AMD running Intel specific code.

D

DocFaustus

2[H]4U
Joined
Sep 22, 2002
Messages
2,830
I ripped this link off of the [H]ard|OCP mainpage news section. To sum it up: It looks like some code specifically makes Intel chips faster based on a little piece of code that checks to see if an Intel proc is being used. See what happens when the code is modified and ran on AMD.

Is this a cut and dry case of specific code to make them look better, or is there any real reason for it to be written this way?



<waits for FreiDOg's reply>
 
I think this would be awesome for [H] Labs to verify, and if proven, trumpet it from the rooftops. I wonder if the trick would work on any athlon cores?
 
It looks like the CPU needs to pass 3 checks to get the speed bonus:

1) SSE
2) SSE2
3) Be an Intel chip.

I barely know code, So I don't know if the chips actually need to run SSE and SSE2 to take advantage of the speed boost, or if they are just another set of checks to try and avoid the competition's chips.
 
Was this code written by Intel that attaches itself to programs to make Intel products look better, or is this someething contained in some OSes, or is this something that is included in third party software? I am curious who is doing this. I am sure I know why this is being done (because Intel is above the law) but I am wondering if they are working alone or if Microsoft or other companies are in on the illegal monopoly style crimes that are being committed. I am thinking this is an Intel- Microsoft crime IMHO. It would be typical since both companies think they are above the law and have always attempted to crush the competition in any illegal manner they see fit.

Reminds me of the old Windows that would not work with Dr Dos due to a line of code in it. You had to run Microsoft Dos. They effectively killed Dr Dos with it and completely got away with the crime.
 
What's so hard to understand? ICC checks as per the 1-3 steps outlined above.

If they check 3 by mistake or not remains to be seen. If they check for "GenuineIntel" then yes, it's by design, else it might as well be a mistake. I see buggy/misdesigned CPU-capabilities-checking code all the time.
 
That was the point of the article, I think. The intel compiler claimed it was doing "intel-specific" optimizations and would refuse to run on non-intel processors. The guy in this article figured out how to remove the check for "is this an intel processor", and showed that an AMD processor got the same performance boost as the Intel one did.

I think this demonstrates that Intel is using general optimizations in their compiler and unfairly labelling them as "intel-specific" so that only Intel processors can benefit from them. This makes a big difference for something like SPEC.
 
Originally posted by pantherdan
Was this code written by Intel that attaches itself to programs to make Intel products look better, or is this someething contained in some OSes, or is this something that is included in third party software? I am curious who is doing this. I am sure I know why this is being done (because Intel is above the law) but I am wondering if they are working alone or if Microsoft or other companies are in on the illegal monopoly style crimes that are being committed. I am thinking this is an Intel- Microsoft crime IMHO. It would be typical since both companies think they are above the law and have always attempted to crush the competition in any illegal manner they see fit.

Reminds me of the old Windows that would not work with Dr Dos due to a line of code in it. You had to run Microsoft Dos. They effectively killed Dr Dos with it and completely got away with the crime.
Click to expand...

How do you come to such a ridiculous conclusion without even knowing what a compiler is?

In simple terms, a compiler turns code that a human writes into a program that a machine can run.

Apparantly, using Intel's compiler, there are supposidly 'Intel specific' optimizations that also run on an Opteron using SPEC. Just because it runs SPEC doesn't mean those optimizations are fully compatible with the Opteron. Not to mention it is AMDs best interest to make their processors as compatible with Intel as possible.

Intel is under no obligation to test or optimize for AMD chips, and no one is under any obligation to use Intel compilers. There is nothing unfair about it.
 
Originally posted by VVVVVVVVVVVVVVVI
How do you come to such a ridiculous conclusion without even knowing what a compiler is?

In simple terms, a compiler turns code that a human writes into a program that a machine can run.

Apparantly, using Intel's compiler, there are supposidly 'Intel specific' optimizations that also run on an Opteron using SPEC. Just because it runs SPEC doesn't mean those optimizations are fully compatible with the Opteron. Not to mention it is AMDs best interest to make their processors as compatible with Intel as possible.

Intel is under no obligation to test or optimize for AMD chips, and no one is under any obligation to use Intel compilers. There is nothing unfair about it.
Click to expand...

I think you are missing the point that it is impossable to make your chip compatible when there is a line of code that says "if not intel, then don't run".

There is a huge difference between writing code to make your product better and writing code to make your competition worse.
 
