Intel's "cripple AMD" function:Will Intel be forced to remove the "cripple AMD" funct

[kl0012]

If SSE 2 (for example) is basically the same regardless of what CPU it's found in why are you of the opinion that Intel has the right to flag it for their CPU only? SSE 2 (in this example) is shared (albeit how they function in each CPU may not be exactly the same) so there should be some co-operation between companies in this endeavor. This makes no sense to me.

All cpus have so-called "errata list". CPU manufacturers usually releases workaround directives especially for compiler & bios writers how to avoid situation where some errata can take place. So, even some cpu supports some instructions extension you can't say that this cpu is fully supported by specific compiler until all related tests were done (even if 99.9% of time it works as expected) .


Now here is what Intel have to say about:
http://software.intel.com/en-us/arti...optimizations/

There are three main types of processor-specific optimization options:

1. Processor-specific options of the form /arch:x<code> on Windows* ( -m<code> on Linux* or Mac OS* X) generate specialized code for processors specified by <code>. The resulting executables from these processor-specific options can be run on the specified or later Intel® and compatible, non-Intel® processors that support the instruction set. The executable may incorporate optimizations specific to those processors and use a specific version of the Streaming SIMD Extensions (SSE) instruction set; on older processors without support for the corresponding instruction set, and illegal instruction or similar error may occur.
2. Processor-specific options of the form /Qx<code> on Windows*( -x<code> on Linux* or Mac OS* X) generate specialized code for processors specified by <code>. The resulting executables from these processor-specific options can only be run on the specified or later Intel® processors, as they incorporate optimizations specific to those processors and use a specific version of the Streaming SIMD Extensions (SSE) instruction set. This switch enables some optimizations not enabled with the correpsonding switchws /arch:x<code> or -m<code>. A run-time check is inserted in the resulting executable that will halt the application if run on an incompatible processor. This is intended to help you quickly find out that the program was not intended for the processor it is running on and potentially avoids an illegal instruction error.
3. Processor-dispatch options of the form /Qax<code> on Windows* ( -ax<code> on Linux* or Mac OS* X) allows the generation of multiple code paths for Intel® processors. Processor dispatch technology performs a check at execution time to determine which processor the application is running on and use the best code path that is compatible with that processor. Compatible, non-Intel processors will take the default code path. The switches described in 1. and 2. above can be used to modify the default code path.

In other words only an /Qax option generates multiple code path while optimized code paths are generated for Intel cpus only. You can still use optimization (such as SSE2) for other cpus by modifying default code path but then you may face a problem with an older cpus (such as Athlon XP). Thats it. If you don't like it, don't use Intel compiler.

[xlink]

So in other words, Intel's Performance edge, could be all unfair optimizations

So this is why my socket 939 still "feels" faster then my quad core 775

On second thought, doesn't Nvidia do this all the time anyway?

Intel should just rename its optimizations to, Intel, the way its meant to be played

I agree, I noticed reduced general system performance when I switched from my 2.6Ghz opteron 165 to a 3.6Ghz c2d... I thought it was the harddrive setup... nope...
the system responsiveness came back when I switched to Am2+
did notice that the c2ds tend to install things faster though. I really need to try out a nehalem system sometime though.

[highoctane]

In other words only an /Qax option generates multiple code path while optimized code paths are generated for Intel cpus only. You can still use optimization (such as SSE2) for other cpus by modifying default code path but then you may face a problem with an older cpus (such as Athlon XP). Thats it. If you don't like it, don't use Intel compiler.

Yeah but in order to know to set the flags you would have to do something like read instructions or have some kind of education about the compiler being used....

[kl0012]

Yeah but in order to know to set the flags you would have to do something like read instructions or have some kind of education about the compiler being used....

Right. All the hype is about one compiler switch only. By default Intel compiler doesn't generate multiple code paths and doesn't check cpu type.

edit - oops, clicked edit instead of quote lol - STEvil

[STEvil]

Right. All the hype is about one compiler switch only. By default Intel compiler doesn't generate multiple code paths and doesn't check cpu type.

edit - oops, clicked edit instead of quote lol - STEvil

One of the links makes mention that SSE/2 has a check (not the "genuineintel" one) and that vector math is not the same due to the check, therefore only SSE is used if the check is not removed.. so even if you kill "genunineintel" you dont get everything.

that could actually be the main article btw, but I forget because i've read about 20 web pages now tracking down different things trying to find ways to optimize programs...

