This is not an IBM technology, but instead is based on a technology developed by Transitive.
It would be much more useful if IBM would offer the version of Transitive software which allows POWER applications to run on x86 systems, rather than the reverse. The only thing which makes sense to run on a emulator on a IBM POWER system would be a mainframe environment.
Why emulate the most mass-produced CPU instruction set ever, given the ISA is still in mass production? Why emulate the cheap volume processor on a more expensive, proprietary platform? The reverse makes much more sense. The more expensive, more closed architecture should be emulated on the less expensive, more open platform.
I fail to understand what value running x86 Linux apps on POWER provides. Intel Woodcrest and AMD Opteron provide great 64-bit performance, the AMD/Intel competition keeps prices dirt cheap and innovation moving at light-speed, and VMware provides fine-grained virtualization. And just like the AMD/Intel war keeps processor prices low, the coming Xen/VMware war is going to cut the cost of virtualization.
Emulators are needed to support customers on processor architectures which are dead. That is Alpha and PA-RISC. Next would be current platforms which customers want to move off of. That would be the Mainframe first, then Itanium, and after that perhaps SPARC and POWER.
There are clearly some weird politics going on at Transitive.
HP's partnership with Transitive is not focused on taking care of HP's own Alpha and PA-RISC customers, but instead on offering a SPARC on Itanium emulator. HP does have a partnership with a mainframe emulator, which makes some sense, but why not offer consolidated hosting to your own existing customers first?
IBM's partnership with Transitive is not focused on POWER or mainframe customers, but instead on offering an x86 on POWER emulator.
I can never envision the business case for emulating the industry-standard x86 architecture on a proprietary RISC platform like IBM's POWER.
I would love to see VMware buy Transitive and offer the ability to create Alpha, PA-RISC, Mainframe, Itanium, POWER, and SPARC VMs on ESX server. Of course if they did that, it would be EMC declaring war on the rest of the IT industry, but it would be a really cool product.
The $3,500 USD is not the price of a 4-way capable, 4 rack unit system fully configured with 4 CPUs. From the article:
"A base configuration [emphasis added] of the 4U is expected to cost less than $3,500, sources said."
The $3,500 USD is likely the price of a 4-way capable, 4 rack unit system configured with only one CPU (a typical base configuration). Assuming about $1,000 to $1,500 USD for the server chassis, LVD SCSI boot disk, and memory, the PPC970 CPU is going to run for around $2,000-$2,500 USD per processor.
A fully configured 4-way PPC970 server will probably cost about $10,000 USD.
Best way to deal with conspiracy theorists ...
on
Roswell Declassified
·
· Score: 2, Funny
If a company is providing its own operating system support, it is now an operating system support company.
If a company is modifying the Linux kernel to fit its particular needs, it is now a Linux distributor.
People cost money. Somebody hacking the Linux kernel for Acme Manufacturing is the same as a Linux Kernel hacker for Red Hat. So the cost is still there.
Many companies do not want to be Linux distributors or Linux support companies. They will use a standard distribution such as Red Hat or Suse, tune it too their needs, and have somebody else handle the trouble ticket.
Newcomer to the market? Sun buys its 2-way Intel servers from the same manufacturer that many vendors buy their 2-way Intel servers from, and that manufacturer is not new to the market.
Furthermore, most Intel servers use either Intel motherboards or Broadcom motherboards. So if vendor B is buying 2-way Xeon boxes based on Intel motherboards from an Asian assembler that puts a blue plastic shell on the motherboard, and vendor B is doing the same thing, albeit with the Asian assembler using a black plastic shell, and both vendors outsource their hardware support to the same company that specializes in low-end Intel server support, and both vendors provide Red Hat but outsource their software support to Red Hat, what is the difference, or what is the relavance of how long the the vendor has been in the market?
Your statement makes about as much sense as if Sun had switched from Seagate to Hitachi hard drives in its systems, and you said Sun is a newcomer to the Hitachi hard drive market.
2-way x86 servers are commodities. The only significant companies innovating on these are Intel, AMD, and Broadcom. Not the companies that acutually sell them.
Port all of the Solaris tools to Linux and produce a "proprietary" distro?
It's called Solaris x86! That is what Sun is doing. Customers who want Linux want Red Hat, Suse, etc. So Sun will support those distros on its x86 boxes.
For customers who want an x86 *NIX solution that provides the exact same management tools and interfaces, Sun has brought back Solaris x86.
To me this is the perfect solution. It addresses both requests easily.
The plaintif sounds similar to many displaced middle aged people. When times are tough, the middle aged, who are better paid, claim they are laid off in favor of the young.
I doubt the national origin of the workers had anything to do with this. It is just a convenient screen.
Given that project Monterey was about developing a commercial UNIX for Itanium, and given that IBM abandoned SCO and produced AIX5L for Itanium and discontinued it shortly thereafter, I really do not know what SCO's beef is.
Project Monterey had nothing to do with x86. So what if IBM is pushing Linux on x86.
Now if IBM produced its own Linux distribution for Itanium, and SCO saw some of its Monterey source in the distro, SCO might have a claim.
Actually, I read somewhere Microsoft plans to support a serial console in the next revision of Windows. This was seen as necessary for managing large scale server farms. The rich shell is no doubt a prerequisite for it.
And no doubt, Microsoft will come up with a network installer like Solaris Jumpstart or AIX NIN.
"But with Spark's RISC instruction set and Sun's insistance on keeping both hardware and software closed, the cost/benefit balance was tipped."
First, Sun's hardware is not closed. Sun does not own SPARC. SPARC International does (www.sparcinternational.com). You can license the SPARC instruction set from them.
You can buy boards from Sun and build your own SPARC computers.
You can buy complete SPARC computers with no Sun hardware at all from Fujitsu.
You can obtain a license Solaris for single SPARC CPU systems for free (beer).
Solaris 8 is also available for Intel-based computers. Solaris 9 added no features of use for Intel, so the lack of availability for Solaris 9 is irrelavant.
A C compiler is NOT an installation tool for Solaris. Solaris has a modular kernel. You do not need to recompile the kernel when you make configuration changes.
This has been true since Solaris 2.0 (a.k.a., SunOS 5.0).
This is way a enterprise-grade operating environement is supposed to work.
The numbers game is really marketing, and Kernels are not marketed, distros are. "Linux 3.0" being new and better than "Redhat 7.2" is just too confusing.
Somebody said do it the Sun way. The distributors already do. The distros are to Linux what Solaris is to SunOS. Solaris 9 is just the latest "distro" of SunOS 5.x (uname says Solaris 9 is SunOS 5.9).
So I would say keep using 2.x as long as it is binary compatible, and a new major number would be for a major change. A new VM system is not.
Looking again at Solaris, they went from Solaris 2.6 to Solaris 7 and not 2.7 to communicate the shift to a full 64-bit address space and release of two distict kernels (32-bit and 64-bit). However, the underlying OS remained SunOS 5.7 for compatability reasons. The main reason for not calling the SunOS 5.7 distro "Solaris 2.7" was marketing, as HP-UX was on version 11 and AIX was on version 4.
Sun has made changes such as a extended memory support and 64-bit filesystem (Solaris 2.6), 64-bit memory addressing (Solaris 7), new VM and significant filesystem changes (Solaris 8), new threading model (Solaris 9), all while maintaining SunOS 5.x binary compatability.
So let the Distro's use the sexy numbers. Keep the kernel number indicative of stability and compatability.
That's what's happening here. It is much like ignoring somebody asking a question you do not know the answer to.
Today's development environments do not do a great job of autmatically parallelizing code, and there are very few outstanding multithreading programmers in this world. Thank goodness one of them is working on this for Linux. The improvement in threading support is critical for Linux to scale in shared memory, multi-processor environments (SMP, NUMA), but will only be important for certain applications. The typical Slashdot reader uses a dual processor Linux system at best, where excellent multithreading is not necessary.
30 Hz has been the standard for viz sim for quite a while. Onyx IR has always built around how much realism it can put into that 30 FPS, not on making the frame rate faster.
The fact is, most games move through space at unrealistic speeds, and a higher frame rate helps. But most airline and military flight simulators are driven by SGI Onyx IR systems, running at 30 Hz.
GPL has always been about free (speech) source, not free (beer) binaries. UnitedLinux does not violate the spirit of this.
The community cannot have it both ways, with commercial interest and support via workable business models, and no defendable commercial version of the product.
UnitedLinux will actually provide the source of their distro, and they will provide their modifications to the community. They are just trying to productize a server based Linux.
Believe me businesses want a good, stable, supportable version of Linux to employ instead of Windows and UNIX.
"The licensing structure is broken up so that, depending on your needs (compiler, etc), you have to buy many pieces separately."
Yes the Sun compiler is separate (GCC comes with Solaris). A logging UNIX file system with concurrent direct I/O comes with Solaris. Disk mangement software comes with Solaris. CDE and Motif come with Solaris. A 200,000 entry commercial grade iPlanet LDAP server comes with Solaris (that's a $400,000 value if purchased separately).
A Solaris license for 1 to 8 CPUs is $0.
The Solaris media kit is $75.
The Forte C/C++ Workshop, single user: $1,995.00
"The full suite, as far as I am told is far in excess of $50,000."
Don't believe everything you hear.
The total software cost (for an 8-CPU or less system) with the Sun compiler is $2,070, or $75 with GCC.
Even if you added the Veritas Volume Manager and Veritas File system and upgraded the compiler to the Forte Enterprise Edition the total cost would be $17,560.
Of course, you could have found this information yourself at http://store.sun.com/.
"You are saying 'Sun pays the vendor to give support to the implementor' and then 'Sun is the vendor'. This is exactly what I said, Sun is not actually paying anyone else"
The last time I checked, support services equalled people. People cost money. And this means either Sun's own professional services, or contractors. Either way, Sun will be paying real dollars, either in salaries or contractor fees.
At http://www.sun.com/blueprints/0501/Naming.pdf you will find a Sun BluePrint entitled "Datacenter Naming Scheme" that offers methodologies to do exactly what you are looking for.
Sun software packaging utility, pkgadd, is useful and well know, however, with the rise of Linux and the Red Hat RPM format, is Sun considering supporting Solaris RPM packages, perhaps by using OpenPKG.
This would be similar to how Sun has adopted ZIP compression on newer patches.
"... an Open Source person within a company that hasn't yet fully grasped the concept,... "
Given that Sun has contributed more lines of code to the open souce community than any other, and is sponsoring the OpenOffice and NetBeans projects, RobLimo's comment is both petty and ignorant.
Perhaps a little less editorializing and a few more facts would be useful.
Fiorina says the workers were made redundant as HP moves away from so-called PA-RISC chip architecture to one based on an Intel platform. "These are great people with great talents," she says, "and they're able to be in a company where they're going to be nurtured. Because we're not going to be a chip R&D shop."
You are right. A short pipeline is a good thing, but to go really fast you have to have a longer pipeline. Copper and SOI can only get you so far. That is why POWER4 has a 14-stage pipeline.
"The 680 kicked the crap out of the SunFire 6800 in the Spec JBB benchmarks."
Yes, the p680, running a 64-bit JVM, did beat the 6800's 32-bit JVM score.
The 6800, on the other hand, beat the crap out of the previous IBM score, which was running a comparable 32-bit JVM.
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.
As for using TPC and SPEC, Gartner says this will cause over a 60% error in sizing. Not real smart to use such benchmarks when dealing with $1M machines.
"But until there's an independent authority that test boxes without bias"
Actually all you need is independent certification of the benchmark. Oracle Applications Standard benchmark is independently certified, and it can be used to effectively compare database systems. It is a much more thorough benchmark than TPC-C.
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.
Oh, and by the way, running Oracle 8.1.6 on the PeopleSoft 8 General Ledger benchmark, a 24 x 750 MHz Sun Fire doubled the 24 x 450 MHz S80's result. And on the most recent runs, a 6 x 750 MHz CPU Sun Fire result was 2.6 times a 6 x 668 MHz pSeries result. Oh, but IBM runs Oracle faster right? Maybe on TPC-C, but not on PeopleSoft. Why is there such a difference?
Every vendor's systems have a "sweet spot" and do well on certain benchmarks. So when you evaluate systems, you need to use a whole bunch of benchmarks, and I would recommend throwing out the extremes because they essentially are statistical outliers. Those corner cases will rarely translate to real-world performance.
Slashdot Mirror
This is not an IBM technology, but instead is based on a technology developed by Transitive.
It would be much more useful if IBM would offer the version of Transitive software which allows POWER applications to run on x86 systems, rather than the reverse. The only thing which makes sense to run on a emulator on a IBM POWER system would be a mainframe environment.
Why emulate the most mass-produced CPU instruction set ever, given the ISA is still in mass production? Why emulate the cheap volume processor on a more expensive, proprietary platform? The reverse makes much more sense. The more expensive, more closed architecture should be emulated on the less expensive, more open platform.
I fail to understand what value running x86 Linux apps on POWER provides. Intel Woodcrest and AMD Opteron provide great 64-bit performance, the AMD/Intel competition keeps prices dirt cheap and innovation moving at light-speed, and VMware provides fine-grained virtualization. And just like the AMD/Intel war keeps processor prices low, the coming Xen/VMware war is going to cut the cost of virtualization.
Emulators are needed to support customers on processor architectures which are dead. That is Alpha and PA-RISC. Next would be current platforms which customers want to move off of. That would be the Mainframe first, then Itanium, and after that perhaps SPARC and POWER.
There are clearly some weird politics going on at Transitive.
HP's partnership with Transitive is not focused on taking care of HP's own Alpha and PA-RISC customers, but instead on offering a SPARC on Itanium emulator. HP does have a partnership with a mainframe emulator, which makes some sense, but why not offer consolidated hosting to your own existing customers first?
IBM's partnership with Transitive is not focused on POWER or mainframe customers, but instead on offering an x86 on POWER emulator.
I can never envision the business case for emulating the industry-standard x86 architecture on a proprietary RISC platform like IBM's POWER.
I would love to see VMware buy Transitive and offer the ability to create Alpha, PA-RISC, Mainframe, Itanium, POWER, and SPARC VMs on ESX server. Of course if they did that, it would be EMC declaring war on the rest of the IT industry, but it would be a really cool product.
The 7 second boot was for a zone within a Solaris instance, so this was not a complete boot.
6 #boot_chart_results
It looks like the complete boot took 32.6 seconds.
See:
http://blogs.sun.com/roller/page/eschrock/2005010
The $3,500 USD is not the price of a 4-way capable, 4 rack unit system fully configured with 4 CPUs. From the article:
"A base configuration [emphasis added] of the 4U is expected to cost less than $3,500, sources said."
The $3,500 USD is likely the price of a 4-way capable, 4 rack unit system configured with only one CPU (a typical base configuration). Assuming about $1,000 to $1,500 USD for the server chassis, LVD SCSI boot disk, and memory, the PPC970 CPU is going to run for around $2,000-$2,500 USD per processor.
A fully configured 4-way PPC970 server will probably cost about $10,000 USD.
http://www.csicop.org/articles/20021018-aldrin/buz z-aldrin-punch-video.mpg
If a company is providing its own operating system support, it is now an operating system support company.
If a company is modifying the Linux kernel to fit its particular needs, it is now a Linux distributor.
People cost money. Somebody hacking the Linux kernel for Acme Manufacturing is the same as a Linux Kernel hacker for Red Hat. So the cost is still there.
Many companies do not want to be Linux distributors or Linux support companies. They will use a standard distribution such as Red Hat or Suse, tune it too their needs, and have somebody else handle the trouble ticket.
Newcomer to the market? Sun buys its 2-way Intel servers from the same manufacturer that many vendors buy their 2-way Intel servers from, and that manufacturer is not new to the market.
Furthermore, most Intel servers use either Intel motherboards or Broadcom motherboards. So if vendor B is buying 2-way Xeon boxes based on Intel motherboards from an Asian assembler that puts a blue plastic shell on the motherboard, and vendor B is doing the same thing, albeit with the Asian assembler using a black plastic shell, and both vendors outsource their hardware support to the same company that specializes in low-end Intel server support, and both vendors provide Red Hat but outsource their software support to Red Hat, what is the difference, or what is the relavance of how long the the vendor has been in the market?
Your statement makes about as much sense as if Sun had switched from Seagate to Hitachi hard drives in its systems, and you said Sun is a newcomer to the Hitachi hard drive market.
2-way x86 servers are commodities. The only significant companies innovating on these are Intel, AMD, and Broadcom. Not the companies that acutually sell them.
x86 *NIX with all of the familiar Sun tools?
Port all of the Solaris tools to Linux and produce a "proprietary" distro?
It's called Solaris x86! That is what Sun is doing. Customers who want Linux want Red Hat, Suse, etc. So Sun will support those distros on its x86 boxes.
For customers who want an x86 *NIX solution that provides the exact same management tools and interfaces, Sun has brought back Solaris x86.
To me this is the perfect solution. It addresses both requests easily.
The plaintif sounds similar to many displaced middle aged people. When times are tough, the middle aged, who are better paid, claim they are laid off in favor of the young.
I doubt the national origin of the workers had anything to do with this. It is just a convenient screen.
Given that project Monterey was about developing a commercial UNIX for Itanium, and given that IBM abandoned SCO and produced AIX5L for Itanium and discontinued it shortly thereafter, I really do not know what SCO's beef is.
Project Monterey had nothing to do with x86. So what if IBM is pushing Linux on x86.
Now if IBM produced its own Linux distribution for Itanium, and SCO saw some of its Monterey source in the distro, SCO might have a claim.
Actually, I read somewhere Microsoft plans to support a serial console in the next revision of Windows. This was seen as necessary for managing large scale server farms. The rich shell is no doubt a prerequisite for it.
And no doubt, Microsoft will come up with a network installer like Solaris Jumpstart or AIX NIN.
http://www.sunsource.net/
"But with Spark's RISC instruction set and Sun's insistance on keeping both hardware and software closed, the cost/benefit balance was tipped."
First, Sun's hardware is not closed. Sun does not own SPARC. SPARC International does (www.sparcinternational.com). You can license the SPARC instruction set from them.
You can buy boards from Sun and build your own SPARC computers.
You can buy complete SPARC computers with no Sun hardware at all from Fujitsu.
You can obtain a license Solaris for single SPARC CPU systems for free (beer).
Solaris 8 is also available for Intel-based computers. Solaris 9 added no features of use for Intel, so the lack of availability for Solaris 9 is irrelavant.
A C compiler is NOT an installation tool for Solaris. Solaris has a modular kernel. You do not need to recompile the kernel when you make configuration changes.
This has been true since Solaris 2.0 (a.k.a., SunOS 5.0).
This is way a enterprise-grade operating environement is supposed to work.
The numbers game is really marketing, and Kernels are not marketed, distros are. "Linux 3.0" being new and better than "Redhat 7.2" is just too confusing.
Somebody said do it the Sun way. The distributors already do. The distros are to Linux what Solaris is to SunOS. Solaris 9 is just the latest "distro" of SunOS 5.x (uname says Solaris 9 is SunOS 5.9).
So I would say keep using 2.x as long as it is binary compatible, and a new major number would be for a major change. A new VM system is not.
Looking again at Solaris, they went from Solaris 2.6 to Solaris 7 and not 2.7 to communicate the shift to a full 64-bit address space and release of two distict kernels (32-bit and 64-bit). However, the underlying OS remained SunOS 5.7 for compatability reasons. The main reason for not calling the SunOS 5.7 distro "Solaris 2.7" was marketing, as HP-UX was on version 11 and AIX was on version 4.
Sun has made changes such as a extended memory support and 64-bit filesystem (Solaris 2.6), 64-bit memory addressing (Solaris 7), new VM and significant filesystem changes (Solaris 8), new threading model (Solaris 9), all while maintaining SunOS 5.x binary compatability.
So let the Distro's use the sexy numbers. Keep the kernel number indicative of stability and compatability.
That's what's happening here. It is much like ignoring somebody asking a question you do not know the answer to.
Today's development environments do not do a great job of autmatically parallelizing code, and there are very few outstanding multithreading programmers in this world. Thank goodness one of them is working on this for Linux. The improvement in threading support is critical for Linux to scale in shared memory, multi-processor environments (SMP, NUMA), but will only be important for certain applications. The typical Slashdot reader uses a dual processor Linux system at best, where excellent multithreading is not necessary.
"At Sun $15.000 would qualify for that..."
Where have you been?
SPARC/Solaris Servers from Sun start at $995.
SPARC/Solaris Workstations from Sun start at $995.
30 Hz has been the standard for viz sim for quite a while. Onyx IR has always built around how much realism it can put into that 30 FPS, not on making the frame rate faster.
The fact is, most games move through space at unrealistic speeds, and a higher frame rate helps. But most airline and military flight simulators are driven by SGI Onyx IR systems, running at 30 Hz.
GPL has always been about free (speech) source, not free (beer) binaries. UnitedLinux does not violate the spirit of this.
The community cannot have it both ways, with commercial interest and support via workable business models, and no defendable commercial version of the product.
UnitedLinux will actually provide the source of their distro, and they will provide their modifications to the community. They are just trying to productize a server based Linux.
Believe me businesses want a good, stable, supportable version of Linux to employ instead of Windows and UNIX.
"The licensing structure is broken up so that, depending on your needs (compiler, etc), you have to buy many pieces separately."
Yes the Sun compiler is separate (GCC comes with Solaris). A logging UNIX file system with concurrent direct I/O comes with Solaris. Disk mangement software comes with Solaris. CDE and Motif come with Solaris. A 200,000 entry commercial grade iPlanet LDAP server comes with Solaris (that's a $400,000 value if purchased separately).
A Solaris license for 1 to 8 CPUs is $0.
The Solaris media kit is $75.
The Forte C/C++ Workshop, single user: $1,995.00
"The full suite, as far as I am told is far in excess of $50,000."
Don't believe everything you hear.
The total software cost (for an 8-CPU or less system) with the Sun compiler is $2,070, or $75 with GCC.
Even if you added the Veritas Volume Manager and Veritas File system and upgraded the compiler to the Forte Enterprise Edition the total cost would be $17,560.
Of course, you could have found this information yourself at http://store.sun.com/.
The last time I checked, support services equalled people. People cost money. And this means either Sun's own professional services, or contractors. Either way, Sun will be paying real dollars, either in salaries or contractor fees.
At http://www.sun.com/blueprints/0501/Naming.pdf you will find a Sun BluePrint entitled "Datacenter Naming Scheme" that offers methodologies to do exactly what you are looking for.
My question would be the following:
Sun software packaging utility, pkgadd, is useful and well know, however, with the rise of Linux and the Red Hat RPM format, is Sun considering supporting Solaris RPM packages, perhaps by using OpenPKG.
This would be similar to how Sun has adopted ZIP compression on newer patches.
" ... an Open Source person within a company that hasn't yet fully grasped the concept, ... "
Given that Sun has contributed more lines of code to the open souce community than any other, and is sponsoring the OpenOffice and NetBeans projects, RobLimo's comment is both petty and ignorant.
Perhaps a little less editorializing and a few more facts would be useful.
"PA-RISC isn't dead."
... made redundant!
Carly Fiorina would disagree:
Fiorina says the workers were made redundant as HP moves away from so-called PA-RISC chip architecture to one based on an Intel platform. "These are great people with great talents," she says, "and they're able to be in a company where they're going to be nurtured. Because we're not going to be a chip R&D shop."
The weren't fired. They were
You are right. A short pipeline is a good thing, but to go really fast you have to have a longer pipeline. Copper and SOI can only get you so far. That is why POWER4 has a 14-stage pipeline.
"The 680 kicked the crap out of the SunFire 6800 in the Spec JBB benchmarks."
Yes, the p680, running a 64-bit JVM, did beat the 6800's 32-bit JVM score.
The 6800, on the other hand, beat the crap out of the previous IBM score, which was running a comparable 32-bit JVM.
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.
As for using TPC and SPEC, Gartner says this will cause over a 60% error in sizing. Not real smart to use such benchmarks when dealing with $1M machines.
"But until there's an independent authority that test boxes without bias"
Actually all you need is independent certification of the benchmark. Oracle Applications Standard benchmark is independently certified, and it can be used to effectively compare database systems. It is a much more thorough benchmark than TPC-C.
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.
Oh, and by the way, running Oracle 8.1.6 on the PeopleSoft 8 General Ledger benchmark, a 24 x 750 MHz Sun Fire doubled the 24 x 450 MHz S80's result. And on the most recent runs, a 6 x 750 MHz CPU Sun Fire result was 2.6 times a 6 x 668 MHz pSeries result. Oh, but IBM runs Oracle faster right? Maybe on TPC-C, but not on PeopleSoft. Why is there such a difference?
Every vendor's systems have a "sweet spot" and do well on certain benchmarks. So when you evaluate systems, you need to use a whole bunch of benchmarks, and I would recommend throwing out the extremes because they essentially are statistical outliers. Those corner cases will rarely translate to real-world performance.