Originally posted by VVVVVVVVVVVVVVVI

Just because it runs SPEC doesn't mean those optimizations are fully compatible with the Opteron. Not to mention it is AMDs best interest to make their processors as compatible with Intel as possible.

Intel is under no obligation to test or optimize for AMD chips, and no one is under any obligation to use Intel compilers. There is nothing unfair about it.
Click to expand...

That would be a valid argument if the optimizations involved using something that could be intel-specific, such as maybe their implementation of MMX/SSE/SSE2/SSE3. However, the code in question involves no such instructions. The optimization was to re-arrange fields in a struct. Clearly this is not intel-specific and any processor can take advantage of the code generated by doing this. However, this optimization only occurs when the "intel-specific" flag is set, meaning that AMD processors that are perfectly capable of taking advantage of this are left out in the cold.
 
Intel saying doesn't run was very true until the K8 arrived, the huge speed boost was mainly from sse2 auto vectorizing. Intel was the only ones with sse2 chips until the K8 core, and after that, they put in flags to keep the auto vectorizing intel only.
 
Originally posted by DocFaustus
I think you are missing the point that it is impossable to make your chip compatible when there is a line of code that says "if not intel, then don't run".

There is a huge difference between writing code to make your product better and writing code to make your competition worse.
Click to expand...

You realize there are other compilers out there besides Intel's, right?

How could you possibly come to the conclusion they are writing code to make the competition worse?

I think you are missing the point of the Intel optimizations.

Intel has a series of CPU specific optimizations in their compiler. They have optimizations for the PIII or higher (QxK), for Prescott (QxP), for Pentium M (QxB), and for the PIV or higher (QxW).

This:

if not intel, then don't run
Click to expand...

is wrong.

The proper way of saying it would be:

if not Pentium X, then don't run
Click to expand...

Intel is checking if the code will run on a specific processor.

From Intel's manual (search google, PDF):

To prevent execution errors, the compiler inserts code in the program to check for proper processor usage. Programs compiled with options /QxN, /QxB, or /QxP will check at run time whether they are being executed on the Intel® Pentium® 4 processor, Intel Pentium M processor, or the Intel processors code-named "Prescott", respectively, or a compatible Intel processor. If the program is not executed on one of these processors, the program terminates with an error.
Click to expand...

You guys are trying to create a conspiracy that just isn't there.
 
Its despicable, but it is well within Intel's rights to write a compiler that puts their products in a better light. It is the Intel compiler, after all.

