![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
Intel's malpractices continue ...
- Thread starter athlonfx
- Start date
robberbaron
Supreme [H]ardness
- Joined
- Sep 6, 2004
- Messages
- 6,101
An accusation, not a fact. We'll se what our wonderful 
judicial system has to say about it.
judicial system has to say about it.It's pretty sad that junk like that gets posted. There are thoughtful and accurate articles about the real problem. That story isn't one of the thoughtful ones.
15 second summary:
Certain versions of intel's compiliers generate code that checks for the "genuine intel" processor name string. If it matches, the full code path, including SSE/SSE2/SSE3 optimizations, is run. For all other processors, a default path is run instead. A single exe can contain more than one code path since not all processors support all optimizations. There are several work-arounds for this and it has been fixed in the current version.
---
The inaccuracy is that Intel doesn't generate slower code when it detects an AMD processor. The compiler compiles the same on either Intel or AMD chips. Intel simply *doesn't* optimize for AMD processors. Another thing is that the Intel C Compiler isn't nearly as widely used as MS VC++ and GCC. So why is AMD complaining? Because 1) AMD uses the Intel compiler for SPEC submissions since it generates the fastest code for both the P4 and A64, and 2) AMD threw everything and the kitchen sink into the complaint, including things both the US and EU FTCs found no problems with 2 and 3 years ago, respectively (both agencies threw out AMD complaints in 2003 and 2002).
And why does an obvious troll post belong here anyways?
15 second summary:
Certain versions of intel's compiliers generate code that checks for the "genuine intel" processor name string. If it matches, the full code path, including SSE/SSE2/SSE3 optimizations, is run. For all other processors, a default path is run instead. A single exe can contain more than one code path since not all processors support all optimizations. There are several work-arounds for this and it has been fixed in the current version.
---
The inaccuracy is that Intel doesn't generate slower code when it detects an AMD processor. The compiler compiles the same on either Intel or AMD chips. Intel simply *doesn't* optimize for AMD processors. Another thing is that the Intel C Compiler isn't nearly as widely used as MS VC++ and GCC. So why is AMD complaining? Because 1) AMD uses the Intel compiler for SPEC submissions since it generates the fastest code for both the P4 and A64, and 2) AMD threw everything and the kitchen sink into the complaint, including things both the US and EU FTCs found no problems with 2 and 3 years ago, respectively (both agencies threw out AMD complaints in 2003 and 2002).
And why does an obvious troll post belong here anyways?
I'm not trying to make a flame war, troll post, or anything like that ... The thread title might've been a little harsh, but whatever ...
Well, this is what the ARTICLE says:
Intel's compilers recognise when they're running on an AMD processor, and generates code that either degrades performance or causes it to crash. That's one of the many accusations in AMD's lengthy document of complaints against Intel in its recent lawsuit against the chip giant.
The paragraph in question, number 123, reads:
"Intel has designed its compiler purposely to degrade performance when a program is run on an AMD platform. To achieve this, Intel designed the compiler to compile code along several alternate code paths. Some paths are executed when the program runs on an Intel platform and others are executed when the program is operated on a computer with an AMD microprocessor. (The choice of code path is determined when the program is started, using a feature known as “CPUID” which identifies the computer’s microprocessor.) By design, the code paths were not created equally. If the program detects a “Genuine Intel” microprocessor, it executes a fully optimized code path and operates with the maximum efficiency. However, if the program detects an “Authentic AMD” microprocessor, it executes a different code path that will degrade the program’s performance or cause it to crash."
I'm sure AMD has evidence of this happening, otherwise why would they write BS in their 48 page report?
Well, this is what the ARTICLE says:
Intel's compilers recognise when they're running on an AMD processor, and generates code that either degrades performance or causes it to crash. That's one of the many accusations in AMD's lengthy document of complaints against Intel in its recent lawsuit against the chip giant.
The paragraph in question, number 123, reads:
"Intel has designed its compiler purposely to degrade performance when a program is run on an AMD platform. To achieve this, Intel designed the compiler to compile code along several alternate code paths. Some paths are executed when the program runs on an Intel platform and others are executed when the program is operated on a computer with an AMD microprocessor. (The choice of code path is determined when the program is started, using a feature known as “CPUID” which identifies the computer’s microprocessor.) By design, the code paths were not created equally. If the program detects a “Genuine Intel” microprocessor, it executes a fully optimized code path and operates with the maximum efficiency. However, if the program detects an “Authentic AMD” microprocessor, it executes a different code path that will degrade the program’s performance or cause it to crash."
I'm sure AMD has evidence of this happening, otherwise why would they write BS in their 48 page report?
Before you came here, the forums used to have subtitles like ("if amd isn't your thing stay away" and "if intel isn't your thing stay away"). edit: see for yourself the troll free better days: http://web.archive.org/web/20020122033003/http://hardforum.com/athlonfx said:
Guess what would happen if I made a "AMD loses big again this quarter" post in the AMD forum? The analyst concensus is that AMD is going to post a loss again this quarter, so it's true.
The hypocrisy in moderation between the 2 forums... this troll will probably stay open.
Intel's compilers recognise when they're running on an AMD processor, and generates code that either degrades performance or causes it to crash.ajm786 said:So they could get something out of it. I'm sure you'd do the same if you were suing someone.
And what pxc said. Why should Intel OPTIMIZE for AMD processors? It doesn't quite make sense.
- Now there's a problem with that ...
BlindedByScience
More Human than Human
- Joined
- May 26, 2000
- Messages
- 9,282
athlonfx said:
If there is indeed hard proof that Intel's compiler degrades performance of "other" CPU's....that's one thing. If it's just that some optimizations aren't turned on....different story.
...aren't there other compilers?
(Puts on mod hat) This is a good subject that deserves good discussion. So far, so good; please keep it on topic, and leave the flame throwers aside.....OK?
pxc said:The hypocrisy in moderation between the 2 forums... this troll will probably stay open.
I have no problem with open discussion but if you guys get into it, it'll get handled. I don't see any hypocrisy there....and, frankly, comments in thread like that don't help a lot. The "Report Post" button is alive, well, and PM's me and every other Mod, SuperMod, and Admin on the boards. Fair enough?
Thanks - B.B.S.
I've been using an AMD processor for the last 3 years or so, with ICC, and I've never actually had a crash (well, apart from accidentally running an SSE2-optimized binary on my non-SSE2-capable AMD, but hey).
I don't know about degraded performance either... all I know is that if the resulting binary was slower than with the MS compiler on AMD, it was slower on Intel aswell, and as far as I checked, the AMD version always ran SSE code when it was supposed to.
Since ICC is a commercial product, I doubt that they'd actually put something like anti-AMD code in it. That would make it very unattractive for people to use (who'd want to sell software that only runs well on Intel processors?).
Perhaps they are talking about some problem WAY back, when AMD first added SSE or some other previously Intel-only feature, and certain software (including software not compiled with ICC) checked for the presence of SSE by seeing if it was an Intel processor of a certain family, rather than checking the proper CPUID flag. A common mistake, but still I doubt that Intel would make such a mistake, since they are the ones that actually put the CPUID flag in there in the first place.
Come to think of it... I actually have the first AMD CPU ever to feature SSE, so if something was up, I should have noticed at some point, I suppose.
I don't know about degraded performance either... all I know is that if the resulting binary was slower than with the MS compiler on AMD, it was slower on Intel aswell, and as far as I checked, the AMD version always ran SSE code when it was supposed to.
Since ICC is a commercial product, I doubt that they'd actually put something like anti-AMD code in it. That would make it very unattractive for people to use (who'd want to sell software that only runs well on Intel processors?).
Perhaps they are talking about some problem WAY back, when AMD first added SSE or some other previously Intel-only feature, and certain software (including software not compiled with ICC) checked for the presence of SSE by seeing if it was an Intel processor of a certain family, rather than checking the proper CPUID flag. A common mistake, but still I doubt that Intel would make such a mistake, since they are the ones that actually put the CPUID flag in there in the first place.
Come to think of it... I actually have the first AMD CPU ever to feature SSE, so if something was up, I should have noticed at some point, I suppose.
robberbaron
Supreme [H]ardness
- Joined
- Sep 6, 2004
- Messages
- 6,101
So Scali, you, like me, see that this is just frivilous BS?
robberbaron
Supreme [H]ardness
- Joined
- Sep 6, 2004
- Messages
- 6,101
FreiDOg said:
So it looks for the Intel(R) instead of the flags, basically?
Something I noticed is that Valve's survey doesn't check flags. It said my CPU doesn't support Hyperthreading. It should actually say that it does (even though it doesn't, nor does it need it), since the X2 has the Hyperthreading tag. It just sees that its an AMD chip and says no. I guess this is a similar thing, albeit irrelevent, heh.
robberbaron said:
Flags are a way of life. X86 by nature is software driven. My oh my how quickly we forget. Remember the big schick about WindowsXP 64 Beta not working in 64bit mode with 64bit Xeons? This was nothing more than a flag seeing Intel, then not taking the 64bit code path for anything not AMD. The next RC had Intel code paths added and wa-la.
http://www.aceshardware.com/read.jsp?id=40000189
Read the whole thing first!
snipet-->The "non SSE-2 generic" program path, which allows the executable to be run on non-SSE-2 CPUs as well, has a serious impact on the Athlon's performance in some areas compared to the VC6, VC7, and Intel C++ (/O2 /G7) versions. We have yet to figure out what is causing this, but we hope that developers will not use this generic path for non-SSE-2 CPUs when generating superb SSE-2 code for the Pentium 4. One possible explanation is that the generic path generates Pentium III code, which does not take in account the store to load forwarding issues. These restrictions (rules) are important for the Athlon and Pentium 4, but matter much less for the Pentium III.
It's up to software folks. This has since been fixed.
Also Hexus and Ars have similar articles. 2CPU.com have other articles that could hurt AMD as well. So what next, will AMD sue these guys for lying?
Donnie27
athlonfx said:
Man, talking about the "Fox proteching the Henhouse", sheesh, that stinks. Why does it stink?
Intel witch hunts lead by the Germans, EU and AMD
http://www.geek.com/news/geeknews/2001apr/bch20010406005269.htm
http://www.networkworld.com/news/2004/0421euinves.html
http://articles.fool.com/coms2/summary_0268-mft04060822_ITM
The EU and Germans bankrolling AMD.
http://www.ecommercetimes.com/story/32799.html
http://news.zdnet.com/2100-9584_22-5154539.html
http://techreport.com/ja.zz?id=38251
""I would like to thank the taxpayers of Germany, Saxony, and the EU for subsidizing cheap chips for us all.""
The same reports are at the Inquirer with different spins. AMD Spokesperson Anand and Wes Fink have already bragged about code path problems being fixed. Intel has a strong case if needed LOL! What AMD is fighting for, is to get prices UP, not down. Folks are still flying the AMD is cheaper flag, AMD must think everyone is that dumb or can't count. This comes from most of teh same folks who think RAMBUS is hosers, hehehehe! RAMBUS sued Infineon (who admitted guilt) and Micron (also plead guilty) had much strong cases than AMD!
Donnie27
athlonfx said:
Man, talking about the "Fox protecting the Henhouse", sheesh, that stinks. Why does it stink?
Intel witch hunts lead by the Germans, EU and AMD
http://www.geek.com/news/geeknews/2001apr/bch20010406005269.htm
http://www.networkworld.com/news/2004/0421euinves.html
http://articles.fool.com/coms2/summary_0268-mft04060822_ITM
The EU and Germans bankrolling AMD.
http://www.ecommercetimes.com/story/32799.html
http://news.zdnet.com/2100-9584_22-5154539.html
http://techreport.com/ja.zz?id=38251
""I would like to thank the taxpayers of Germany, Saxony, and the EU for subsidizing cheap chips for us all.""
The same reports are at the Inquirer with different spins. AMD Spokesperson Anand and Wes Fink have already bragged about code path problems being fixed. Intel has a strong case if needed LOL! What AMD is fighting for, is to get prices UP, not down. Folks are still flying the AMD is cheaper flag, AMD must think everyone is that dumb or can't count. This comes from most of teh same folks who think RAMBUS is hosers, hehehehe! RAMBUS sued Infineon (who admitted guilt) and Micron (also plead guilty) had a much stronger case than AMD!
Donnie27
Donnie27 said:
Thing is that a compiler is a tool for actually writing that software. If the tool is broken, then so will its creations.
Reminds me of the proof-of-concept that someone once made of a compiler that compiled an exploit into every program it was used with. But once the compiler was compiled with a 'tainted' compiler, any trace of the actual exploit code was gone. So even if you would compile a new compiler with non-tainted sourcecode, the exploit would still be inserted in it, and it would still insert the exploits into all other programs it would generate.
Quite a clever trick actually. Shows the dangers of compilers, and teaches us to trust noone, not even a compiler. If you really want to know what's going down, you need to look at the lowest possible level (and be careful about using tainted disassemblers, hexeditors etc
).I don't think this will hold up in court.
Basically, the compiler (written by intel for intel CPU's) checks to see if it is Intel hardware, and if it is then the complier uses all the features of the CPU. If it is not Intel hardware it uses the most compatable code path, because Intel doesn't want to be held accountable for possible faults in non Intel hardware. (EG: if a VIA C3 SSE instruction did not work, it would cause the software to crash if the complier tried to use it)
Intel is under no obligation to make the most effecent use of non Intel hardware with Intel software, and given the liabilty, using the most compatable code paths on non Intel hardware makes sense.
==>Lazn
Basically, the compiler (written by intel for intel CPU's) checks to see if it is Intel hardware, and if it is then the complier uses all the features of the CPU. If it is not Intel hardware it uses the most compatable code path, because Intel doesn't want to be held accountable for possible faults in non Intel hardware. (EG: if a VIA C3 SSE instruction did not work, it would cause the software to crash if the complier tried to use it)
Intel is under no obligation to make the most effecent use of non Intel hardware with Intel software, and given the liabilty, using the most compatable code paths on non Intel hardware makes sense.
==>Lazn
Scali said:Thing is that a compiler is a tool for actually writing that software. If the tool is broken, then so will its creations.
Reminds me of the proof-of-concept that someone once made of a compiler that compiled an exploit into every program it was used with. But once the compiler was compiled with a 'tainted' compiler, any trace of the actual exploit code was gone. So even if you would compile a new compiler with non-tainted sourcecode, the exploit would still be inserted in it, and it would still insert the exploits into all other programs it would generate.
Quite a clever trick actually. Shows the dangers of compilers, and teaches us to trust noone, not even a compiler. If you really want to know what's going down, you need to look at the lowest possible level (and be careful about using tainted disassemblers, hexeditors etc
Thanks for the info and the view point.
You know well as I do that when the first Xeons with AMD's x86-64 (hey, call it what it is) were tested and the flag kicked OFF 64bit and wouldn't enabled it. AMD favoring folks from far and wide were all to quick to say; "Hahahaha Xeons can't do 64bit" or "It's broke, Intel couldn't do it" or etc.. It's not Intel's fault AMD called SSE a Gimmick and only marketing while putting off using it. Their followers believed that too. 3DNow does slow all or every Pentium down. I know (not think or believe) that Intel and AMD have been lying so long that they wouldn't know the truth if it bit them both on the booty but this is silly.
AMD is worse because they're doing the suing. If they get their way, we'll all be talking about how a $600 processor is a good deal like those folks in the "Deals" section of the Forum, sheeshe Loouis!
Donnie27
Donnie27 said:
Yea, but that was the OS that did the detection in a way that prohibited it from running on the Intels of that time. A compiler is a different beast.
And there's this story about AMD's documentation being faulty, which rendered the Intel processors incompatible anyway.
Always a problem when software and hardware are developed simultaneously. If one party decides to change something, the others can't always respond in time.
What do you mean exactly?
There is no Pentium that even supports 3DNow!, so it cannot be slowed down by it anyway. It can only give an invalid instruction exception
And did AMD really call SSE a gimmick? Or was it just clueless AMD !!!!!!s on Internet forums?
Scali said:
Very true and I agree! I was just giving an example.
What do you mean exactly?
There is no Pentium that even supports 3DNow!, so it cannot be slowed down by it anyway. It can only give an invalid instruction exception
And did AMD really call SSE a gimmick? Or was it just clueless AMD !!!!!!s on Internet forums?
Like Quake2, it was 3DNow or nothing in the way of SIMDs. NOT that 3DNow slowed down the P3s and P4s, unoptimized apps sufferred=P Even the base MMX, the first 21 instructions I think, that makes the base of 3DNow, doesn't kick in when an Intel processor is used. Yes, you're absolutely right, there's tons I need to learn about compilers, flags and etc., thanks for the help.
Yes, two of AMD's Top Engineers called SSE a Gimmick. Just as another called Hyperthreading a Gimmick and a Fix. While sitting on the TPI board, both Tim "Sweetness" Sweenty and Mark "Rainman" Reins, called SSE2 useless as well. Their (AMD's and Intel BTW) motto is, "If we don't have it yet, it's useless, a Gimmick or a Fix." Their Followers or Fans usually swallow or believe every single word.
Donnie27
chrisf6969
[H]F Junkie
- Joined
- Oct 27, 2003
- Messages
- 9,011
SO why doesn't AMD build their own compiler and stop bitching.
If they were using ACC (AMD's Compiler),
instead of ICC (Intel) then that wouldn't be a problem.
Next their going to complain that Intel motherboards are more stable and faster than AMD motherboards and Intel should build motherboards for AMD processors to level the playing field.
Why don't they just stick to 3dNow and stop copying all of Intel's SSE codes too. lol
If they were using ACC (AMD's Compiler),
instead of ICC (Intel) then that wouldn't be a problem.
Next their going to complain that Intel motherboards are more stable and faster than AMD motherboards and Intel should build motherboards for AMD processors to level the playing field.
Why don't they just stick to 3dNow and stop copying all of Intel's SSE codes too. lol
Donnie27 said:
Since I said both AMD and Intel I must keep this fair. Intel lied and called the Integrated memory controller slapped on and a quick fix. They not only said said 64bit was not needed but that the way AMD did it was sloppy. Both clear lies. If I shopped and bought from what I thought were honest companies, I'd have nothing, computers or anything. Honest companies die. It's like consumers like being lied to.
Donnie27
chrisf6969 said:SO why doesn't AMD build their own compiler and stop bitching.
If they were using ACC (AMD's Compiler),
instead of ICC (Intel) then that wouldn't be a problem.
Next their going to complain that Intel motherboards are more stable and faster than AMD motherboards and Intel should build motherboards for AMD processors to level the playing field.
Why don't they just stick to 3dNow and stop copying all of Intel's SSE codes too. lol
Someone else on another forum said the same thing, hehehehe
Like the price of their processors, AMD would sell it for too much I'm still laughing at the guys in the Deals section talking about a "good deal", "nicely priced" or "affordable" $600 processor, you kidding me? That's about how much I expect to spend on Mobo, Processor and Video card.Donnie27
not if you buy that 800$ video card, 1000$ processor, and 300$ motherboard. dont forget your 200$ power supply, 200$ case, and 400$ ram.
really, amd bitching that intels compiler doesn't work well with their cpu's is like ford complaining that dodge's v12 engine won't fit into the Focus.
its like microsoft complaining that linux code doesn't run natively on windows. its like taco bell complaining to Cattlemens that they make a better steak. Its like Nvidia complaining that ATI's drivers dont work for Nvidia's cards.
seriously, its called x86 compatible. COMPATABLE. each CPU has its own enhanced instruction set. you don't see Alpha bitching that Intels compiler doesn't work on their CPU's.
AMD is lucky enough that it would work on their cpu's AT ALL.
Intel could simply say "F' you!" and release their instruction set without releasing a compiler and leave it to third parties to make a compatable compiler. however doing so would only hurt Intel. AMD expects Intel to do compatability testing for them? Do you see microsoft going to linux and saying "oh, i'm sorry that doesnt work with your software, let me fix that".
A cpu is a product, and as a product, your company should provide some sort of support for that product. a company is under NO obligation to provide support for their competitors products. It only becomes anti competitive when a company purposefully detects a product and makes it faulty.
in the case intels ICC its an equal discriminator. i'm sure Cyrix would have just as many problems as AMD.
really, amd bitching that intels compiler doesn't work well with their cpu's is like ford complaining that dodge's v12 engine won't fit into the Focus.
its like microsoft complaining that linux code doesn't run natively on windows. its like taco bell complaining to Cattlemens that they make a better steak. Its like Nvidia complaining that ATI's drivers dont work for Nvidia's cards.
seriously, its called x86 compatible. COMPATABLE. each CPU has its own enhanced instruction set. you don't see Alpha bitching that Intels compiler doesn't work on their CPU's.
AMD is lucky enough that it would work on their cpu's AT ALL.
Intel could simply say "F' you!" and release their instruction set without releasing a compiler and leave it to third parties to make a compatable compiler. however doing so would only hurt Intel. AMD expects Intel to do compatability testing for them? Do you see microsoft going to linux and saying "oh, i'm sorry that doesnt work with your software, let me fix that".
A cpu is a product, and as a product, your company should provide some sort of support for that product. a company is under NO obligation to provide support for their competitors products. It only becomes anti competitive when a company purposefully detects a product and makes it faulty.
in the case intels ICC its an equal discriminator. i'm sure Cyrix would have just as many problems as AMD.
chrisf6969
[H]F Junkie
- Joined
- Oct 27, 2003
- Messages
- 9,011
SacLANd said:
Exactly!! Couldn't have said it better myself!
robberbaron
Supreme [H]ardness
- Joined
- Sep 6, 2004
- Messages
- 6,101
Donnie27 said:Someone else on another forum said the same thing, hehehehe
Donnie27
I don't really understand this statement, since AMD processors are cheaper than Intel's at the same performance point.... unless something has drastically changed without me noticing. You'd also have a pretty lowly performing computer if you put $600 into the board, CPU, and GPU. Maybe a notch above a 530/6600GT combo?
Anyways,
http://theinquirer.net/?article=24622
The plot thickens!
robberbaron said:
Sorry, I don't believe Intel processors cost more. As you compare them per performance point, you have to pick what app/s you're talking about. Games make what you're saying true, multimedia apps make your statements faulse. If the MM app is optimized, that's makes your (or many others including AMD) statements very faulse. I'm sure you wouldn't want to use Adobe Premiere 7 for your performance measurements? One of the few apps that scale with MHz LOL! That whould make a P4 3GHz worth what a an Athlon 57FX cost LOL! You, me or NO ONE else can pick a price point without looking at what we'd use the computer for.
I was looking at a 3200+, an ATI x800XL and a DFI Lan party. No I don't see a 3700+ as a 3.7GHz P4 because once the games stop, its model number looks like a rip off. This would be a Gaming Rig. I don't need a multimedia rig since I already have a P4 for that. I was made an offer by my favorite VAR for $625 shipped for the above base to a system.
PR doesn't stand for Performnce Rate, it stands For Price Rate.
The X2 is good but IMHO (yes, only mine) that's about $200 too much for just a processor, any current precessor=P So Hell no I don't think $600 Plus for that processor is a good deal at all. But that's just me.
Donnie27
Donnie27 said:
Well, the integrated memory controller may actually be slapped on... but it's not a quick fix, it seems to be a good long-term solution (at least performance-wise, there are ofcourse some practical problems, with the CPU and socket tied to a specific memory type).
But the 64-bit thing, well... that's just true.
x86 is a lousy processor to begin with, and patching 64-bit onto it is not going to make it any better. Intel has a far better 64-bit solution (as do several other companies, such as IBM, HP, and Digital (well, didn't get them very far in the end
) ).And since even most 64-bit motherboards are still physically limited to 4 gb or less, apparently 64-bit is not that big a deal even today (let's disregard the performance gains from 64-bit mode, since they are not a result of the CPU being 64-bit, but rather the result of some improvements like added registers, which would give as much extra performance if added to the 32-bit CPUs). And we only just have a 64-bit version of Windows... so indeed AMD was far too soon with its 64-bit processors. Intel is right on time, and if it wasn't for x86-64, they'd probably have a desktop-Itanium ready now.
Donnie27 said:
Well, that makes perfect sense to me.
3DNow! was there before SSE, so for a while, there was no Intel alternative for floating point SIMD.
If the MMX instructions were used as part of the 3DNow! code, then it would not help the Intel processors anyway, since it is rather costly to switch between MMX and FPU code (they use the same physical registers). So 3DNow! really was a bit of all or nothing.
But the same happened the other way around when SSE was introduced. Since the installed base of 3DNow! was so small, and 3DNow! was far more limited than SSE, most developers chose to go SSE-or-nothing.
Scali said:
Hey I agree, that's the way I saw it back in the day as well. But yes, MMX makes up the base for 3DNow, that's what AMD won in court in the first place. Without checking, I think it was like 21 of these are MMX and then another 23 to make up the 54 instructions. SSE was announced at the same time but 3DNow reached the market first.
Donnie27
Donnie27 said:
What do you mean? MMX is an instructionset in its own right, and was first available on the Pentium. It's an integer-only set. AMD just mapped 3DNow! onto the same physical registers, which means that some MMX instructions can perform meaningful operations on the floating point data. But Intel designed MMX, and never planned the instructions to be used that way.
Some of the SSE instructions are also part of the non-SSE Athlons, and is called Extended MMX, or MMX+. It's the subset of SSE instructions that are basically additions to MMX/3DNow! rather than the instructions that operate on the new XMM registers.
Scali said:
Same thing I was thinking but you used the correct terms, I didn't
What AMD did was use MMX and then add to it its own fixes or other micro-code or so said a few industry watchers.You did clear up something and thank you again! I remember MMX and POD Racer with my Pentium 166MMX. The whole point of all of this was that AMD fans called it a Gimmick and marketing. Many even said Intel copied AMD by using SIMDs LOL!
Donnie27
Grazehell said:
There are short-term solutions and long-term solutions. x86-64 is not a proper long-term solution. Sure, throw enough money and research at it, and you can linger on for decades. But what a waste.
It's just silly when the new technology is already there, and it is more efficient, and has a better perspective for the future.
I'm not interested in just getting the job done. I'm interested in getting the job done in the fastest, most efficient, most reliable, and with the best precision and quality. We have the means, we should use them to our advantage.
robberbaron
Supreme [H]ardness
- Joined
- Sep 6, 2004
- Messages
- 6,101
Scali said:
There just isn't demand for such a thing, otherwise there would be a really good chance of seeing it. Intel doesn't have to go with AMD's attempt at setting a trend. They went with the best business decision, which was prolonging x86. I'm sure IA-64 is a much superior architecture, but can you really expect anyone to say this:
"Hey Intel/AMD, I want you to design the next platform with this in mind: The abandonment of every piece of software we all currently own! I will gladly pay for this!"
The transition to IA-64 would be about that severe in many cases. x86-64, while being inherently inferior, is a superior business move.
robberbaron said:
Ofcourse there's no demand, now that AMD put that horrible quick fix called x86-64 on the market. If they hadn't done that, then at some point the need for 64-bit would be compelling enough to move to Itanium.
There already was a Windows XP for it, and VS.NET was already completely prepared for the transition to 64-bit. A lot of code written with VS.NET is just a recompile away from running on Itanium (without emulation that is, obviously all x86 code already runs with the emulator). The stuff that actually uses .NET doesn't even need the recompile.
Let's face it, AMD just put us back another 10 years at least. I hope Intel tears AMD up in court.
robberbaron said:
WOW! Someone does get it!
So why can't folks understand that same issue with Processors? Lest's look at processor the same way but sub Intel's P4 and Netburst for x86-64 and AMD's Hammer for IA-64. Same sentence might look like this. "The P4, while being inherently inferior, is a superior business move."
For Intel to make a similar trasition as AMD, suffer all of the inherent problems AMD has faced, we'd all be paying higher prices.
If Processors were Tanks, Hammer would be like the King Tiger. It was too heavy for the Motors of those days. But it had a big highpower 88mm connon and a fire control system that could kill anything it could see. Thank goodness the Germans couldn't build a lot of them. When compared to today, the P4 would be an M1A2, great protection, fast, but has a very hot turbine for a motor and drinks fuel faster than any tank ever made.
Donnie