[kl0012]

One of the links makes mention that SSE/2 has a check (not the "genuineintel" one) and that vector math is not the same due to the check, therefore only SSE is used if the check is not removed.. so even if you kill "genunineintel" you dont get everything.

that could actually be the main article btw, but I forget because i've read about 20 web pages now tracking down different things trying to find ways to optimize programs...

Agner refered to the /Qax switch even it was not mentioned in the subject article. But here he expanded about the matter of the problem (paragraph 12.2):
http://www.agner.org/optimize/optimizing_cpp.pdf
Also I didn't saw any evidence that Intel used automatic dispatcher in other cases then /Qax switch which is well documented in Intel compiler manual.
A few words about PCMark05 mentioned above - there is no evidence that it was compiled with ICC. Moreover I would say it wasn't compiled with ICC since VIA cpu get some bust while AMD authentication was used (why?). I don't know what was the reason why developers used multiple code paths but probably it was not Intel compiler.

[alfaunits]

Actually it is that simple; that is EXACTLY how it is supposed to work.

No it's not.
You want to know why? Here:
Compiler: Hi, CPUx. Do you support FDIV?
CPUx: Yes, I do.
Compiler: Great! Let me use it..
<BOOOM>
What happened? the CPUx is an Intel P1 with FDIV bug
Every single compiler as of them included a FDIV-bug code path if there was FPU code.
Compilers have to be CPU agnostic.
There are similar cases for SSEx. Not as bad as FDIV but code breaking.
Also, AMD CPUs do not use the same memory alignment and other data arragnement optimizations the same way Intel CPUs do for the same instruction (be it vanilla x86 or SSEx). Intel is not responsible for making sure the code path works on AMD CPUs; but if it allowed Intel optimized code path to run on AMD CPUs, we would have the same AMD-is-crippled cr** talk again because we would find a similar situation where the code path for Intel CPUs works slower on AMD CPUs than the default code path would.

This would be similar to claiming that the CPU manufacturer needs to get and test every motherboard that anybody might possibly make anywhere in the world.

No. You totally misrepresent the idea. The basis of AMD CPUs is nothing Intel made in terms of hardware. Motherboards are based on Intel made hardware. Intel actually certifies their chipsets to work with specific CPUs - it is up to the mobo manufacturers whether that really works (due to voltage/stability/heating or whatever issues).

It is also not their job to CERTIFY what the AMD CPU can and can not do.

No, it is their job to make sure their code works on non-Intel CPUs - that's where it ends. It's not their job to even make it possible for the best code path to be run. Nor is it even their job or obligation of any kind to even make it possible to run the fastest code path on non-Intel CPUs.

Does their default code work slower than the code compiled by default with MSVC++ or GCC++? Is ICC++ making code that has lines of code not needed? No.

It is however Intel's job to use what the CPU has been certified by AMD to do.

Since when? LOL!

People seem to be attempting to make this into a much more complicated issue than merely using a certain optimization or not.

You don't make compilers, obviously. Don't trivialize them then.

[safan80]

it's not about who makes better compilers or who invest heavily on compiler dev
it's about Intel's underhand methods ... if they're had superior products, they've more than just winning but to actually sneak at one's back and shot at their leg ... is not something to be proud of

Since intel pays their devs they can do whatever they want to their compilers. As for their other practices that would be a different discussion.

[JohnZS]

What is with the rabid AMD fanboi'ism on these forums?

#1 Intel doesn't owe AMD anything in their compilers.
#2 Intel doesn't own the only compiler.
#3 Any good software developer will not stop optimizations at the compiler level. They bring in byte code programmers fluent in assembly to tweak things beyond what is normally possible for a compiler to do.

This AMD is the wounded kitten being picked on by the Intel pitbull mentality on these forums is so annoying already.

I have noticed this too.
The AMD Fanboism I can live with, however it is the constant "AMD hard done by", "AMD being crushed by the evil empire", "AMD is ethical", "AMD is Green", all this nonsense is pathetic.

If AMD spent less of their time moaning and envying Intel's success and actually started to work on their own compilers and improve their own products (like they have with the fantastic Phenom II) they would be in a much better position.

I will admit that certain shady deals with certain OEM's during the Pentium flaw.. sorry Pentium 4 era were rather naughty to say the least, but AMD needs to get over this and produce the next AMD FX50

