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

Printable View

Show 100 post(s) from this thread on one page

01-03-2010, 01:54 AM
alfaunits

Quote:

Originally Posted by keithlm

Apparently you don't completely understand what is being discussed.

Apparently you don't understand that people don't see things equally - otherwise we would all be robots with the same mind set.

Quote:

You are not correct. It is not Intels job to to take on the responsibility of the non-Intel CPU manufacturer.

You are totally twisting my words. It is Intel's job simply to make sure the ICC code works on non-Intel CPUs (or say it doesn't work). Period.

Quote:

Nobody is suggesting that Intel allow non-Intel chips to use the Intel specific code.

Actually you (AMD side) ARE suggesting this.
SSE2/3/4/etc. code from ICC is Intel specific code. Memory alignment and other factors, as I have stated several times, are INTEL SPECIFIC with ICC compiled code - they do not work the same way on non-Intel chips.
Sure, a lot of time they do work well - but there are times where this Intel code would also work slower, and much slower than what you currently call "crippling". Then again, we would have this conversation! It doesn't matter what Intel did - if it isn't good for AMD, the AMD side would always bash it.
Be it a separate code path for non-Intel CPUs or Intel code path for non-Intel CPUs that sometimes gives waay lower perf. on AMD CPUs. (Yes I have seen this in ~ICC8 days)

Quote:

What is being suggested is that Intel allow the non-Intel chips to use the most efficient/fastest non-Intel versions available. Currently they don't do that.

ROFL! You just shot yourself in the foot there ;) And you don't even realize it...
What ICC does give non-Intel CPUs is a single code path is not Intel version - so that IS the fastest version available.
It's also the fastest code compiled for non-Intel CPUs in most cases.
If we continue with your mindset, GCC/MSVC should be sued for not providing the most efficient code on all CPUs.

Quote:

Actually it IS there job to make sure their code works on non-Intel CPU.

Yes - but ONLY to make sure it works (just that it WORKS - not good, not fast, not fastest... just WORKS).
If you don't agree with me here, please rephrase your English, because your words do say you agree with me.

Quote:

When they do that job they need to use the best instruction set that is supported by each CPU regardless of brand.

Wo wo wo... where does it say that? Did they claim it would do that?

Quote:

Some people are purposefully forgetting that Intel has claimed this support and accepted the task.

WHERE?
Please tell me where it says so.. I will say I am wrong, but if you had this piece of text from Intel, noone here would disagree with you.

Quote:

Or they claim that Intel doesn't need to do the best job possible. (I.e., they are advocating that it is acceptable for Intel to be incompetent.)

For the... donno what number of times... it is acceptable for Intel not to give a f*** about how fast ICC works on non-Intel CPUs. It just needs to work without errors.

Quote:

None of the things you mention allow them to purposefully cripple the competition. If they don't want to support non-Intel they need to specifically drop all non-Intel support.

We all agree on this - we just don't agree what "cripple" means!
Now, provide me with the text you say you have (read 2 paragraphs above), and we will agree on "cripple" then.
If you don't have that text however, what should we do?

Quote:

ANSWER: Since they claim to support non-Intel CPU.

We don't agree on what "supporting non-Intel CPUs" is again.

Quote:

EDIT: Actually I am amazed this can even be really debated in any meaningful way; no less 5 forum pages.

Actually I am surprised how civilized this thread has remained... it takes a few posts to for AMD-Intel thread to turn to flames, this one has stayed well within bounds.

Quote:

It's very simple: a bug was found with Intel's compiler. It needs to be fixed.

I wish the world worked in binary, but it doesn't.
01-03-2010, 02:16 AM
Mechanical Man

Quote:

Intel® C++ Compiler Professional Edition 11.1 Components:
The multithreading and optimization technologies in Intel®
compilers and libraries give the Professional Edition its edge in
helping you deliver high-performance applications for the latest
multicore processors.

http://software.intel.com/sites/prod...in_indepth.pdf

It gives the impression that those optimizations would be available also on other than Intel processors. That clearly is not the case. That is also what FTC is biching.

It would be different case if it read:

