A 32-bit JVM can only address 4 GB of memory. Java has to do garbage collection. The longer you can defer garbage collection, the higher your benchmark score. With a 64-bit JVM addressing 96 GB of RAM, you can defer garbage collection for the length of the benchmark run.
Also, I would bet that when Sun runs SPECjbb using the 1.4 JVM (64-bit), they will produce 6800 results very similar to, and perhaps better than, the p680. Also, if you note at www.spec.org, a 24 CPU HP Superdome scored 146,825 on SPECjbb using a 32-bit JVM. When HP runs this with a 64-bit JVM, they will probably exceed 200,000, crushing both IBM and Sun.
In short, if you are using SPECjbb to estimate performance for a planned J2EE appserver, you would be an incompetent fool to use a 64-bit JVM run, unless you know your appserver used a 64-bit JVM, and most (if not all) do not.
Granted, I should have been more careful in looking at the JVMs. But consider this: the 8 and 12 way versions of the 680s without the 64-bit JVM (with JIT enabled, but I'd consider that part of the platform IBM provides for Java) outdo the 8 and 12 way E6800.
The difference isn't as dramatic, but observe that the iSeries 840, in its 12 and 24-way forms (32 bit JVM) outdoes the E6800. The processors are the same and the 12 way numbers for the 840 are lower than than of the 680. IBM's older-generation boxes admittedly lose to the E6800, but I claim that this is because the older AS400s and RS6Ks used the Power III back then (notice also that the numbers from the old AS400s are comparable to the old RS6Ks). This suggests two things: Sun's scaling from 12 to 24 isn't as efficient; although a 64-bit JVM helps, the RS64 IV at 600 Mhz as a platform simply outdoes the 750 Mhz US III. It's even scarier when you look at the numbers for the 750 Mhz RS64 IV (granted that they are with 64 bit JVMs).
And speaking of TPC benchmarks, what about TPC-H? IBM has a pretty decent 128 CPU SP2 result. However, the Sun 6800's CPUs are exactly twice as fast as the SP2's CPUs, and got exactly twice the performance per CPU, and both systems were running IBM's DB2 database.
I don't get the TPC-H complaints about IBM. I assume IBM hasn't published TPC-H stuff because it hasn't had an SP model (i.e. clusterable) until the 690. When the 690 turbo has been tested, I assumed that the numbers will be published. In the meantime, here's what I don't get. The 128 CPU SP cluster outdid an E10K (whose CPUs were running 25 Mhz faster) at a much higher cost efficiency (note however that the database sizes were different). And the SP outdid the E6800 box by a factor of 3. It did have to use 128 CPUs instead of 24, but consider: the price/performance ratios were nearly the same, so an IBM box that was "one-third" as powerful would have been equal in standing to an E6800 - or better, since most multi CPU things scale sub-linearly. But remember that the SP system was using 375 Mhz CPUs - the E6800 used 750 Mhz USIIIs. Imagine what a 690 Turbo would do here.
One final argument: IBM isn't cheating by clustering. If Sun's had a cluster that was good enough, it would have published the result. After all, it clustered 4 24-way E6500s for the TPC-C and it still just barely lost to a single 24-way S80 (precursor to the 680). With almost the highest numbers (except for an HP and Teradata box) IBM han't had reason to publish new TPC-H results. I bet now they will show fresh numbers.
You only get this by clocking the backpane bus down to 100 mhz. Constant latency keeps things nice and simple for a lot of engineering, but it does not by definition produce a better system. Same with the Star Cat - its crossbar is constant latency so that more CPU boards don't slow it down. But this means it had to clock the backpane low enough for the *most distant* two boards to be able to talk at this speed.
Remember that as long as we obey physics, the latency will increase on the order of n^(1/2) or n^(1/3). You can try to hide it with the appearance of constant latency (busses, crossbars) but you will pay a price. Consider two examples: Sun's crossbar *could not* handle more than 18 CPU boards because latency would kill it by design. On the other hand, connecting MCMs via a variable speed ("wave pipelined"?) bus in the 690 means future boxes with more than 4 MCMs could be accomodated (and you get the best performance you can given distance when you haven't maxed out the box). In addition, IBM can place 8 CPUs on one chip, so physical locality benefits greatly there.
That being said, I think Sun is trying to avoid the embarassment of its E6500 line: back then, to max out its CPUs, you had to underclock the bus from 100 Mhz to 83.
The S80 got a high score because it's CPU had a very short pipeline (5-stage) which a database benchmark with a lot of locality benefits from tremedously. Another benefit was the S80's CPUs had twice the cache as the rest of the industry. Throw in some really good database benchmark engineers and you can really tune for TPC-C's locality. Also, the S80 could hold as memory as the E10K, so a big Oracle SGA means fewer disk accesses.
Short pipeline stages are something IBM should be praised for. The US III is a 14-stage pipeline (like the Athlon) but good ol' Sun hasn't been able make them available above 900 Mhz so far. IBM had 5-stage processors at 750 Mhz if I'm correct. It's not just in TPC stuff that short pipelines matter - short pipelines mean that you have to spend less resources on scheduling, branch prediction, etc. saving lots of die area. Short pipelines also tend to be better for older applications, so businesses migrating to the new box won't experience a slowdown because their software wasn't compiled for 14-stage processors.
TPC isn't the only benchmark that IBM's published. The 680 kicked the crap out of the SunFire 6800 in the Spec JBB benchmarks. Both boxes were 24-way systems, but IBM's score was higher by 50%. Granted, IBM makes better Java runtimes (though Java should be Sun's turf no?) but the 6800 was running US IIIs at 750 Mhz while the 680 had 600 Mhz chips.
I find it cute that Sun's now refused to publish TPC scores at all on the Star Cat. I bet they would have rushed out numbers had the Star Cat actually been better. I wish there was indeed a new DB benchmark. But until there's an independent authority that test boxes without bias, I'll rely on TPC and Spec.
No it can't. Read the original AnandTech article. The Thunder has 5 slots that are 64 bit x 33 Mhz. The main problem with using 66 Mhz slots is that they're not backwards compatible - in fact, they don't even have the same plastic recesses so you can't fit a 33 into a 66 slot.
True that you can use PC memory for Macs. However, also remember this:
1) Most users (mac and PC) will buy memory straight from the store where they got their computer, be it Apple.com, Dell.com. Now Dell's web site does charge quite a bit, though not as much as Apple.
2) PCs are more open to a wider variety of memory. Some of this memory may be "non standard", but apparently, Apple's latest firmware update simply fails to recognize memory Apple considers "bad" - where "bad" can include functional but not fully labeled memory. Check out:
http://maccentral.macworld.com/news/0104/03.appl er am.shtml
Slashdot Mirror
Granted, I should have been more careful in looking at the JVMs. But consider this: the 8 and 12 way versions of the 680s without the 64-bit JVM (with JIT enabled, but I'd consider that part of the platform IBM provides for Java) outdo the 8 and 12 way E6800.
The difference isn't as dramatic, but observe that the iSeries 840, in its 12 and 24-way forms (32 bit JVM) outdoes the E6800. The processors are the same and the 12 way numbers for the 840 are lower than than of the 680. IBM's older-generation boxes admittedly lose to the E6800, but I claim that this is because the older AS400s and RS6Ks used the Power III back then (notice also that the numbers from the old AS400s are comparable to the old RS6Ks). This suggests two things: Sun's scaling from 12 to 24 isn't as efficient; although a 64-bit JVM helps, the RS64 IV at 600 Mhz as a platform simply outdoes the 750 Mhz US III. It's even scarier when you look at the numbers for the 750 Mhz RS64 IV (granted that they are with 64 bit JVMs).
I don't get the TPC-H complaints about IBM. I assume IBM hasn't published TPC-H stuff because it hasn't had an SP model (i.e. clusterable) until the 690. When the 690 turbo has been tested, I assumed that the numbers will be published. In the meantime, here's what I don't get. The 128 CPU SP cluster outdid an E10K (whose CPUs were running 25 Mhz faster) at a much higher cost efficiency (note however that the database sizes were different). And the SP outdid the E6800 box by a factor of 3. It did have to use 128 CPUs instead of 24, but consider: the price/performance ratios were nearly the same, so an IBM box that was "one-third" as powerful would have been equal in standing to an E6800 - or better, since most multi CPU things scale sub-linearly. But remember that the SP system was using 375 Mhz CPUs - the E6800 used 750 Mhz USIIIs. Imagine what a 690 Turbo would do here.
One final argument: IBM isn't cheating by clustering. If Sun's had a cluster that was good enough, it would have published the result. After all, it clustered 4 24-way E6500s for the TPC-C and it still just barely lost to a single 24-way S80 (precursor to the 680). With almost the highest numbers (except for an HP and Teradata box) IBM han't had reason to publish new TPC-H results. I bet now they will show fresh numbers.
You only get this by clocking the backpane bus down to 100 mhz. Constant latency keeps things nice and simple for a lot of engineering, but it does not by definition produce a better system. Same with the Star Cat - its crossbar is constant latency so that more CPU boards don't slow it down. But this means it had to clock the backpane low enough for the *most distant* two boards to be able to talk at this speed.
Remember that as long as we obey physics, the latency will increase on the order of n^(1/2) or n^(1/3). You can try to hide it with the appearance of constant latency (busses, crossbars) but you will pay a price. Consider two examples: Sun's crossbar *could not* handle more than 18 CPU boards because latency would kill it by design. On the other hand, connecting MCMs via a variable speed ("wave pipelined"?) bus in the 690 means future boxes with more than 4 MCMs could be accomodated (and you get the best performance you can given distance when you haven't maxed out the box). In addition, IBM can place 8 CPUs on one chip, so physical locality benefits greatly there.
That being said, I think Sun is trying to avoid the embarassment of its E6500 line: back then, to max out its CPUs, you had to underclock the bus from 100 Mhz to 83.
Short pipeline stages are something IBM should be praised for. The US III is a 14-stage pipeline (like the Athlon) but good ol' Sun hasn't been able make them available above 900 Mhz so far. IBM had 5-stage processors at 750 Mhz if I'm correct. It's not just in TPC stuff that short pipelines matter - short pipelines mean that you have to spend less resources on scheduling, branch prediction, etc. saving lots of die area. Short pipelines also tend to be better for older applications, so businesses migrating to the new box won't experience a slowdown because their software wasn't compiled for 14-stage processors.
TPC isn't the only benchmark that IBM's published. The 680 kicked the crap out of the SunFire 6800 in the Spec JBB benchmarks. Both boxes were 24-way systems, but IBM's score was higher by 50%. Granted, IBM makes better Java runtimes (though Java should be Sun's turf no?) but the 6800 was running US IIIs at 750 Mhz while the 680 had 600 Mhz chips.
I find it cute that Sun's now refused to publish TPC scores at all on the Star Cat. I bet they would have rushed out numbers had the Star Cat actually been better. I wish there was indeed a new DB benchmark. But until there's an independent authority that test boxes without bias, I'll rely on TPC and Spec.
No it can't. Read the original AnandTech article. The Thunder has 5 slots that are 64 bit x 33 Mhz. The main problem with using 66 Mhz slots is that they're not backwards compatible - in fact, they don't even have the same plastic recesses so you can't fit a 33 into a 66 slot.
True that you can use PC memory for Macs. However, also remember this:
l er am.shtml
1) Most users (mac and PC) will buy memory straight from the store where they got their computer, be it Apple.com, Dell.com. Now Dell's web site does charge quite a bit, though not as much as Apple.
2) PCs are more open to a wider variety of memory. Some of this memory may be "non standard", but apparently, Apple's latest firmware update simply fails to recognize memory Apple considers "bad" - where "bad" can include functional but not fully labeled memory. Check out:
http://maccentral.macworld.com/news/0104/03.app