Considering AMD used Intel's compiler for their SPEC submissions, i'm interested in knowing just how much more performance can be eked out of the Opteron line with a non-biased compiler (no, GCC doesn't count)
 
Originally posted by valtrain
That would be a valid argument if the optimizations involved using something that could be intel-specific, such as maybe their implementation of MMX/SSE/SSE2/SSE3. However, the code in question involves no such instructions. The optimization was to re-arrange fields in a struct. Clearly this is not intel-specific and any processor can take advantage of the code generated by doing this. However, this optimization only occurs when the "intel-specific" flag is set, meaning that AMD processors that are perfectly capable of taking advantage of this are left out in the cold.
Click to expand...

How do you know what the optimizations do? It doesn't say in the link what they are for, they don't know.

Besides, that bypasses the whole point that Intel is somehow required to put in a check for a specific AMD processor and it is a conspiracy if they don't. (edit: How is that despicable?)

Why would they put in optimizations checking for a specific AMD processor? That doesn't make any sense.
 
Originally posted by Merlin45
Intel saying doesn't run was very true until the K8 arrived, the huge speed boost was mainly from sse2 auto vectorizing. Intel was the only ones with sse2 chips until the K8 core, and after that, they put in flags to keep the auto vectorizing intel only.
Click to expand...

The K8's have been out for a year now, the first version of the intel compiler to include the "intel specific optimizations" came out 2 months ago.

Originally posted by Mark Larson

Considering AMD used Intel's compiler for their SPEC submissions, i'm interested in knowing just how much more performance can be eked out of the Opteron line with a non-biased compiler (no, GCC doesn't count)
Click to expand...

I agree, it seems that intel is trying to unfairly slant the SPEC scores in their favor. While I think it would be OK to include intel-specific optimizations in their compiler IF IN FACT THEY ARE INTEL SPECIFIC, it seems that in this case the optimizations are clearly not intel-specific and are not allowed to benefit AMD processors.

Originally posted by VVVVVVVVVVVVVVVI

How do you know what the optimizations do? It doesn't say in the link what they are for, they don't know.

Besides, that bypasses the whole point that Intel is somehow required to put in a check for a specific AMD processor and it is a conspiracy if they don't. (edit: How is that despicable?)

Why would they put in optimizations checking for a specific AMD processor? That doesn't make any sense.
Click to expand...

Intel shouldn't have to put in a check to see what kind of AMD processor it is. Additionally, Intel shouldn't put in a check to see if its an Intel processor. If they are doing optimizations that require SSE or SSE2 support, why not just check for SSE/SSE2 support instead of additionally checking the CPUID for the GenuineIntel string. Even more preposterous than this, the optimization cited in the posting on comp.arch didn't even rely on SSE/SSE2, it was just a general optimizatoin that any processor could take advantage of.
 
Originally posted by valtrain
Intel shouldn't have to put in a check to see what kind of AMD processor it is. Additionally, Intel shouldn't put in a check to see if its an Intel processor. If they are doing optimizations that require SSE or SSE2 support, why not just check for SSE/SSE2 support instead of additionally checking the CPUID for the GenuineIntel string.
Click to expand...

Did you even read my post? Or understand it?

The string 'N' didn't check for Intel, it checked for Pentium 4. Intel optimizes for the Pentium 4, Prescott, Pentium M, etc... not just for SSE/SSE2.

Read. Comprehend.

Even more preposterous than this, the optimization cited in the posting on comp.arch didn't even rely on SSE/SSE2, it was just a general optimizatoin that any processor could take advantage of.
Click to expand...

Those optimizations don't work on PIII or the AthlonXP. They are specific to the Pentium 4(*), which is why it checks for the Pentium 4, NOT Intel.

The only thing that is preposterous is the conspiracy nuts out in force, who don't even understand the basics of what is going on.

Edit: (*) Since Intel (rightly so) doesn't optimize for AMD chips, those optimizations are specific to the Pentium 4.

Again, just because they happened to work on the Athlon64 in this specific program, it in no way gives any indication they will work over a broad range of programs. Intel doesn't know, because they aren't going to test for AMD specific optimizations.
 
> [...] and showed that an AMD processor got the same performance boost as the Intel one did.

This is a surprise in your world? Do you know of any instruction(s) where the Pentium is orders of magnitude faster than the AMD implementation? I don't. So why the surprise?

The only thing worth discussing here is a) is the check for Intel CPUs (instead of req. instruction set capabilities) by design, and if so, is that and it's apparent lack of documentation morally/ethically defendable.

addendum: Some of you seem to have expected that the Intel compiler would have injected some mysterious P4-only-instructions into the code to make it faster. Now _that_ would have been newsworthy!

Extra Extra! New secret performance instructions found hidden away in IA-32 implementation on Pentium 4s! Read all about it!
 
AMD needs to get off their asses and write their own compiler. There is so much potential with the K7-K8 execution pipeline that none of the compilers take advantage of.
 
VVVVVVVVVVVVVVVI, chill the fuck out. Stop trying to kill the thread and let people talk about it. You are not explaining shit. You just keep repeating youself and following it up by calling us conspiracy nuts, and say we don't understand what a compiler is, et cetera.

Since you seem to be a self proclaimed expert, why don't you explain to us why there is nothing to be concerned about:

1) Why the intel chip check is there
2) If the code actually uses SSE and SSE2. Or will non SSE/SSE2 chips benifit if those checks were there.
3) What is adversly affected in terms of performance (from an end user standpoint).
4) What else is compiled this way.
 
Originally posted by eloj
The only thing worth discussing here is a) is the check for Intel CPUs (instead of req. instruction set capabilities) by design, and if so, is that and it's apparent lack of documentation morally/ethically defendable.
Click to expand...

It's documented. I quoted it directly from Intel's PDF.
 
> "or a compatible Intel processor."

.. only because "Intel" and "compatible" weren't juxtaposed :-\
 
Originally posted by DocFaustus
VVVVVVVVVVVVVVVI, chill the fuck out. Stop trying to kill the thread and let people talk about it. You are not explaining shit. You just keep repeating youself and following it up by calling us conspiracy nuts, and say we don't understand what a compiler is, et cetera.
Click to expand...

Kill the thread? Sorry, I'm not a fanboy, I own AMD and Intel chips. If you guys want to have a bash Intel fieldday, go ahead, but expect someone to inject reality.

