<br><br><div class="gmail_quote">On Mon, Jan 4, 2010 at 2:34 PM, Matt Olander <span dir="ltr"><<a href="mailto:matt@ixsystems.com">matt@ixsystems.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Mon, Jan 4, 2010 at 12:28 PM, Arthur Koziol <<a href="mailto:A-Koziol@neiu.edu">A-Koziol@neiu.edu</a>> wrote:<br>
> On 01/04/2010 12:58 PM, Matt Olander wrote:<br>
>><br>
>> On Mon, Jan 4, 2010 at 10:34 AM, <a href="mailto:doverosx@gmail.com">doverosx@gmail.com</a><<a href="mailto:doverosx@gmail.com">doverosx@gmail.com</a>><br>
>> ¬†wrote:<br>
>><br>
>>><br>
>>> Arthur Koziol wrote:<br>
>>><br>
>>>><br>
>>>><br>
>>>> <a href="http://www.osnews.com/story/22683/Intel_Forced_to_Remove_Cripple_AMD_Function_from_Compiler_" target="_blank">http://www.osnews.com/story/22683/Intel_Forced_to_Remove_Cripple_AMD_Function_from_Compiler_</a><br>

>>>><br>
>>>> Pretty evil if you asked me. Seems Intel is batting a thousand lately.<br>
>>>> Hope AMD takes 'em to the cleaners.<br>
>>>> _______________________________________________<br>
>>>> Testing mailing list<br>
>>>> <a href="mailto:Testing@lists.pcbsd.org">Testing@lists.pcbsd.org</a><br>
>>>> <a href="http://lists.pcbsd.org/mailman/listinfo/testing" target="_blank">http://lists.pcbsd.org/mailman/listinfo/testing</a><br>
>>>><br>
>>>><br>
>>>><br>
>>><br>
>>> Interesting...I thought it was a fact that WAS widely known and the<br>
>>> issue remedied by the order of the FTC in 2000-2001? Circa K7 Athlons.<br>
>>><br>
>>> Intel seems to be quite evil in how they handle some key operations, of<br>
>>> course, the way they have been "handling" business these days has earned<br>
>>> their appearance in an OpenBSD song ;).<br>
>>><br>
>><br>
>> It *is* the Intel Compiler, after all. Nobody has to use it and I'm<br>
>> not really sure why anybody would try to use it on a non-Intel system<br>
>> ;)<br>
>><br>
>> -matt<br>
>><br>
><br>
> Matt,<br>
><br>
> Bigger picture than just "use something else", imagine all the lost revenue<br>
> for AMD because something showed better benchmarks with Intel versus AMD and<br>
> someone went with Intel as a result. Evil is as evil does. It's funny though<br>
> that when you look at the TOP500, top 3 spots run AMD. HA!<br>
<br>
</div></div>Haha, good point, Arthur. It's definitely a shady thing to do on<br>
Intel's part but I'm just not surprised to find that an Intel Compiler<br>
would compile more efficiently on Intel CPU's. I can't imagine a large<br>
AMD cluster compiling their custom code on anything closed and<br>
Intel-specific like the Intel Compiler though. Ironically, we're<br>
trying to get some traction with Intel to get a modern port of the<br>
compiler on FreeBSD, along with some development tools that are<br>
currently Windows and Linux specific.<br>
<br>
While AMD may have caught Intel with their pants down a few years ago<br>
and had the edge, there is no doubt that the tide has turned and Intel<br>
responded with very fast modern CPUs, regardless of what the code is<br>
compiled on. I'm sure we'll see AMD step it up in their next<br>
architecture :)<br>
<font color="#888888"><br>
-matt<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Testing mailing list<br>
<a href="mailto:Testing@lists.pcbsd.org">Testing@lists.pcbsd.org</a><br>
<a href="http://lists.pcbsd.org/mailman/listinfo/testing" target="_blank">http://lists.pcbsd.org/mailman/listinfo/testing</a><br>
<br>
</div></div></blockquote></div><br>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.<br clear="all">
<br>-- <br>Thanks,<br>Mike Bybee<br>