[PC-BSD Testing] New blurb I thought some might like about AMD v Intel

Arthur Koziol A-Koziol at neiu.edu
Tue Jan 5 06:00:49 PST 2010


On 01/04/2010 10:17 PM, doverosx at gmail.com wrote:
> Arthur wrote:
>    
>>> On Mon, Jan 4, 2010 at 2:34 PM, Matt Olander<matt at ixsystems.com
>>> <mailto:matt at ixsystems.com>>  wrote:
>>>
>>>      On Mon, Jan 4, 2010 at 12:28 PM, Arthur Koziol<A-Koziol at neiu.edu
>>>      <mailto:A-Koziol at neiu.edu>>  wrote:
>>>      >  On 01/04/2010 12:58 PM, Matt Olander wrote:
>>>      >>
>>>      >>  On Mon, Jan 4, 2010 at 10:34 AM, doverosx at gmail.com
>>>      <mailto:doverosx at gmail.com>  <doverosx at gmail.com
>>>      <mailto:doverosx at gmail.com>>
>>>      >>   wrote:
>>>      >>
>>>      >>>
>>>      >>>  Arthur Koziol wrote:
>>>      >>>
>>>      >>>>
>>>      >>>>
>>>      >>>>
>>>      http://www.osnews.com/story/22683/Intel_Forced_to_Remove_Cripple_AMD_Function_from_Compiler_
>>>
>>>      >>>>
>>>      >>>>  Pretty evil if you asked me. Seems Intel is batting a
>>>      thousand lately.
>>>      >>>>  Hope AMD takes 'em to the cleaners.
>>>      >>>>  _______________________________________________
>>>      >>>>  Testing mailing list
>>>      >>>>  Testing at lists.pcbsd.org<mailto:Testing at lists.pcbsd.org>
>>>      >>>>  http://lists.pcbsd.org/mailman/listinfo/testing
>>>      >>>>
>>>      >>>>
>>>      >>>>
>>>      >>>
>>>      >>>  Interesting...I thought it was a fact that WAS widely known
>>>      and the
>>>      >>>  issue remedied by the order of the FTC in 2000-2001? Circa K7
>>>      Athlons.
>>>      >>>
>>>      >>>  Intel seems to be quite evil in how they handle some key
>>>      operations, of
>>>      >>>  course, the way they have been "handling" business these days
>>>      has earned
>>>      >>>  their appearance in an OpenBSD song ;).
>>>      >>>
>>>      >>
>>>      >>  It *is* the Intel Compiler, after all. Nobody has to use it
>>>      and I'm
>>>      >>  not really sure why anybody would try to use it on a non-Intel
>>>      system
>>>      >>  ;)
>>>      >>
>>>      >>  -matt
>>>      >>
>>>      >
>>>      >  Matt,
>>>      >
>>>      >  Bigger picture than just "use something else", imagine all the
>>>      lost revenue
>>>      >  for AMD because something showed better benchmarks with Intel
>>>      versus AMD and
>>>      >  someone went with Intel as a result. Evil is as evil does. It's
>>>      funny though
>>>      >  that when you look at the TOP500, top 3 spots run AMD. HA!
>>>
>>>      Haha, good point, Arthur. It's definitely a shady thing to do on
>>>      Intel's part but I'm just not surprised to find that an Intel
>>>      Compiler
>>>      would compile more efficiently on Intel CPU's. I can't imagine a
>>>      large
>>>      AMD cluster compiling their custom code on anything closed and
>>>      Intel-specific like the Intel Compiler though. Ironically, we're
>>>      trying to get some traction with Intel to get a modern port of the
>>>      compiler on FreeBSD, along with some development tools that are
>>>      currently Windows and Linux specific.
>>>
>>>      While AMD may have caught Intel with their pants down a few years ago
>>>      and had the edge, there is no doubt that the tide has turned and
>>>      Intel
>>>      responded with very fast modern CPUs, regardless of what the code is
>>>      compiled on. I'm sure we'll see AMD step it up in their next
>>>      architecture :)
>>>
>>>      -matt
>>>      _______________________________________________
>>>      Testing mailing list
>>>      Testing at lists.pcbsd.org<mailto:Testing at lists.pcbsd.org>
>>>      http://lists.pcbsd.org/mailman/listinfo/testing
>>>
>>>
>>> I've been experimenting a bit with clang and llvm on FreeBSD/PC-BSD
>>> and Debian lately. I haven't tried doing any performance testing with
>>> the compiled executables against the Intel compiler, but it does
>>> compare favorably with gcc. Really close in execution time, but
>>> compiles FAR faster.
>>>        
>> CLANG, that's the one I was trying to think of. All those riding the
>> GCC sucks bus are fawning over it to take over as the default compiler.
>>
>> Arthur
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Testing mailing list
>> Testing at lists.pcbsd.org
>> http://lists.pcbsd.org/mailman/listinfo/testing
>>
>>      
> Onto compiler talk I see ;).
>
> I hear PCC is a more likely candidate in the near but not-near future.
> Also is it true that FreeBSD isn't adopting GCC 4.3.X+ because of
> licensing discrepancies? There is a big performance gap between gcc
> 4.2.1 and gcc 4.3.X that makes FreeBSD look bad in the useless
> benchmarks by phoronix.
>
>    
That I don't know to be honest. I might be talking out my posterior but 
did I read that the work going into GCC 4.5 will be what eventually 
allows it to run on 7.x BSD and up (IF it was because of GPLv3 license 
issue)? Heh, PTS isn't so bad. I have some appreciation of the new 
Phoromatic Tracker that is able to automagically find the latest 
regressions in the Linux kernel but testing the daily kernel builds. 
That could benefit the BSD devs I would think if it could be contoured 
to BSD also. <sarcasm>But unlike Linux, FreeBSD is *PERFECT*! </sarcasm> 
If you look here, it seems GCC 4.5 work is pretty active: 
http://www.freshports.org/lang/gcc45/. Nothing on the surface though 
about if the licensing stuff has been resolved. Maybe we'll see final by 
the time FBSD 8.1 rolls out.

Arthur


More information about the Testing mailing list