I shouldn't have to repeat myself. I pointed out the optimization was specific for the Pentium 4 straight from Intel docs. When someone directly quotes me and says it is NOT, obviously I'm going to repeat myself.

That person I quoted didn't understand what a compiler was. I didn't say YOU, thats why I quoted him.

Since you seem to be a self proclaimed expert, why don't you explain to us why there is nothing to be concerned about:

1) Why the intel chip check is there
Click to expand...

Optimizations that work on the P4 wont work on the PIII, and etc...

2) If the code actually uses SSE and SSE2. Or will non SSE/SSE2 chips benifit if those checks were there.
Click to expand...

Non SSE/SSE2 chips wont work because they are not Pentium 4s.

3) What is adversly affected in terms of performance (from an end user standpoint).
Click to expand...

There is nothing adversly affected in terms of performance. The optimizations were a positive gain in performance.

4) What else is compiled this way.
Click to expand...

I don't understand what you mean by that.
 
I sent an email to the guy's address he posted on comp.arch, in his reply he said that he ran the entire SPEC suite on the AMD FX51 using the hacked "intel-only" binaries. To me, SPEC represents a pretty broad range of programs, you'd think if this one was freak accident where the optimization happened to work on AMD's processors then at least some part of SPEC would have failed.

In response to DocFaustus, I think:

1) I could understand why a SSE/SSE2 check would be needed since not all processors support that. I'm wondering why not just check for SSE/SSE2 rather than that PLUS the intel cpuid?

2) Clearly if there are SSE/SSE2 optimizations then the chip will need to support SSE/SSE2 in order to run. However, AMD's K8 has supported both SSE and SSE2 for a year now and I don't see why any optimization using those couldn't also work on the AMD chip.

3) Its not that things are adversely affected, per se. It will make Intel's benchmarks seem artifically fast when compared to AMD processors if Intel's compiler is being used. This seems to be the most important note here in my opinion.

4) I'm not sure who else uses the Intel compiler, although Intel's site seems to list plenty of feedback on it so somebody must be using it.
 
Originally posted by VVVVVVVVVVVVVVVI
Kill the thread? Sorry, I'm not a fanboy, I own AMD and Intel chips. If you guys want to have a bash Intel fieldday, go ahead, but expect someone to inject reality.

I shouldn't have to repeat myself. I pointed out the optimization was specific for the Pentium 4 straight from Intel docs. When someone directly quotes me and says it is NOT, obviously I'm going to repeat myself.
Click to expand...

I have examined the supposedly "intel-specific" binaries generated by ICC8. The optimization in question is not specific to Intel, P4, P3, P2, or even x86!!! It's a data re-organization optimization of struct fields (if you know compilers, then you should know what I'm talking about). This optimization works for almost all architectures/implementations. Examine the object files if you don't believe me.

Since this optimization works on all CPUs, there's no reason for intel to label it "intel-specific" except to hurt (using illegal monopoly tactics) the competition.
 
hrmm well not to paint Intel as a good guy or anything but it seems like the proper thing to do; checking for an Intel specific processor when implementing processor specific optimizations is the best way to ensure reliability. You never know if the code is going to run on a Transmeta or a VIA Crap E-PC500 XT where these optimizations won't do any good.

It should be AMD's resonsibility to release a compiler that can handle Athlon64 optimizations, but instead they give you a .pdf so you can read how to do the optimizations yourself. Gee thanks!
 
This is really old news actually, this is the same reason why AMD opterons or FX's SSE2 sucks because programs don't recognize the AMD cpu properly. When the recognition is fixed SSE2 works just as well as P4 atm the SSE2 execution is done every 2 cpu cycles. This is why Opterons do poorly in sisoft sandra SSE2 tests, when the program is coded better it will not have that problem.

I don't think AMD has a compiler but I do know that their Math.h Library is optimized for AMD hence their x86 flies. All Math header lib does is rearrange in which code is executed which favours AMD chips. Oh and the Math.h is AMD only lib ( 64 bit)
 
Originally posted by formerIntelEmployee
I It's a data re-organization optimization of struct fields (if you know compilers, then you should know what I'm talking about).
Click to expand...

Sounds like the data structures are being swizzled to improve cache optimization. These types of optimizations most certainly vary from processor to processor.
 