Quote:

Intel® C++ Compiler Professional Edition 11.1 Components:
The multithreading and optimization technologies in Intel®
compilers and libraries give the Professional Edition its edge in
helping you deliver high-performance applications for the latest Intel
multicore processors.

agree?
01-03-2010, 02:30 AM
kl0012

Quote:

Originally Posted by gosh

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:

How exactly this refutes what I said about /Qax switch.
BTW, accidentally I have ICC 8.0 installed. memcpy() func is implemented as intisinc there. Here is code generated with default options (no optimization):

Code:

int main() { char a[100], b[100]; memcpy(a, b, 100); return 0; }

Code:

00401010 push ebp 00401011 mov ebp,esp 00401013 sub esp,0C8h 00401019 push eax 0040101A push edi 0040101B push ecx 0040101C mov edi,ebp 0040101E sub edi,0C8h 00401024 mov ecx,32h 00401029 mov eax,0CCCCCCCCh 0040102E rep stos dword ptr [edi] 00401030 pop ecx 00401031 pop edi 00401032 pop eax 8: 9: char a[100], b[100]; 10: 11: memcpy(a, b, 100); 00401033 add esp,0F4h 00401036 lea eax,[a] 00401039 mov dword ptr [esp],eax 0040103C lea eax,[b] 00401042 mov dword ptr [esp+4],eax 00401046 mov dword ptr [esp+8],64h 0040104E call memcpy (00401070) memcpy: 00401070 push ebp 00401071 mov ebp,esp 00401073 push edi 00401074 push esi 00401075 mov esi,dword ptr [src] 00401078 mov ecx,dword ptr [count] 0040107B mov edi,dword ptr [dst] 0040107E mov eax,ecx 00401080 mov edx,ecx 00401082 add eax,esi 00401084 cmp edi,esi 00401086 jbe CopyUp (00401090) 00401088 cmp edi,eax 0040108A jb CopyDown (00401208) CopyUp: 00401090 test edi,3 00401096 jne CopyLeadUp (004010ac) 00401098 shr ecx,2 0040109B and edx,3 0040109E cmp ecx,8 004010A1 jb CopyUnwindUp (004010cc) 004010A3 rep movs dword ptr [edi],dword ptr [esi] 004010A5 jmp dword ptr [edx*4+4011B8h]

As you see, there is no cpu type check and multiple code paths. Also the copy function itself is implemented with double word copy.
01-03-2010, 02:33 AM
Mechanical Man

Can you show what code it produces if you compile it with optimizations?
01-03-2010, 02:49 AM
SocketMan

The Problem

A while ago I upgraded my copy of the Intel Fortran Compiler for Linux (to version 7.1.040, build 20040309Z). All seemed well, and the code compiled with the new version passed all of our unit tests. However, when we moved the new executables out to our compute farm they started segfaulting all over the place. What was going on?
The investigation

The code in question is several hundred thousand lines of old-style poorly commented Fortran 77, with a bit of C mixed in to make things more interesting. We've had problems before with compiler upgrades, so having the new compiler produce code which didn't work wasn't completely surprising. However, this one seemed odder than usual: the executables all seemed to pan out fine on the compile machine, but fail on the compute farm. Running gdb indicated that they segfaulted in a routine called __intel_cpu_dispatch_fail, which wasn't enormously productive. The stack trace showed which routine in our code led to the __intel_cpu_dispatch_fail segfault, but it was a pretty simple routine and there wasn't anything obviously wrong with it.

We've seen bugs with the Intel compilers before (and with other compilers too, I might add) where the optimiser caused problems. Sure enough, compiling with all of the optimisation flags turned off produced executables that ran perfectly fine across our collection of machines, albeit rather slowly. Reinstating the optimisation flags one-at-a-time revealed that the -xK flag was the culprit: if that was specified, the executables segfaulted on the compute farm, if not, they didn't.

