SoylentNews is people
SoylentNews
In 2011 AMD released the Bulldozer architecture, with a somewhat untraditional implementation of the "multicore" technology. Now, 4 years later, they are sued for false advertising, fraud and other "criminal activities". From TFA:
In claiming that its new Bulldozer CPU had "8-cores," which means it can perform eight calculations simultaneously, AMD allegedly tricked consumers into buying its Bulldozer processors by overstating the number of cores contained in the chips. Dickey alleges the Bulldozer chips functionally have only four cores—not eight, as advertised.
This discussion has been archived.
No new comments can be posted.
AMD Sued by Customer Over Misrepresentation of "Multicore"
|
Log In/Create an Account
| Top
| 36 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
TAPPING? You POLITICIANS! Don't you realize that the END of the "Wash
Cycle" is a TREASURED MOMENT for most people?!
(Score: 1) by xav on Saturday November 07 2015, @12:25PM
> When you examine the output of /proc/cpuinfo, each hyperthread is counted as a separate processor, which of course is bogus. More marketing bullshit from Intel.
Watch out! /proc/cpuinfo is a marketing weapon in the hands of Intel!
Do you really think that Intel wrote the kernel code that generates /proc/cpuinfo and made in buggy in order to deceive the customer?
You tin-foil hat must be covering your eyes. Look better at /proc/cpuinfo, especially at those "core id" lines.
# fgrep -w -e id -e processor /proc/cpuinfo
(Score: 4, Informative) by Runaway1956 on Saturday November 07 2015, @02:49PM
No - I don't think they did that, but I remember they released a compiler that crippled code when it ran on an AMD processor. That is one of the reasons I don't do Intel.
* Intel Forced to Remove "Cripple AMD" Function from Compiler?
posted by Thom Holwerda on Sun 3rd Jan 2010 20:32 UTC
IconHere's something you probably don't know, but really should - especially if you're a programmer, and especially especially if you're using Intel's compiler. It's a fact that's not widely known, but Intel's compiler deliberately and knowingly cripples performance for non-Intel (AMD/VIA) processors.
Agner Fog details this particularly nasty examples of Intel's anticompetitive practices quite well. Intel's compiler can produce different versions of pieces of code, with each version being optimised for a specific processor and/or instruction set (SSE2, SSE3, etc.). The system detects which CPU it's running on and chooses the optimal code path accordingly; the CPU dispatcher, as it's called.
"However, the Intel CPU dispatcher does not only check which instruction set is supported by the CPU, it also checks the vendor ID string," Fog details, "If the vendor string says 'GenuineIntel' then it uses the optimal code path. If the CPU is not from Intel then, in most cases, it will run the slowest possible version of the code, even if the CPU is fully compatible with a better version."
It turns out that while this is known behaviour, few users of the Intel compiler actually seem to know about it. Intel does not advertise the compiler as being Intel-specific, so the company has no excuse for deliberately crippling performance on non-Intel machines.
"Many software developers think that the compiler is compatible with AMD processors, and in fact it is, but unbeknownst to the programmer it puts in a biased CPU dispatcher that chooses an inferior code path whenever it is running on a non-Intel processor," Fog writes, "If programmers knew this fact they would probably use another compiler. Who wants to sell a piece of software that doesn't work well on AMD processors?"
In fact, Fog points out that even benchmarking programs are affected by this, up to a point where benchmark results can differ greatly depending on how a processor identifies itself. Ars found out that by changing the CPUID of a VIA Nano processor to AuthenticAMD you could increase performance in PCMark 2005's memory subsystem test by 10% - changing it to GenuineIntel yields a 47.4% performance improvement! There's more on that here [print version - the regular one won't load for me].
In other words, this is a very serious problem. Luckily, though, it appears that the recent antitrust settlement between AMD and Intel will solve this problem for at least AMD users, as the agreement specifically states that Intel must fix its compiler, meaning they'll have to fix their CPU dispatcher.
The Federal Trade Commission is investigating Intel too, and it is also seeking a resolution of the compiler issue, but the FTC takes it all a step further than the Intel-AMD settlement. Since the latter only covers AMD, VIA could still be in trouble. Consequently, the FTC asks that Intel do a lot more than what's described in the AMD settlement:
Requiring that, with respect to those Intel customers that purchased from Intel a software compiler that had or has the design or effect of impairing the actual or apparent performance of microprocessors not manufactured by Intel ("Defective Compiler"), as described in the Complaint:
Intel provide them, at no additional charge, a substitute compiler that is not a Defective Compiler;
Intel compensate them for the cost of recompiling the software they had compiled on the Defective Compiler and of substituting, and distributing to their own customers, the recompiled software for software compiled on a Defective Compiler; and
Intel give public notice and warning, in a manner likely to be communicated to persons that have purchased software compiled on Defective Compilers purchased from Intel, of the possible need to replace that software.
Fog also offers up a number of workarounds, such as using GNU GCC, whose optimisations are similar to that of Intel's compiler, "but the Gnu function library (glibc) is inferior". You can also patch Intel's CPU dispatcher - Fog even provides a patch to do so in "Optimizing software in C++: An optimization guide for Windows, Linux and Mac platforms".
This is a particularly nasty kind of anticompetitive practice, as it really requires deep knowledge of matters in order to find it out. God knows how many benchmarks have been skewed in favour of Intel simply because people unknowingly used Intel's compiler in good faith. Intel's compiler is seen as the cream of the crop and delivers superior performance, but apparently only if you stick to GenuineIntel.
e p (11) 123 Comment(s)
http://www.osnews.com/story/22683/Intel_Forced_to_Remove_quot_Cripple_AMD_quot_Function_from_Compiler_ [osnews.com]
(Score: 0) by Anonymous Coward on Saturday November 07 2015, @03:15PM
I can find valid reasons to default to low levels of optimization on another product vs one that is produced by the compiler vendor and if it is documented this isn't inherently a bad thing. It is bad to cheat and lie, it is not bad to clearly state you will optimize conservatively for an architecture that was not produced in house, and it is good to clearly document that behavior.
This does not have to be evil, it could be stupidity.
I would not put it past Intel to try to slide this in and cover it up under a false flag, but I don't necessarily see anything wrong with not fully optimizing for execution on another chip *by default.*
(Score: 2) by zugedneb on Saturday November 07 2015, @06:51PM
I can find valid reasons...
There are none.
Nobody working with consumer products asks a compiler to do work for a specific _brand_.
They want to compile to a specific set of _instructions_.
It is not the job of the compiler writer to be paranoid about some vendor not implementing the instruction set correctly. The job is to make the compiler produce as requested.
old saying: "a troll is a window into the soul of humanity" + also: https://en.wikipedia.org/wiki/Operation_Ajax