Originally posted by valtrain
I sent an email to the guy's address he posted on comp.arch, in his reply he said that he ran the entire SPEC suite on the AMD FX51 using the hacked "intel-only" binaries. To me, SPEC represents a pretty broad range of programs, you'd think if this one was freak accident where the optimization happened to work on AMD's processors then at least some part of SPEC would have failed.

In response to DocFaustus, I think:

1) I could understand why a SSE/SSE2 check would be needed since not all processors support that. I'm wondering why not just check for SSE/SSE2 rather than that PLUS the intel cpuid?

2) Clearly if there are SSE/SSE2 optimizations then the chip will need to support SSE/SSE2 in order to run. However, AMD's K8 has supported both SSE and SSE2 for a year now and I don't see why any optimization using those couldn't also work on the AMD chip.

3) Its not that things are adversely affected, per se. It will make Intel's benchmarks seem artifically fast when compared to AMD processors if Intel's compiler is being used. This seems to be the most important note here in my opinion.

4) I'm not sure who else uses the Intel compiler, although Intel's site seems to list plenty of feedback on it so somebody must be using it.
Click to expand...

is it just me or have the k8's only been available for a few months? and not a full year?
 
Originally posted by Jason711
is it just me or have the k8's only been available for a few months? and not a full year?
Click to expand...
Opteron was launched a good while ago. Not a full year, but close (April 22, IIRC)
 
Originally posted by old skool
Sounds like the data structures are being swizzled to improve cache optimization. These types of optimizations most certainly vary from processor to processor.
Click to expand...

Cool, if that is what they are doing, then all the more power to them. We need AMD to follow suit.
 
Originally posted by DocFaustus

<waits for FreiDOg's reply>
Click to expand...

who knows why.....


anyway,
all ICC code starts with a call to
___intel_proc_init
it will use ___intel_proc_init_X for /QxX flags, which undoubtedly do a more indepth check of the CPU abilities including HT on some P4 models (N, B, P), it could be that bit test that's causing code not to run on A64, when the __intel_proc_init works fine (probably only checks pretty basic IA32 functionality)


i ran a few programs through ICC with and without /QxN flag, 1 with SIMD friendly code, and 1 without.

The only real difference in the assembly output (/FA flag) was the simd friendly code used SSE instead of MMX (as you would expect).
These weren't really the complexity of programs I would like for good comparison. one a simple conversion from n bit bitmaps to 32 bit XRGB, the other some sorting / managment of an octree (just a few chunks of a larger program).

