Slashdot Mirror
AMD Says Barcelona Will Outperform Clovertown
Dysfnctnl85 points out a ZDNet Blog posting in which AMD claims that its upcoming quad-core "Barcelona" chipset should be 40% faster than "Clovertown," Intel's quad-core Xeon 5300 line. AMD says that the introduction of Barcelona marks a shift in their strategy from emphasizing price to performance. The post goes on: "Intel is eager to claw back some of the server market share from AMD, and this is where Clovertown comes in... The Xeon 5300 line will represent excellent value for money since Intel plans on pricing them the same as its dual core Xeon 5100 processors. That could make things tough for AMD."
Everyone know that in Barcelona they take Ciesta. So don't plan on using you computer between noon and 1.
We are all just people.
We are talking a SERVER line of cpus here. EE chips are a desktop cpu brand.
For servers TDP is incredibly important, because server rooms are air-conditioned, a room full of higher TDP cpus costs much much much more to run from an electricity point of view.
That's not to say that they won't overstep their vcore or TDP limits to get the upper hand on performance, but that wouldn't win them the performance/watt ratio crown that's the all-important stat for server cpus.
Only by specious reasoning. I'll disprove by counterexample. If I continously tell the disk to seek to one extreme and read a cacheful, then seek to the other extreme and read a cacheful, it will neither be waiting for requests nor using its full bandwidth. A and not B disproves (A => B).
Latency and throughput are unrelated only if there can be infinitely many requests produced and satisfied in parallel. In the case of a hard disk, there can be only one active request per head because it can only be at one place at once. Let's consider the example of my laptop hard drive. It's rated at a data transfer rate of 150 MB/s. But look at the seek speeds - 1.5ms minimum, 12ms average read, 22 ms maximum. It can read a 1 MB file in 6.7 ms, but if that 1 MB file is fragmented into ten chunks across the drive, it'll take around 130 ms.[*] So in this case it actually transfers at 5% of its rated speed. And depending on the application, the data may be in many, many tiny chunks.
Latency limits throughput. The requestee usually can only satisfy a limited number of requests at once (see above), and the requestor may not be able to produce the next request until it's received the previous response.
Simple example: I'm performing a binary search. I need to see what's at location mid before I know if I'll next be interested in location (low+mid)/2 or location (mid+high)/2. In some cases, I can do a speculative fetch for both locations, but you can only extend that out so many generations before you've used up most of your bandwidth on data you'll never use.
Processors are smart about re-ordering instructions to keep working while they're waiting for stuff to happen, but still they frequently get to a point where they can't execute anything more because of ordering constraints - the results of some instruction are dependent on a previous instruction that hasn't completed yet because it's waiting for a value from memory. That value can be the actual instruction to be executed or an operand...either way, your shiny new processor's stuck doing nothing.
[*] - It might beat the average if it's smart about ordering. At the very least, 22 ms has to get added if one request is at one extreme and one request is at the other extreme. That brings it down to 23% of the rated speed.