I find it disappointing to say the least that a lot of threads lately are full of so much nVidia and Intel hate when at the end of the day as controversial as this may sound ALL corporations are as bad as each other.

Final8ty
Is absolutely right, this is like BatmanAA. nVidia provided the cards, and the code to enable FSAA on Batman, why should ATi cards have this if they did not provide the cards for it (the nVidia code) to be tested on?

Naturally I am with you as we all know ATi cards are more than capable of supporting FSAA just sadly ATi do not provide as much developer resources as nVidia (although that has changed somewhat with quite a few DirectX11 titles)

ATi need to just be more proactive instead of reacting like they were hard done by.

John

DISCLAIMER I am an Intel and nVidia fanboy so take my posting with copious amounts of salt... or vodka, which ever you prefer

[Greg83]

Guess all I have to say, is I feel duped by Intel, about the real performance of their processors now and will not trust any numbers I see in reviews every again, games, apps, benchmarks regardless.
I feel, theoretical performance, is closer to real performance in a non-intel compiler world, since afaik, all apps/games/benchmarks used in reviews, were compiled with this Intel compiler .

AMD / ATI all the way, no more , Paid to cripple competitors performance nvidia/intel stuff.

[RPGWiZaRD]

^ Heh I doubt more than perhaps 5% of the tests you see have unfair advantage due to Intel's compiler. As long as MSVC stays as the most popular and useful compiler there's no bigger concern I think.

[kl0012]

Guess all I have to say, is I feel duped by Intel, about the real performance of their processors now and will not trust any numbers I see in reviews every again, games, apps, benchmarks regardless.
I feel, theoretical performance, is closer to real performance in a non-intel compiler world, since afaik, all apps/games/benchmarks used in reviews, were compiled with this Intel compiler .

AMD / ATI all the way, no more , Paid to cripple competitors performance nvidia/intel stuff.

The funny thing is that if all the benchmarks would use Intel compiler, then the superiority of Intel processors would be much, much higher (up to 2-3 times in case of optimizations for SSE2/3) and not only because of the lack of optimization for AMD, but also because of presence much better optimization for Intel. By the way, Pentium 4 is often lost Athlon64 due to lack of intelligible optimization for SSE2 and HT.

[grimREEFER]

i believe the reason is that, depending on the cpu, even if there is support for an instruction set, it may be faster still to avoid it altogether.
Generally, the non intel cpu's have poor enough sse performance that they don't lose too much performance anyway, or perhaps gain performance.

[RPGWiZaRD]

i believe the reason is that, depending on the cpu, even if there is support for an instruction set, it may be faster still to avoid it altogether.
Generally, the non intel cpu's have poor enough sse performance that they don't lose too much performance anyway, or perhaps gain performance.