The bulk of the 'Intel only optimizations' i would think are limited to
1. ordering the structs / variables (as was mentioned) to improve sequential access where possible (especially towards SSE_ movs, which are very improtant to P4's cache bandwith)
2. defaulting to multithreaded libraries where HT is avalible,
3. defaulting to SSE2 then SSE1 then MMX instructions instead. (no cpu flags will leave SSE_ off by default).
4. might take into account things like register file size, or optimize for trace cache usage, but that's just a wild guess.

ASM output was very close in size, so i don't /Qx_ implies anything like /fast (/fast was ~33% larger ASM output because of extemely agressive loop unrolling and inlining) or /03 (high optimization for speed).
 
wwwwwwwwww if you want to enlighten someone who is not "in the know" that is fine. Coming off as some kind of superior being actually makes you look like a punk. Thanks for the divine enlightenment. You da man.

Several people went on to point out these things that I was griping about. Looking for specific Intel product pretty much sums it up. If it is capable of running on an AMD chip, then writing code to make it fail is deliberate. Cut and dry. Black and White.

If you are not an Intel fanboy, don't act like one.
 
Originally posted by Mark Larson
Opteron was launched a good while ago. Not a full year, but close (April 22, IIRC)
Click to expand...

how the hell does that elude me? :confused:
 
Originally posted by pantherdan
wwwwwwwwww if you want to enlighten someone who is not "in the know" that is fine. Coming off as some kind of superior being actually makes you look like a punk. Thanks for the divine enlightenment. You da man.

Several people went on to point out these things that I was griping about. Looking for specific Intel product pretty much sums it up. If it is capable of running on an AMD chip, then writing code to make it fail is deliberate. Cut and dry. Black and White.

If you are not an Intel fanboy, don't act like one.
Click to expand...

thats sort of what i have noticed...

it runs on amd chips (only k8?) the exact same (correct me if i am wrong)

and.. intel has put something in the code to make it only run on "pentium" based cpu's, which in turn, gives it a large boost...

therefore.. we throw up the bullshit flag.

now.. i guess it is their compiler, so they can do what they want.

or is it that simple?
 
This entire argument is pointless...the only things being tossed around here are repeated statements of Intel conspiring to make programs run artificially slower on AMD systems, a statement which regardless of your knowledge of the inner workings of compilers is simply wrong.

For starters, this is an Intel compiler...why anyone would expect Intel to thoroughly test their compiler optimizations on AMD processors is beyond me. The fact that the code in question runs just fine on K8 CPUs is not the point...the point is that Intel probably never bothered to test the code on any AMD CPUs, and why would they? Since Intel has no reason to waste resources testing their compilers on competitors' hardware, when they make any code optimizations they can't garauntee compatibility with CPUs other than the ones they test on. Ergo, no testing on AMD, VIA, or any other CPUs means the code gets flagged not to be compiled on such. Stuff happens, even on CPUs who should run basic x86 code identically...just look at the freezing problems Folding@Home has been having with AMD CPUs.

To say that this series of tests is any kind of definitive statement that the code in question will run just fine on AMD processors may be true, but it's not important. Intel should not be expected to test its products on competing products, and thus it would be simply irresponsible of Intel to say that un-tested optimizations will work on said processors...anyone who has worked with compilers knows that this kind of stuff will get you into trouble later.
 
Did someone say Intel has an obligation to test their software on rival company processors? My question about the ethics was "Should someone make their software specifically fail just because a non Intel processor is attempting to run it?"

That is why I brought up the Dr Dos and Windows fiasco several years back. Something that is written to fail JUST BECAUSE you are not running a specific processor is shady.

What if Doom 3 was written so it would not run on an AMD chip. Not because the AMD chip was incapable of doing the job, but because ID just felt like adding a line to cause an error if the processor was not Intel.

Are we talking about some completely proprietary software here? Pls explain to me what a compiler is.
 
pantherdan: In the most general sense, compiler is a piece of software that translates one language into another. More commonly, a compiler is a piece of software that converts files from one programming language to a more primative one. In this specific case, icc is the C and C++ compiler produced by intel which translates text files containing C or C++ (high-level programming languages, written by programmers) code into x86 machine code. Of course the cpu can only exectue machine code and human programmers usually prefer to work in a high level language (though some still program in assembly, which is a slightly more readable and editable form of machine code).

As a programmer, this news doesn't make me happy, though I can think of one real reason for insisting on an intel cpu: codegen bugs. In my experience, codegen bugs cause more hassle and confusion than any other type of compiler bugs, if icc produces bent x86 machine code with these optimizations, then I could understand their decision to only run this code on cpus they've validated.

Compilers, especially the code generation subsystem, tend to be complex pieces of software, and no programmer wants to worry about code generation (many bugs can cause a compiler to generate incorrect code, code that calculates incorrect results or crashes despite a correct input program).
 
Originally posted by pantherdan
Did someone say Intel has an obligation to test their software on rival company processors? My question about the ethics was "Should someone make their software specifically fail just because a non Intel processor is attempting to run it?"
[...]
What if Doom 3 was written so it would not run on an AMD chip. Not because the AMD chip was incapable of doing the job, but because ID just felt like adding a line to cause an error if the processor was not Intel.
Click to expand...
The issue isn't one of ethics but economics. Intel is not breaking software so that it can't run on AMD processors; in fact, they're not doing anything at all, and that's what people seem to have a problem with. All the Intel compiler does is optimize certain code to run faster on Intel CPUs...it doesn't make it so that it runs inherently slower on other CPUs, it just doesn't speed it up either. It's not ethics...Intel doesn't want to spend the money to validate their compiler on competing technology, and so they don't, who can blame them?

I think the confusion lies in your statement that Intel is actually inserting code that makes the program run slower on AMD systems...which is incorrect. If you take out the optimization, both Intel and AMD procs get the same code, and they both work. With the optimization, Intel P4 procs get special code that has been tested to run faster in certain situations...as Monkeyshave said, this code probably bends the rules of x86 instruction coding, or it might just be specific to the way the P4 architecture has its cache set up. The point is that Intel cannot garauntee that this special code will run on every processor, and so they don't have their compilers make the changes on processors they haven't validated.

Am I happy that Intel doesn't valid on other platforms? No, but why would we expect them to? AMD doesn't even make compilers...if they want compilers that run optimized code on their cores, they should do it themselves, not expect their arch-rival to do it for them.
 
You must log in or register to reply here.
Back
Top