The -xK flag to the 'ifc' compiler specifies that SSE instructions should be used (the equivalent to gcc's -fpmath=sse). If we compiled with -axK (produce both normal 386 code and SSE code and decide at runtime which to use), then all was OK. So, it looked like some sort of bug with the SSE code emitted by the compiler, so I was tempted simply to downgrade again and wait for the next version, which hopefully would have fixed the bug.

I cast a final eye over the last run on the compute farm, and noticed that while most of the machines segfaulted on the -ax code, a few didn't. Interestingly, the ones on which the code worked were all single-processor Pentium 4s, which the ones on which it crashed were all dual-processor Athlon MPs. Hmmm. It's either an SMP bug or an AMD bug, and I was interested enough to try and work out which.

Tracing the code up to the segfault on one of the Athlons, I found the smoking gun in an exponential routine:

(gdb) break vmlsExp4
Breakpoint 1 at 0x8106340
(gdb) run probe.dat probe.dat
Starting program: fastqmf probe.dat probe.dat

Breakpoint 1, 0x08106340 in vmlsExp4 ()
(gdb) disas
Dump of assembler code for function vmlsExp4:
0x08106340 <vmlsExp4+0> testl $0xffffff00,0xedb375c
0x0810634a <vmlsExp4+10> jne 0x8106760 <vmlsExp4.I>
0x08106350 <vmlsExp4+16> testl $0xffffff80,0xedb375c
0x0810635a <vmlsExp4+26> jne 0x8106464 <vmlsExp4.H>
0x08106360 <vmlsExp4+32> testl $0xffffffff,0xedb375c
0x0810636a <vmlsExp4+42> jne 0x816c9f8 <__intel_cpu_dispatch_fail>
0x08106370 <vmlsExp4+48> call 0x816c89a <__intel_cpu_indicator_init>
0x08106375 <vmlsExp4+53> jmp 0x8106340 <vmlsExp4>
0x08106377 <vmlsExp4+55> ret
End of assembler dump.

vmlsExp4 is (I managed to work out) the vectorised exponential routine. What this code does is check the bits of a global variable. If it's 0x100 or greater, then call vmlsExp4.I (which contains SSE2 code), otherwise if it's 0x80 or greater, call vmlsExp4.H (which contains SSE code), otherwise if it's 0 call __intel_cpu_indicator_init, otherwise call __intel_cpu_dispatch_fail (which simply segfaults nastily by doing a 'movl $0x1,0x0').

Looking at __intel_cpu_indicator_init, it goes and checks the various processor capabilities and sets the global variable at 0xedb375c to a value depending on the processor capabilities. If you can do SSE2, the value is 0x200. If you can only do SSE1, you get 0x80, and so on. If you can't do anything, you get the value 0x1. What is odd is that the Athlon chips can do SSE quite happily, but seem to end up with a value 0x1 anyway. Tracing through the code on a P4 and an Athlon revealed the culprit (in __intel_cpu_indicator_init).

15f: 0f a2 cpuid
161: 89 45 fc mov %eax,0xfffffffc(%ebp)
164: 89 5d f8 mov %ebx,0xfffffff8(%ebp)
167: 89 4d f4 mov %ecx,0xfffffff4(%ebp)
16a: 89 55 f0 mov %edx,0xfffffff0(%ebp)
(snip)
19f: 8b 45 f8 mov 0xfffffff8(%ebp),%eax
1a2: 3d 47 65 6e 75 cmp $0x756e6547,%eax
1a7: bb 01 00 00 00 mov $0x1,%ebx
1ac: 75 18 jne 1c6 <__intel_cpu_indicator_init+0x8c>
1ae: 8b 45 f0 mov 0xfffffff0(%ebp),%eax
1b1: 3d 69 6e 65 49 cmp $0x49656e69,%eax
1b6: 75 0e jne 1c6 <__intel_cpu_indicator_init+0x8c>
1b8: 8b 45 f4 mov 0xfffffff4(%ebp),%eax
1bb: 3d 6e 74 65 6c cmp $0x6c65746e,%eax
1c0: 75 04 jne 1c6 <__intel_cpu_indicator_init+0x8c>

The 'cpuid' call here puts the CPU manufacturer's ID in ebx:edx:ecx. The 'cmp' instructions later then check that these values were 'Genu','ineI','ntel' (i.e. 'GeniuneIntel'). If not, then we jump off to a bit of code that doesn't even pretend to check for the CPU capabilities but instead returns 0x1 (i.e it's a 386, and nothing other than the bog-standard 386 instruction set is available).

Think about what this means. The code produced by the Intel compiler checks to see if it's running on an Intel chip. If not, it deliberately won't run SSE or SSE2 code, even if the chip capability flags (available through the 'cpuid' instruction) say that it can. In other words, the code has been nobbled to run slower on non-Intel chips.
Talking to Intel

I raised this with Intel through their compiler support forums. The initial response from Intel was that

The most recent update of 8.0 compilers should have fixed the run-time issue with -xW and -xK on AMD processors. I don't believe the fix has been carried back to 7.1. It's not deliberate, it's an oversight, due to AMD processors not being supported or tested with those options.

followed later (after some discussion) by

As Tim correctly pointed out, this was a bug introduced into the vector math library. It is fixed in the current 8.0 compilers. There are no plans to fix it for 7.1.

http://www.swallowtail.org/naughty-intel.shtml

That's just one example out of many.It's unlikely that FTC is
"pushing" this case without any evidence.
Of course we can say that it's just a bug and was not intentional - but just like the saying goes fool me once shame
on you fool me twice shame on me.
01-03-2010, 03:57 AM
Hornet331

Quote:

Originally Posted by Mechanical Man

It gives the impression that those optimizations would be available also on other than Intel processors. That clearly is not the case. That is also what FTC is biching.

It would be different case if it read:

agree?

In the normal product brief, they state so:

Quote:

The Intel® C++ Compiler Professional Edition 11.1 for Windows* delivers
advanced capabilities for development of application parallelism and winning
performance for the full range of Intel® processor-based platforms. It includes
the compiler’s breadth of advanced optimization, multithreading, and processor
support, as well as automatic processor dispatch, vectorization, and loop
unrolling. It also has highly optimized C++ templates for parallelism, math
processing, and multimedia libraries. Try it and see for yourself. Download
an eval copy right now: www.intel.com/software/products/compilers/cwin

http://software.intel.com/sites/prod...cwin_brief.pdf

Also i think you skiped the first paragraph where they mentioned what is included:

Quote:

The product includes:
• Intel® C++ Compiler for Windows for IA-32, Intel® 64,
and IA-64 architectures
01-03-2010, 04:00 AM
kl0012

Quote:

Originally Posted by Mechanical Man

Can you show what code it produces if you compile it with optimizations?

With /QaxW option - as expected:

Code:

00401010 > > F705 04A74000 >TEST DWORD PTR DS:[___intel_cpu_indicator],FFFFFE00 0040101A . 0F85 24000000 JNZ test.00401044 00401020 . F705 04A74000 >TEST DWORD PTR DS:[___intel_cpu_indicator],FFFFFFFF 0040102A . 0F85 38010000 JNZ test.00401168 00401030 . E8 33320000 CALL test.___intel_cpu_indicator_init 00401035 .^EB D9 JMP SHORT test._main 00401037 . C3 RETN 00404268 >/$ 50 PUSH EAX 00404269 |. 52 PUSH EDX 0040426A |. 51 PUSH ECX 0040426B |. 53 PUSH EBX 0040426C |. 57 PUSH EDI 0040426D |. 56 PUSH ESI 0040426E |. 55 PUSH EBP 0040426F |. 8BEC MOV EBP,ESP 00404271 |. 83EC 50 SUB ESP,50 00404274 |. 9C PUSHFD 00404275 |. 58 POP EAX 00404276 |. 8BC8 MOV ECX,EAX 00404278 |. 35 00002000 XOR EAX,200000 0040427D |. 50 PUSH EAX 0040427E |. 9D POPFD 0040427F |. 9C PUSHFD 00404280 |. 58 POP EAX 00404281 |. 3BC1 CMP EAX,ECX 00404283 |. 0F84 2A000000 JE test.004042B3 00404289 |. 51 PUSH ECX 0040428A |. 9D POPFD 0040428B |. 33C0 XOR EAX,EAX 0040428D |. 0FA2 CPUID 0040428F |. 8945 FC MOV DWORD PTR SS:[EBP-4],EAX 00404292 |. 895D F8 MOV DWORD PTR SS:[EBP-8],EBX 00404295 |. 894D F4 MOV DWORD PTR SS:[EBP-C],ECX 00404298 |. 8955 F0 MOV DWORD PTR SS:[EBP-10],EDX 0040429B |. B8 01000000 MOV EAX,1 004042A0 |. 0FA2 CPUID 004042A2 |. 8945 EC MOV DWORD PTR SS:[EBP-14],EAX 004042A5 |. 895D E8 MOV DWORD PTR SS:[EBP-18],EBX 004042A8 |. 894D E4 MOV DWORD PTR SS:[EBP-1C],ECX 004042AB |. 8955 E0 MOV DWORD PTR SS:[EBP-20],EDX 004042AE |. E9 1A000000 JMP test.004042CD 004042B3 |> 33C0 XOR EAX,EAX 004042B5 |. 8945 FC MOV DWORD PTR SS:[EBP-4],EAX 004042B8 |. 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX 004042BB |. 8945 F4 MOV DWORD PTR SS:[EBP-C],EAX 004042BE |. 8945 F0 MOV DWORD PTR SS:[EBP-10],EAX 004042C1 |. 8945 EC MOV DWORD PTR SS:[EBP-14],EAX 004042C4 |. 8945 E8 MOV DWORD PTR SS:[EBP-18],EAX 004042C7 |. 8945 E4 MOV DWORD PTR SS:[EBP-1C],EAX 004042CA |. 8945 E0 MOV DWORD PTR SS:[EBP-20],EAX 004042CD |> 8B55 F8 MOV EDX,DWORD PTR SS:[EBP-8] 004042D0 |. 81FA 47656E75 CMP EDX,756E6547 .............. .............. 00404239 |> 8BC8 MOV ECX,EAX 0040423B |. C1E0 08 SHL EAX,8 0040423E |. 03C1 ADD EAX,ECX 00404240 |. 8BC8 MOV ECX,EAX 00404242 |. C1E0 10 SHL EAX,10 00404245 |. 03C1 ADD EAX,ECX 00404247 |. 8BCA MOV ECX,EDX 00404249 |. 83E2 03 AND EDX,3 0040424C |. C1E9 02 SHR ECX,2 0040424F |. 74 06 JE SHORT test.00404257 00404251 |. F3:AB REP STOS DWORD PTR ES:[EDI] 00404253 |. 85D2 TEST EDX,EDX 00404255 |. 74 06 JE SHORT test.0040425D
01-03-2010, 04:12 AM
alfaunits

Quote:

Originally Posted by Mechanical Man

It gives the impression that those optimizations would be available also on other than Intel processors. That clearly is not the case. That is also what FTC is biching.
It would be different case if it read:
agree?

No. It does provide high-performance applications. In msot cases it provides a faster than compiled-by-the-rest applications.
The fact that you wish to think it provides the best possible always suggests you never heard of marketing.
01-03-2010, 04:16 AM
alfaunits

When you quote someone, put it in quotes. Otherwise you allude that these are your words, and I would attack them directly.

This does not prove anything. We're still mixing what "cripple" means.
App didn't work on MAD, now it does. Fixed bug. Case closed.

Quote:

Originally Posted by SocketMan

The Problem
<snip>
http://www.swallowtail.org/naughty-intel.shtml
01-03-2010, 07:17 AM
kl0012

Quote:

Originally Posted by STEvil

Found it:

This is version 8 though, no telling if current versions so this as well or its been fixed since then.

http://www.swallowtail.org/naughty-intel.shtml

Quote:

but calls to the vectorised single-precision math instrinsics will use SSE, not SSE2.

Somehow I miss the meaning of the above. The main diff between SSE to SSE2 is that SSE2 supports double precission vector calc while SSE supports only single precission vector calc. So if you need to calculate single precission values, you actually don't need SSE2. Also -xW switch does not generate multiple code paths - only check for supported instructions.
01-03-2010, 09:14 AM
keithlm

Quote:

Originally Posted by alfaunits

Actually I am surprised how civilized this thread has remained... it takes a few posts to for AMD-Intel thread to turn to flames, this one has stayed well within bounds.

In fact the only person that seems to be getting emotional is.... you.

And yes... we can easily determine from your posts that you have no problem advocating that Intel be incompetent. That is your opinion. But don't be surprised when people do not agree with you.

A professional company that claims something needs to follow through on that claim. If they don't they are being incompetent. You have no problem accepting incompetence. Other people will not find that to be acceptable.

Let's review the Intel response that Socketman received: (And others if you care to do the research)

Quote:

The most recent update of 8.0 compilers should have fixed the run-time issue with -xW and -xK on AMD processors. I don't believe the fix has been carried back to 7.1. It's not deliberate, it's an oversight, due to AMD processors not being supported or tested with those options.

You mean that Intel doesn't actually test each option on each non-Intel compiler? That kind of totally undermines one of the main things you keep using as an argument.

In addition you'll notice that Intel did say they fixed this incorrect behavior. (But people continually find that they have not.) How can anybody argue against what Intel has already recognized as a bug?
01-03-2010, 01:43 PM
STEvil

Quote:

Originally Posted by kl0012

Somehow I miss the meaning of the above. The main diff between SSE to SSE2 is that SSE2 supports double precission vector calc while SSE supports only single precission vector calc. So if you need to calculate single precission values, you actually don't need SSE2. Also -xW switch does not generate multiple code paths - only check for supported instructions.

Does SSE2 support single precision calcs?
01-03-2010, 04:19 PM
initialised

Quote:

Originally Posted by alfaunits

You do know there is a "workaround" for ICC as well? A forced instruction set compile?

Errr, actually it's ridicolously easier to do the patch for this. Waaay easier than nVidia PhysX hax.

Say you buy an application that was complied using the compiler that gimps AMD/Cyrix/Transmeta/Via CPUs and don't have access to the source code. How does the end user with the wrong CPU patch this?
01-03-2010, 04:23 PM
informal

Quote:

Originally Posted by initialised

How does the end user with the wrong CPU patch this?

He can't do anything... He's stuck.
01-03-2010, 04:30 PM
STEvil

Quote:

Originally Posted by initialised

Say you buy an application that was complied using the compiler that gimps AMD/Cyrix/Transmeta/Via CPUs and don't have access to the source code. How does the end user with the wrong CPU patch this?

The same way you remove a CD/timer check. The average user doesnt know this.

edit - should mention that depends how it was gimped. Some are fixable some are not.
01-04-2010, 02:17 AM
alfaunits

You misinterpret me.
If that code doesn't work on AMD, that's a bug. Plain and simple. v8.0? We are v11.0 now. Check if it doesn't work, then come back to report the bug.
I would not defend Intel on this, if they didn't fix it.

I am only defending the stand on whether the apps compiled with multiple code paths should execute the most optimized code on AMD systems. Intel never said they will. That's not incompetence.

Those are two TOTALLY different things.

Quote:

Originally Posted by keithlm

In fact the only person that seems to be getting emotional is.... you.

And yes... we can easily determine from your posts that you have no problem advocating that Intel be incompetent. That is your opinion. But don't be surprised when people do not agree with you.

A professional company that claims something needs to follow through on that claim. If they don't they are being incompetent. You have no problem accepting incompetence. Other people will not find that to be acceptable.

Let's review the Intel response that Socketman received: (And others if you care to do the research)

You mean that Intel doesn't actually test each option on each non-Intel compiler? That kind of totally undermines one of the main things you keep using as an argument.

In addition you'll notice that Intel did say they fixed this incorrect behavior. (But people continually find that they have not.) How can anybody argue against what Intel has already recognized as a bug?
01-04-2010, 08:30 AM
keithlm

Quote:

Originally Posted by alfaunits

You misinterpret me.
If that code doesn't work on AMD, that's a bug. Plain and simple. v8.0? We are v11.0 now. Check if it doesn't work, then come back to report the bug.
I would not defend Intel on this, if they didn't fix it.

I am only defending the stand on whether the apps compiled with multiple code paths should execute the most optimized code on AMD systems. Intel never said they will. That's not incompetence.

Those are two TOTALLY different things.

BTW: See links in the very first post of this thread which discuss compiler version 11.1.054.

Intel does not need to run the most optimized code path they have available on all processors. However they do need to run the most optimized code path available that any particular processor supports.

Those are also two totally different things.
01-04-2010, 09:02 AM
alfaunits

Quote:

Originally Posted by keithlm

Intel does not need to run the most optimized code path they have available on all processors. However they do need to run the most optimized code path available that any particular processor supports.

Those are also two totally different things.

I don't agree they have to. That's the whole didagreement in this thread (between AMD and Intel "sides").
Now if Intel said they will, that's different, but I don't see anyone posting any proof of that?

FTC statement does not actually require Intel to do that.
01-04-2010, 09:40 AM
Solus Corvus

Whether or not intel says they will use the most optimal code path on any given processor - not doing so is a sub-optimal design.
01-04-2010, 06:02 PM
oohms

Quote:

Originally Posted by Solus Corvus

Whether or not intel says they will use the most optimal code path on any given processor - not doing so is a sub-optimal design.

This thread is going around in circles. Alfaunits has already answered that, and to me it makes perfect sense. If the intel compiler is faster than GCC with non intel processors, and running intel code is unreliable on non intel cpus, then what is the issue :confused:

Quote:

Originally Posted by alfaunits

Actually you (AMD side) ARE suggesting this.
SSE2/3/4/etc. code from ICC is Intel specific code. Memory alignment and other factors, as I have stated several times, are INTEL SPECIFIC with ICC compiled code - they do not work the same way on non-Intel chips.
Sure, a lot of time they do work well - but there are times where this Intel code would also work slower, and much slower than what you currently call "crippling". Then again, we would have this conversation! It doesn't matter what Intel did - if it isn't good for AMD, the AMD side would always bash it.
Be it a separate code path for non-Intel CPUs or Intel code path for non-Intel CPUs that sometimes gives waay lower perf. on AMD CPUs. (Yes I have seen this in ~ICC8 days)

What ICC does give non-Intel CPUs is a single code path is not Intel version - so that IS the fastest version available.
It's also the fastest code compiled for non-Intel CPUs in most cases.
If we continue with your mindset, GCC/MSVC should be sued for not providing the most efficient code on all CPUs.
01-04-2010, 07:12 PM
Solus Corvus

Quote:

Originally Posted by oohms

This thread is going around in circles. Alfaunits has already answered that, and to me it makes perfect sense. If the intel compiler is faster than GCC with non intel processors, and running intel code is unreliable on non intel cpus, then what is the issue :confused:

No, it's not unreliable. Code compiled with intel only optimizations forced with switches at compile time runs fine with other cpus. There are some corner cases where optimized code might run slower on non-intel cpus then unoptimized code, but unoptimized code runs slower the vast majority of the time.

Like I said, it's not a big deal because you can change the default behavior with switches. But I just think it's funny that all the intel guys had to step in and defend a bad design choice.
01-05-2010, 03:36 AM
alfaunits

If Intel did it the other way (run the same code), we'd still have complaints saying it doesn't run optimal all the time. Words would be different, but complaints would be the same.
That's just how things work :(

Quote:

Originally Posted by Solus Corvus

No, it's not unreliable. Code compiled with intel only optimizations forced with switches at compile time runs fine with other cpus. There are some corner cases where optimized code might run slower on non-intel cpus then unoptimized code, but unoptimized code runs slower the vast majority of the time.

Like I said, it's not a big deal because you can change the default behavior with switches. But I just think it's funny that all the intel guys had to step in and defend a bad design choice.
01-05-2010, 09:35 AM
savantu

Quote:

Originally Posted by Solus Corvus

No, it's not unreliable. Code compiled with intel only optimizations forced with switches at compile time runs fine with other cpus. There are some corner cases where optimized code might run slower on non-intel cpus then unoptimized code, but unoptimized code runs slower the vast majority of the time.

Like I said, it's not a big deal because you can change the default behavior with switches. But I just think it's funny that all the intel guys had to step in and defend a bad design choice.

It is not a bad design choice; it is actually needed.

Intel's compiler specifically targets Intel cpus thus is fully aware of what goes well on each of those cpus. I am talking about instruction bundling and latencies. Even among Intel cpus, there are significant differences in latencies for the same instructionsn not to mention how they digest bundles ( micro and macro uops ).
That's why the compiler needs to check what CPU it runs on, so that it can optimize for a P6 based uarch, Netburst, Core or Nehalem. In the text book you are advised on what flags to use for what uarch.

What about supporting other CPUs, like AMD ones ? Why should Intel care and spend million of manhours learning instruction latencies and optimal bundles for AMD CPUs ? Is AMD willing to pay for that ? Obviously not.

It isn't simply a case of having SSE flags enabled or not, the compiler goes much further than that. It isn't aware of the insides of an AMD CPU and has as many options as Intel uarchs there are. Wich one is best suited for AMD CPUs ? Is it P6, is it Core? Maybe Penryn or Nehalem ? How many corner cases are there where instruction bundles optimized for Core will crap on K10
? More than a few.
AMD and Intel have in common one thing; basic 386 uarch. Intel knows that on that code, there won't be any problem since it's the common root. From that one, the implementations differ.
Why should Intel have to support a competitor's implementation free of charge ?
01-05-2010, 11:00 AM
Solus Corvus

Quote:

Originally Posted by alfaunits

If Intel did it the other way (run the same code), we'd still have complaints saying it doesn't run optimal all the time. Words would be different, but complaints would be the same.
That's just how things work :(

What basis would there be for complaint? Nobody is complaining that Intel processors run MS and GCC compiled code faster.

Of course there will always be irrational people that will complain about anything. But that's not a reason to not do the right thing.

Quote:

Originally Posted by savantu

It is not a bad design choice; it is actually needed.

Intel's compiler specifically targets Intel cpus thus is fully aware of what goes well on each of those cpus. I am talking about instruction bundling and latencies. Even among Intel cpus, there are significant differences in latencies for the same instructionsn not to mention how they digest bundles ( micro and macro uops ).
That's why the compiler needs to check what CPU it runs on, so that it can optimize for a P6 based uarch, Netburst, Core or Nehalem. In the text book you are advised on what flags to use for what uarch.

What about supporting other CPUs, like AMD ones ? Why should Intel care and spend million of manhours learning instruction latencies and optimal bundles for AMD CPUs ? Is AMD willing to pay for that ? Obviously not.

It isn't simply a case of having SSE flags enabled or not, the compiler goes much further than that. It isn't aware of the insides of an AMD CPU and has as many options as Intel uarchs there are. Wich one is best suited for AMD CPUs ? Is it P6, is it Core? Maybe Penryn or Nehalem ? How many corner cases are there where instruction bundles optimized for Core will crap on K10
? More than a few.
AMD and Intel have in common one thing; basic 386 uarch. Intel knows that on that code, there won't be any problem since it's the common root. From that one, the implementations differ.
Why should Intel have to support a competitor's implementation free of charge ?

Are you actually trying to argue that there is no optimization middle ground that could be a safe default between basic 386 and an all out latency/memory/cache/grouping SSE4.2 superset? I know that's not the case and I'm sure you do too. An Intel specific optimization might run slower on other cpus for specific cases - but basic x86 is guaranteed to run slow all of the time.

As to the rest of your premise, it is easily disproved. Take a linux app and compile it with all the icc optimizations and run it on an AMD machine. Then compare that with the default icc output on an AMD machine. Back when I had an AMD machine the former always produced a faster program. I invite you to give it a try.
01-05-2010, 11:12 AM
Hornet331

Actually i think the worse fallback since icc 10 is sse2. Its quite logical since this is mandatory anyways to run any modern windows os.

Show 100 post(s) from this thread on one page