That's total BS. With the PCSX2 emulator which is a prime example because it utilizes like all instructions that's useful for it and it's extremely cpu limited in most of the case (you even see linear performance gains with overclocked CPU amount). It utilizes many important instructions from especially SSE and SSE2 (today also SSE3 and some SSE4/4.1 in plugins) and without those it's a matter of playable vs non playable speeds (we're talking maybe 3x-4x difference in speed). You could see in the past that the Athlon XPs couldn't handle it at all due to lack of SSE2 and even Pentium 4's performed significantly better but then with AMD64 cpus with SSE2 support it became a totally different story where say 2.6 ~ 2.8GHz AMD64 performed something equal to maybe 5.0~5.4GHz P4.

[Hornet331]

No, it is their job to make sure their code works on non-Intel CPUs - that's where it ends. It's not their job to even make it possible for the best code path to be run. Nor is it even their job or obligation of any kind to even make it possible to run the fastest code path on non-Intel CPUs.

Does their default code work slower than the code compiled by default with MSVC++ or GCC++? Is ICC++ making code that has lines of code not needed? No.

even though its a bit old, i just leave this here... (note: this is run on a amd cpu)

http://www.usenetbinaries.com/doc/gc...arks_perl.html

[Greg83]

^ Heh I doubt more than perhaps 5% of the tests you see have unfair advantage due to Intel's compiler. As long as MSVC stays as the most popular and useful compiler there's no bigger concern I think.

But is that the 5% of tests where intel destroyed the amd?
I can only assume it is, based on the amd gaming performance

[alfaunits]

OK, so essentially ICC is faster than GCC/default is almost everything? Ridicolously faster in some, faster more/less in most, and miserably slower in just a few?
And the problem IS??? (not meant for you, Hornet, JTBC)

even though its a bit old, i just leave this here... (note: this is run on a amd cpu)

http://www.usenetbinaries.com/doc/gc...arks_perl.html

[wuttz]

OK, so essentially ICC is faster than GCC/default is almost everything? Ridicolously faster in some, faster more/less in most, and miserably slower in just a few?
And the problem IS??? (not meant for you, Hornet, JTBC)

that wasn't meant to be a reliable, scientific nor definitive table of benchmark results.

in other words, that table should be taken only at face value, with results that may or may not be accurate, consistent or reproducible.

in my own words, that table is crap.

[Hornet331]

that wasn't meant to be a reliable, scientific nor definitive table of benchmark results.

in other words, that table should be taken only at face value, with results that may or may not be accurate, consistent or reproducible.

in my own words, that table is crap.

yet, the via nano table is pure gold...

[BrowncoatGR]

Some of you need to realize that the Intel Compiler Suite is a product in it's own right and not something Intel distributes for free in order to support their processors. If they don't support competing processors they need to clarify that in the system requirements. Of course if they did that nobody would actually use it. Who wants to use a compiler that doesn't properly support 1/4th of the x86 CPUs out there? Still Intel claims the compiler supports any x86 processor that supports at least SSE2 from any vendor.

A PC based on an IA-32 or Intel® 64 architecture processor supporting the Intel®
Streaming SIMD Extensions 2 (Intel® SSE2) instructions (Intel® Pentium® 4 processor
or later, or compatible non-Intel processor), or based on an IA-64 architecture (Intel®
Itanium®) processor

[gosh]

Right. All the hype is about one compiler switch only. By default Intel compiler doesn't generate multiple code paths and doesn't check cpu type.

from 2005
http://www.intelliot.com/blog/2005/0...-stinks-again/
On any non-Intel processors, it specifically included an alternate code path for “memcpy” that actually used “rep movsb” to copy one byte at a time, instead of (for example) “rep movsd” to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I’d ever seen, and was around 4X slower than even a typical naive assembly memcpy:

[wuttz]

from 2005
http://www.intelliot.com/blog/2005/0...-stinks-again/
On any non-Intel processors, it specifically included an alternate code path for “memcpy” that actually used “rep movsb” to copy one byte at a time, instead of (for example) “rep movsd” to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I’d ever seen, and was around 4X slower than even a typical naive assembly memcpy:

ding! ding! ding!
someone hit the jackpot!



purposeful crippling, like bringing in a honda to a toyota service center; and toyota insisting on use of carpentry tools only for honda cars.

[Eastcoasthandle]

All cpus have so-called "errata list". CPU manufacturers usually releases workaround directives especially for compiler & bios writers how to avoid situation where some errata can take place. So, even some cpu supports some instructions extension you can't say that this cpu is fully supported by specific compiler until all related tests were done (even if 99.9% of time it works as expected) .


Now here is what Intel have to say about:
http://software.intel.com/en-us/arti...optimizations/


In other words only an /Qax option generates multiple code path while optimized code paths are generated for Intel cpus only. You can still use optimization (such as SSE2) for other cpus by modifying default code path but then you may face a problem with an older cpus (such as Athlon XP). Thats it. If you don't like it, don't use Intel compiler.

This has nothing to do with my post. You basically created a hypothetical question regarding errata then tried to answer it using my post as a cover front for your own question. Simply put, the flag to only recognize Intel CPUs should be removed. If for any reason it doesn't work properly with AMD, then let it error out. That way it will light a fire under AMD's butt to get it fixed. Had this ever happen with consumers in any large number from the get-go could such a claim have been made. However, this never happened therefore becomes moot.

[Greg83]

I'll never understand devils advocates.

Not all evil can be explained away as good

[alfaunits]

Some of you need to realize

No you need to realize that:

that the Intel Compiler Suite is a product in it's own right and not something Intel distributes for free in order to support their processors. If they don't support competing processors they need to clarify that in the system requirements.

They DO support competing processors - where does it state that they perform the best on competing processors though?? Do you have anything that says that?

Still Intel claims the compiler supports any x86 processor that supports at least SSE2 from any vendor.

Man, do you realize this is "System Requirements" for RUNNING the ICC not the requirement for running ICC compiled code?
ROFL