AMD sued: Number of Bulldozer cores in its chips is a lie, allegedly AMD lied about the true number of Bulldozer cores in some of its FX processors, it is claimed. Mini-chipzilla boasted that, depending on the model, the chips had either four, six, eight or 16 Bulldozer cores. A class-action lawsuit [PDF] alleges the real figures are half that. The troubled California giant is being sued in …
So stumpy what you seem to be saying is that all processors should be judged by the standars of the 80286.
If you're looking at x86 architecture, even the 486SX didn't have FP. But I've worked on systems that didn't just have an extra chip fitted, but had another half dozen boards added to the 25 that comprised the CPU, if you wanted floating point. For a price in the range of a family sedan, so you took a good look at your workload first to figure out if it was worth it.
The SX was the cheap version of the DX. Actually, the 487 was a full DX that disabled the SX. But today the FPU is used not only for the old 8087 instruction set, but by all the SSE and later instructions heavily used for graphics and signal processing. Good luck doing without... a lot of software imply they're available.
back in them days, when testing the chips, if the co-processor was wonky, it was disabled and the chip was sold as an SX chip, if the main processor was wonky, the main processor was disabled and the chip sold as a co-processor... only if both bits worked was the chip sold as a fully functioning unit at correspondingly higher price...
This is how I remember it as well.
In fact, I am looking at an 80387 Math coprocessor that is on top of my microwave oven that I keep there just as a reminder that I spent over $700 (USD) just for this single chip, back in the day. Just so that I could run AutoCAD (which required a math coprocessor) on my '386 box. This is the most expensive single IC that I've ever purchased.
I keep it there as a constant reminder of to never buy cutting edge tech unless I'm prepared to regret it later....
(PS - I also had purchased a CDC Wren IV 700 MB (yes MB, not GB or TB) SCSI drive for $3000 USD, around that same time. I no longer have the drive though)
Tech: live without it, unless you really, really need it.
Here's an image https://en.wikipedia.org/wiki/Intel_80487SX
I don't really know how many bought a 486X instead of a DX and later bought a 80487SX to add the FPU, but it was made and available - including boards supporting it.
It was the latest "coprocessor" made. SInce then, more and more software started to rely on an FPU being available, and switching to an emulation library would slow down them a lot.
Both the 386 and 486 came in variants that didn't have FP units. Or to be more pedantic, all 486 chips had FP units, but some were disabled. My understanding is that during the QA process, any full 486 chips that had defects in just the FP part of the die, just had that disabled, rather than the whole chip being discarded.
@BillG - Read the article. It is not just the FPU. Just a few paragraphs in you will find:
"a single branch prediction engine, a single instruction fetch and decode stage, a single floating-point math unit, a single cache controller, a single 64K L1 instruction cache, a single microcode ROM, and a single 2MB L2 cache."
Seems that much, if not most, of a "module" is single threaded. If you can only fetch one instruction at a time and you can only decode one instruction at a time then a module is not really a two-core unit. It seems that only at the end of the instruction pipeline do have a couple of integer execution units and a couple of load/store units. So, at best, I'd call it weird AMD hyper-threading.
If you want to go down that rabbit hole things will get very messy. AMD did mightily screw up it's design and modules typically perform like 1.5 real cores but do manage to issue multiple instructions per clock. The problem is more that those ops then get stalled waiting on the shared execution units.
If his argument is 8 simulations ops case over and no cpu guarantees to always achieve it anyway.
Isn't the fetching part of a pipelining operation rather than a processing operation?
Also, going back to the must-have-an-fpu-to-be-a-core point, that implies that anything which doesn't have a an FPU isn't a core... so the 486 sx had no cores?
It may be a little tricky, but anyone who pays attention knows AMD chips don't match intel on performance and they don't cost anywhere near as much as intel charges. Maybe that's because more features cost more. Surprise!
I'm not a chip architect, but doesn't the presence or absence of duplicate numbers of those components depend entirely upon things like chipset timing?
Specifically, is it not possible to have a pre-fetch unit that is running at [in practical terms] double the clock speed of the cores? Or put another way, is it safe to assume that the throughput of the pre-fetch unit is tightly tied to that of the processors?
Let's put this another way...
If you fire up any modern manager on an Intel Core i7 powered machine, you will see that the "core count" is precisely double what Intel claim for the chip, thanks to Hyperthreading. But what most but the nerdy aren't aware of is the fact that the Intel chips will typically "sleep" one ore more of these "cores" in order to manage the temperature of the chip... So [being argumentative] we could argue that Intel can't claim the number of cores they do if the chip isn't designed to use them all simultaneously?
I'm not trying to pick an argument with you, I'm just try to offer a view that says that modern chip design has become so hideously complex that this entire [and seemingly frivolous] case seems to be built entirely on semantics.
The irony here is that anyone truly concerned with this "nth level" of performance from their CPU is not actually going to count or measure things like this, but actually review simulations of performance from industry-accepted measurement and benchmarking tools like (I think) SiSoft SANDRA. [ I might be a bit out of date with that example!] So for someone to come along at this point with an argument like this is not far short of spotting an ambiguity in the documentation for a 10-year old car and thinking they can sue. Caveat emptor!
You are a bit incorrect there - if OS sees 8 runnable threads, 8-core Intel CPU will execute them all in parallel and all cores will run on advertised clock rate. The trick with sleeping some cores in order to pull up clock rate of others (up to "Turbo" speed specific for the CPU and number of running threads) is applicable only when there are less runnable threads than the number of cores.
This feature doesn't support your argument, nor does your mentioning of Hyperthreading. What were you aiming at?
The original post from td97402 basically called out the fact that some of the AMD chip design involved sharing of some components between pairs of cores, seeming [to my mind] to imply that because the cores shared a branch prediction engine, and both the fetch and decode stages of the instructions, that this meant that the chip didn't really have properly independent cores.
I'll repeat for the record that I'm not a chip architect and that what follows may be factually incorrect...
However, what I wanted to say was that it is entirely possible that the sharing of the fetch and decode units across multiple cores is entirely reasonable. For example [here comes the fiction] suppose that, on average, each instruction takes 4 clock ticks to execute. Suppose that the fetch and decode units can each retrieve and decode an instruction in one clock tick and then switch between different threads in a second clock tick.
If this theoretical model were in any way reflective of the actual CPU, then AMD might have been able to determine that one fetch and one decode unit [with adequate state switching] would be sufficient to "service" two processor cores.
Terrible analogy: I drive a car with a relatively simple 4-cylinder 2-litre engine. The car has one fuel pump. That pump is essential to the engine, since without it those 4 cylinders simply won't get the fuel/air mixture needed for combustion. But the engine only needs one pump, since that pump is plenty capable of supporting all 4 cylinders. In a similar way [again, I have no way of knowing if this is true] the "effort ratio" between what the fetch/decode units do and what the processor does could *easily* be such that these two components can be very effectively shared.
I really didn't want to pick an argument with the original post, just to point out that there could be all sorts of design reasons [and, in modern CPUs, there are all sorts of examples] of sharing or time-slicing components across the broader system design.
To my way of thinking, in order to show that sharing single fetch and decode units between 2 CPU cores is deliberately misleading, someone would have to first show that having one fetch and one decode unit per CPU could actually produce more throughput. Without this, the plaintiff's case is based on conjecture and lacking a basis in fact. Now that presents a massive problem for the plaintiff, since the only way that they could demonstrate this would be to have AMD build such a chip. Which I can't see AMD inclined to do...
Hyperthreading isn't based on having two cores, it's one core with an alternate register set that gets switched in when the active set stalls for some reason (like a cache miss). AMD are providing two complete integer cores that can execute simultaneously, but share some of the logic that feeds them and an FPU. If memory serves then both integer cores are able to access the FPU at once, providing they limit themselves to 128 bits of math.
"Seems that much, if not most, of a "module" is single threaded. If you can only fetch one instruction at a time and you can only decode one instruction at a time then a module is not really a two-core unit."
Not quite. You see, the time used for fetching is far less than the time used for computing. IK am not saying that AMD chips are the best thing on earth (they aren't), but
1) Usually a single fetch unit can keep busy two integer pipelines
2) We can argue that an 8 module (to use AMD's terminology) CPU would be better than a 4 module CPU. No doubt about it. But that's not the question. The question is if AMD right in calling the 4 module CPU an 8 core processor. I believe so, but that's just my opinion.
3) It is true that it shares a single FPU with two integer pipelines. But it shares a more powerfull FPU. Check it. The Athlon FX FPU is more powerfull than the Athlon FPU. If memory serves me right, its is 256 bits versus 192 bits.
Now, real world information: I run the standard PovRay benchmark in a FX 6300. It was better than on a i5 of equivalent generation and clock. The run time was about 30% worse for the FX - it used that much more computing time. But this computing time was spread through its six cores. So, it completed the benchmark about 25% faster than the i5.
And I ask: would be justifiable to cal this 3 module a six core?
This looks to me like someone is just trying to get some easy money.
to sue over what amounts to marketingspeak or at best terminology. Not too long ago FPU's were an optional co-processor, an expensive add-on, that only the most demanding users needed. So what amounts to a processor core? My i5 registers as quad-core even though it is apparently physically a dual core unit that can run two threads per core. I think people who really need the oomph generally would know how to figure out which processor they need, regardless of branding, labels or hype.
It doesn't look like AMD lied about the actual architecture of the chip, more like they marketed it as "teh shiny". A suspicious person might suspect Big Chipzilla might have had a hand in this one.
As far as I know, Intel does not sell hyperthreading as more cores.
But they do drop very heavy hints that it makes things faster, which is not necessarily so.
It'd be crazy if this case is allowed to get to court, never mind win. If a sharing of resources means one cannot count all the cores sharing them, where does that end? Cache? Intel have shared L3 cache. Power? Memory? AMD actually do quite well there. PCIe bus? Not likely to be more than one of those. It's plain nuts.
SMP as we know it could be outlawed by a court case, which would be the most ridiculous thing ever. So it's probably guaranteed then.
"It'd be crazy if this case is allowed to get to court, never mind win."
Since this is in the US, there is really no question of this case being allowed to go to court.
As to winning: I wouldn't expect there to be any correlation between the merits of the case and the outcome.
amd has never made a secret of this "news". Everyone that cared, knew this from the beginning, everyone understood potential shortcoming and everyone else purchased more expensive intel chip.The idea was that in mixed load (real life or not) 8 treads could be executed simultaneously. I won't recall if this best case scenario was more likely to happen than in hypertreaded intel and estimates of what would be performance impact of having this extra fpus present (disabling ht was easy to do and test).
As usual, no love to lawyers and please, do not represent me in your class action or I'll sue you for damages to my preferred chip supplier.
I remember that the early Sparc T CPUs from Oracle / Sun had eight cores that shared an FPU. Never heard of anyone suing over that.
The first Nahelem architecture Xeons were "deceptive" over many SSE registers they had. In 64 bit mode all the registers were there as billed, but the number mysteriously dropped by half in 32 bit mode. It made 64 bit mode code look terrific compared to 32 bit, but only because of this artificial limitation. Of course this was all written down in the data sheets...
I've always considered AMD to be selling a weird, kind of weak variation of hyper-threading as two physical cores. I always divide by two when looking at AMD desktop processors. I think they've been misleading when selling those modules as two cores. Worthy of a lawsuit, well that is another matter.
>>I always divide by two when looking at AMD desktop processors."
Then you are estimating processor performance badly. FPU operations are a minority part of most use cases. The reasons why Bulldozer is slower than say, Haswell, are complex - scheduling problems, weaker branch prediction and other things... Not, in most cases, the shared FPUs. Even with FP operations, the FPUs have 256-bit width and actually can work on two operations simultaneously (one for each core), they just have to be 128-bit operations. Which is common enough.
Basically, your logic is flawed. SUN make a 16-core chip that has one FPU between all of them. Does that mean each of the cores is really only 1/16th of a core? Perhaps they should be sued.
This is a stupid lawsuit, by people suing over their own ignorance.
We live in a world where ISPs frequently sell "unlimited" connections without getting sued. It would be utterly perverse if AMD lost this case, given the wide range of published benchmarks that a buyer might use to "estimate" the performance of an architecture that has been openly published in detail.
From the lack of market research on display here, it is clear that the buyer didn't give a stuff about performance until the weasels started whispering "no win, no fee" in his ear.
"I've always considered AMD to be selling a weird, kind of weak variation of hyper-threading as two physical cores."
Weird, but wrong. The AMD cores are far worse than the Intel ones - but the "dual thread" technology AMD uses is far better than Intel's HyperThreading.
Let me explain: HyperThreading can gain you a 30% boost - at best. In some weird cases it is better to have it disabled (Intel says so, in case of virtual machines). Real world scenario, it will gain You something about 15% speed.
AMD dual thread technology does not have this problem: it is recommended to keep it always on, and there is no situation where it would harm the speed.
The difference in speed is not because of the HyperThreading/duas thread technology> it is because the AMD CPU architecture (today) is inferior.
So the boy didn't read the cut sheet from AMD when he bought it. The question of cores is one that will have to address what kind of cores now that heterogeneous chips are increasingly becoming the norm. What does it mean to say something has X cores when the chip can combine CPUs (x86 and/or ARM), FPUs, GPUs, DSPs or even the occasional FPGA? Do FPUs matter if software is optimized for GPUs?
Of course, such a ruling will be avoided if AMD proves its eight-core Bulldozer processors do not drop to four-core performance in multithreaded FPU benchmark tests.
Another problem entirely as it may well depend on the bit width employed by the benchmark. What happens if it doubles the performance of a four core at 128 bits but not at 256 bits?
Regardless, this kind of "I didn't understand what I was buying" crap needs to be bounced out. Would he sue because he bought a Tegra 4 because the five cores didn't work like they thought?
@Disko,
Having built computers, I have learned not to be dazzled by the marketing fluff but to try to find out which chip has the best balance of features with price for my needs. I have found through years sometimes the best is by Big Chipzilla at other times Little Chipzilla is best. The specs and architecture are rough guides to actual performance (more real cores, bigger cache, cache type, etc.) when the box is fired up.
Also, most chips are probably overkill for most users including office drones particularly when you get to beyond 2 cores. And the only reason for 2 cores is they allow more RAM to be installed.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
