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

Arthur A-Koziol at neiu.edu
Mon Jan 4 18:50:44 PST 2010

>On Mon, Jan 4, 2010 at 2:34 PM, Matt Olander 
><<mailto:matt at ixsystems.com>matt at ixsystems.com> wrote:
>On Mon, Jan 4, 2010 at 12:28 PM, Arthur Koziol 
><<mailto:A-Koziol at neiu.edu>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, 
> <mailto:doverosx at gmail.com>doverosx at gmail.com<<mailto:doverosx at gmail.com>doverosx at gmail.com>
> >>  wrote:
> >>
> >>>
> >>> Arthur Koziol wrote:
> >>>
> >>>>
> >>>>
> >>>> 
> <http://www.osnews.com/story/22683/Intel_Forced_to_Remove_Cripple_AMD_Function_from_Compiler_>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
> >>>> <mailto:Testing at lists.pcbsd.org>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 :)
>Testing mailing list
><mailto:Testing at lists.pcbsd.org>Testing at lists.pcbsd.org
>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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pcbsd.org/pipermail/testing/attachments/20100104/b49cd2b7/attachment.html>

More information about the Testing mailing list