If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
Bill Davidsen wrote:
I assume that the ID string check takes place at compile time, and that running the compiler on a Intel CPU would produce the optimal code run anywhere. I find it hard to believe that they have two or more sets of code in the object file and incur the overhead of a runtime check and selection, just because the executable would be huge and slow on any CPU. So what we're talking here is that Intel compilers produce better code on Intel CPUs. It's a runtime check. It's absolutely required because even on Intel's own processors, not all instruction set extensions are supported. So Intel needs to detect which instructions are supported. The alternate paths aren't that large in size, but they are critical paths based on how often they are executed. Interesting to know if the "good" code would actually fail to run properly on some AMD CPU, letting Intel claim it was assuring reliable operation wherever run. Don't read that to mean I claim that, just technical curiosity. Intel came up with a system to check for instruction set extensions which it fails to follow itself! Yousuf Khan |
#12
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
On Jan 7, 1:49*am, Yousuf Khan wrote:
Bill Davidsen wrote: I assume that the ID string check takes place at compile time, and that running the compiler on a Intel CPU would produce the optimal code run anywhere. I find it hard to believe that they have two or more sets of code in the object file and incur the overhead of a runtime check and selection, just because the executable would be huge and slow on any CPU. So what we're talking here is that Intel compilers produce better code on Intel CPUs. It's a runtime check. It's absolutely required because even on Intel's own processors, not all instruction set extensions are supported. So Intel needs to detect which instructions are supported. The alternate paths aren't that large in size, but they are critical paths based on how often they are executed. Interesting to know if the "good" code would actually fail to run properly on some AMD CPU, letting Intel claim it was assuring reliable operation wherever run. Don't read that to mean I claim that, just technical curiosity. Intel came up with a system to check for instruction set extensions which it fails to follow itself! Keep it up, Yousuf. You're doing a great job of making both you and AMD look foolish and vindictive. Wouldn't it be great if Microsoft had a competitor like this. They could recompense all of us for all of the time we have spent trying to deal with their crippled software. So Intel made sure its compiler worked for its own processors but wasn't so careful with AMD. Like no one else in the business who's in a hurry and has limited resources does similar? Bottom line, if you had your way: Yousuf happy, lawyers rich, industry devastated. Good job. Robert. |
#13
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
shofar wrote:
In article , Yousuf Khan wrote: And as I said, FTC is going to make Intel pay to recompile and redistribute all of the software created on Intel compilers. That includes all of that Oracle software. That should cost Intel billions, just by itself! But, what are the odds that this is actually enforceable? It's the government, they determine what is enforceable or not. What does this mean for the average home user? Probably not much. Are only business apps affected? Mostly. Lots of users don't run a lot of heavy-weight apps. Say, Nero to burn discs or playing a game from one of many game developers. How does a user know if their software was compiled on an Intel computer - chances are that a lot of it was. The home user doesn't need to know, the company they bought their software from, will know what compiler they used to compile with. So if Nero was compiled with an Intel compiler, Nero's manufacturer will contact Intel, ask for some money back, etc. Most likely whether the corrected version gets to the end users is upto the app developer. They might advertise it as "New & Improved, now with enhancements for AMD processors". :-) Are all the developers going to make newly-compiled versions of their old software available for download or snail mail delivery? I doubt in most cases that it makes much of a difference to the performance of most apps. It's high-performance software that will be mostly affected. That's not as big a market as general-purpose applications, but it's an important segment. Retroactive how far back - certainly through XP? For however long the FTC can prove that there were these shenanigans going on. I'm sure it's going to simply mean all versions of the compiler going back to version X.Y.Z or something like that. You are right - it will cost Intel billions - if it happens. But, somehow, it just doesn't seem realistic with Windows already up to 7 and loads of new Linux distros freely available. Most Linux distros are not done with an Intel compiler, mostly with GNU. In the Windows world, most apps are also similarly not done with an Intel compiler, mainly a Microsoft one. Intel compilers are known to be a niche product compiler. Why would the developers spend a lot of time and effort, even if Intel pays for it, looking backwards? They probably won't bother to recompile older versions, but if they have new versions of the software in the works, then this may represent a very lucrative reduction in their R&D costs. I wouldn't feel too sorry for Intel for having to fork over this much cash for other people's developments, since it was their fault for purposefully screwing up in the first place. Yousuf Khan |
#14
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
Robert Myers wrote:
Keep it up, Yousuf. You're doing a great job of making both you and AMD look foolish and vindictive. Keep it up, Robert. You're doing a great job of licking Intel's nether regions. Wouldn't it be great if Microsoft had a competitor like this. They could recompense all of us for all of the time we have spent trying to deal with their crippled software. Microsoft killed all of their competitors already. It was too late for them. Fortunately, Intel got caught early enough. Of course, "early enough" in this case, means after only 25 years of having it their own way. I can think of at least 5 Intel x86 competitors over the years, all of whom are now gone. AMD is the last one left after all of this time. Cyrix is gone, NexGen is gone, Transmeta gone, NEC gone, etc. So Intel made sure its compiler worked for its own processors but wasn't so careful with AMD. Like no one else in the business who's in a hurry and has limited resources does similar? That's the spin-doctor way of making the truth more palatable. Intel wasn't simply "not careful", it was deliberate. In order to detect instruction set instructions for processors, Intel's own documentation said, all you need to do is detect certain flags in a register which are either turned on or turned off depending on whether an instruction set is supported or not. Nothing more, nothing less. What Intel did instead was detect whether the processor returned, "GenuineIntel" in the CPUID, and if it did, then it went to check the flags. You have no need to check "GenuineIntel" to look for the instruction set flags. Bottom line, if you had your way: Yousuf happy, lawyers rich, industry devastated. Good job. The industry is already a moribund devastated industry ever since Intel took up its position as the Mammoth that stands on this ground. PCs have not evolved much since the 80's. With the Mammoth moved out of the way, new life can take hold now. Lawyers will be rich no matter what. Yousuf Khan |
#15
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
On Jan 7, 5:29*pm, Yousuf Khan wrote:
Robert Myers wrote: Keep it up, Yousuf. *You're doing a great job of making both you and AMD look foolish and vindictive. Keep it up, Robert. You're doing a great job of licking Intel's nether regions. Time to start reporting you for abuse, too? Crude speech is the last resort of the desperate. Wouldn't it be great if Microsoft had a competitor like this. They could recompense all of us for all of the time we have spent trying to deal with their crippled software. Microsoft killed all of their competitors already. It was too late for them. Fortunately, Intel got caught early enough. Of course, "early enough" in this case, means after only 25 years of having it their own way. I can think of at least 5 Intel x86 competitors over the years, all of whom are now gone. AMD is the last one left after all of this time. Cyrix is gone, NexGen is gone, Transmeta gone, NEC gone, etc. So Intel made sure its compiler worked for its own processors but wasn't so careful with AMD. *Like no one else in the business who's in a hurry and has limited resources does similar? That's the spin-doctor way of making the truth more palatable. Intel wasn't simply "not careful", it was deliberate. In order to detect instruction set instructions for processors, Intel's own documentation said, all you need to do is detect certain flags in a register which are either turned on or turned off depending on whether an instruction set is supported or not. *Nothing more, nothing less. What Intel did instead was detect whether the processor returned, "GenuineIntel" in the CPUID, and if it did, then it went to check the flags. You have no need to check "GenuineIntel" to look for the instruction set flags. Listen. I'm one of the bluntest people on the face of the earth. I don't do with BS, not yours, not Intel's, not anybody's. If you want to find out how blunt I can be, eventually you will. Some weenie at Intel did what was easiest, or some manager at Intel told a weenie to do it some way or other. Get a life, Yousuf. There was no board meeting about this. I'm sick of your finger-pointing. Push hard enough, and I'll speculate as to where all this moral certainty comes from, any you won't like it one little bit. Bottom line, if you had your way: Yousuf happy, lawyers rich, industry devastated. Good job. The industry is already a moribund devastated industry ever since Intel took up its position as the Mammoth that stands on this ground. PCs have not evolved much since the 80's. With the Mammoth moved out of the way, new life can take hold now. That's not spin. That's delusion. Robert. |
#16
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
On Jan 7, 1:41*am, Yousuf Khan wrote:
Robert Myers wrote: On Jan 4, 7:42 pm, Yousuf Khan wrote: Robert Myers wrote: I'm sure that you'll come back with all kinds of moralistic bluster. That's the price I pay for responding to your posts. Sure, if you want to call legal-findings to be moralistic bluster, then go right ahead. As soon as the regulatory authorities present their credentials as God, then I will be interested in their moral opinions. *Until then, they are just another political institution, so far as I'm concerned. Ah, I see, only God is worthy to judge Intel now. Intel is beyond the realm of mere mortal institutions such as courts and governments. :-) Human institutions are just that. Human institutions will do what they will do, and what they will do depends a great deal on who you are and where you are. If I were Tim Geithner, I could evade income taxes, play a leading role in one of the worst financial meltdowns in memorty, and go on to be Secretary of the Treasury. If I went most anywhere north of India or slightly to the east or west, I wouldn't want to deal with any of the human institutions there. Human institutions will do what they will do. That what human institutions do has anything at all to do with morality is pure circumstance and perception. Whether I agree with perceptions or not hardly matters, and that you endorse them carries no weight with me. If Intel deliberately and blatantly misled customers into believing that they should buy and use Intel compilers for AMD processors, knowing full well that the compiler is crippled for said processors, that's potentially criminal commercial fraud. *I don't know that any such thing has been proven. That's "potentially criminal commercial fraud", you think? Has it been proven in court? You bet it has, as I said this is not a new accusation, and you can be sure that the EU which has already ruled against Intel has found it guilty on that point too. AMD had already included the accusation in its original 2005 civil anti-trust filing against Intel. That filing pre-dated the EU ruling. Here's an article from 2005: If you don't understand the difference between a civil and a criminal plea, I don't know why I'm wasting my time with you. Does Intel's compiler cripple AMD performance? - The Tech Reporthttp://techreport.com/discussions.x/8547 You don't read, do you? When a philosopher was told of Godel's result that there are true theorems that can't be proven (or else you can prove everything), he responded, "Well, who ever would have thought otherwise?" I've told you, and I'm telling you for the last time. Intel compilers do better with Intel processors? Well, who ever would have thought otherwise? Why else would Intel fool around with compilers? Are your Intel rose-tinted glasses finally starting to get a little scratchy, now that software integrity is involved? The FTC is ready to make Intel pay compensation to software developers which used Intel's compilers for recompiling and redistributing all of their software. Too bad the FTC never protected me from anything that matters. From my experience, icc does enough better than gcc that it is worth using it, but it doesn't do wildly better in most cases. *Either the compiler wasn't all that crippled, or it did even worse than gcc. *If someone didn't even bother to test whether icc was worth the bother relative to gcc, then I hardly know what to say. *At that, it was widely known that icc was not the best compiler for AMD processors. If I wanted to compile for Windows and not for Linux, I'd be using a compiler from Microsoft. *Before I even *considered* an Intel compiler, I'd test it against a compiler from Microsoft. *You seem to live in a world where ordinary common sense is suspended. Oracle has been using Intel compilers since 2003. Intel programming tools edge forward - CNET News "Database giant Oracle has chosen Intel to supply crucial programming tools called compilers for creating software that runs on servers using Intel processors. The move is one of several steps Intel is taking to improve the software's utility. "http://news.cnet.com/Intel-programming-tools-edge-forward/2100-1007_3... When I approached Oracle about software, they tied to encourage me *very strongly* to buy from Dell. Do you think there's the possibility of a connection, and that not all application providers were equally naive? But, now that you mention it, Oracle may be one of AMD's targets here. Not to worry about Microsoft. *They* weren't using Intel compilers. Robert. |
#17
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
My 2cents. In ICC 10 (IIRC 9 too) you could require the use of an SSE set so
the compiler won't create paths for lower SSE sets (app compiled for SSE3 won't run on a SSE2 CPU). Doing this was faster on my A64x2 instead of letting SSE3 code be optional. Intel took this option out for non-Intel processors in ICC11 though. And I've yet to find an instance where MS's compiler was faster than ICC. |
#18
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
Jim wrote:
My 2cents. In ICC 10 (IIRC 9 too) you could require the use of an SSE set so the compiler won't create paths for lower SSE sets (app compiled for SSE3 won't run on a SSE2 CPU). Doing this was faster on my A64x2 instead of letting SSE3 code be optional. Intel took this option out for non-Intel processors in ICC11 though. And I've yet to find an instance where MS's compiler was faster than ICC. I don't normally get any chance to bench ICC against MS, but I do against GCC, and I have to suspect that the code which runs worse on AMD is vector heavy. I don't have any serious apps which I want to use for that, and the integer and non-vector f.p. stuff are close enough to make little difference. |
#19
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
Yousuf Khan wrote:
Bill Davidsen wrote: I assume that the ID string check takes place at compile time, and that running the compiler on a Intel CPU would produce the optimal code run anywhere. I find it hard to believe that they have two or more sets of code in the object file and incur the overhead of a runtime check and selection, just because the executable would be huge and slow on any CPU. So what we're talking here is that Intel compilers produce better code on Intel CPUs. It's a runtime check. It's absolutely required because even on Intel's own processors, not all instruction set extensions are supported. So Intel needs to detect which instructions are supported. The alternate paths aren't that large in size, but they are critical paths based on how often they are executed. Interesting to know if the "good" code would actually fail to run properly on some AMD CPU, letting Intel claim it was assuring reliable operation wherever run. Don't read that to mean I claim that, just technical curiosity. Intel came up with a system to check for instruction set extensions which it fails to follow itself! I read an interesting post on this which said that the logic is this: if the CPU is Intel, the flags are checked, because the meaning of each bit is known. If not, the meaning of some bits as used by other vendors is not identical to Intel usage. Therefore, Intel chose to not use any vector stuff beyond mmx (or sse) rather than try to handle other vendor's use. Clearly you can call this an excuse, and Intel probably could have checked for at least some of the other vendors, assuming that within a vendor the bits are stable. I know there is/was one CPU vendor who used the bits Intel classified as either "unused" or "RFU" to mean something, but I don't remember what. There was code in some program I used which checked that. For modern 32/64 bit CPUs I doubt that's an issue, but I don't really know that everyone uses bits the way Intel does. Vendors in Pentium days (from memory), AMD, Cyrix, Transmeta, SiS, and at least one other. Hope someone remembers this stuff more clearly. In any case, if that claim is true, it's still a very dubious reason to avoid a more thorough check. |
#20
|
|||
|
|||
Intel Forced to Remove "Cripple AMD" Function from Compiler?
* Yousuf Khan:
And as I said, FTC is going to make Intel pay to recompile and redistribute all of the software created on Intel compilers. That includes all of that Oracle software. That should cost Intel billions, just by itself! Probably not. The majority of Windows apps is compiled with non-intel compilers, and even less in the Linux world. The intel compilers were common in the HPC field where their performance advantage does matter, but I guess most developers already patched out the relevant part to get full performance on AMD CPUs. Benjamin |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
"Forced" back to XP, loving it | journey | Dell Computers | 13 | July 9th 08 01:03 PM |
External Hard Drive And "Safely Remove Hardware" | Hammer | General | 4 | July 6th 08 09:35 PM |
What is the point of "Safely remove hardware" icon? | [email protected] | General | 15 | February 24th 06 03:03 AM |
Solution to HP Error "Remove and Check Cartridges" | [email protected] | Printers | 1 | February 19th 06 04:26 PM |
Unable to find the video driver program from "ADD/Remove Programs" dialog box | slee15 | Homebuilt PC's | 18 | October 26th 05 09:00 PM |