Slashdot Mirror

Actually, the problem with that Intel vs AMD CPU
cookout video that Toms showed a while back was
not AMD's fault at all. They claimed the AMD CPU
will continue to run until it fries itself, while
the Intel CPU used Speedstepping to cool itself
down if needed.

The problem with the video was that the CPU *DID*
have an on core thermal diode... but Tom's
PURPOSELY used an Athlon based motherboard THAT
DID NOT SUPPORT IT. It was the fault of the
motherboard maker and Tom's unsurprisingly
selective choice of that motherboard... and that
was why the CPU fried itself. Hello? Has anyone
SEEN those CPU Shutdown Temp settings in the BIOS?
I turned those on in my test rig and COULD NOT
fry my AMD CPU.

So much for Tom's "in depth" reporting. The guy's
a total sell-out. (Which is obvious) But since he
did the worst possible thing in the reporting and
journalistic point of view: Changed the credits
on articles previously written by another writer
just to spite him. (Van Smith over at Van's
Hardware.) Bad. I have absolutely no respect or
trust for Tom's anymore and never will because
of these two incidents... and there have been a
few more. I'm sure other /. posters will
eventually point them all out.

Fuck it, I'll link the examples myself.

Link One - Kyle from HardOCP's
comment about Tom's misleading video.
Found in the Ace's Hardware Forums.

Link Two - Post taken from AMDZone
posted on Ace's Hardware Forums about Tom's
Hardware modifying Van's articles to credit a
different author. Forum responses results in
some additional info. Read through the threads.

Actually, the problem with that Intel vs AMD CPU
cookout video that Toms showed a while back was
not AMD's fault at all. They claimed the AMD CPU
will continue to run until it fries itself, while
the Intel CPU used Speedstepping to cool itself
down if needed.

The problem with the video was that the CPU *DID*
have an on core thermal diode... but Tom's
PURPOSELY used an Athlon based motherboard THAT
DID NOT SUPPORT IT. It was the fault of the
motherboard maker and Tom's unsurprisingly
selective choice of that motherboard... and that
was why the CPU fried itself. Hello? Has anyone
SEEN those CPU Shutdown Temp settings in the BIOS?
I turned those on in my test rig and COULD NOT
fry my AMD CPU.

So much for Tom's "in depth" reporting. The guy's
a total sell-out. (Which is obvious) But since he
did the worst possible thing in the reporting and
journalistic point of view: Changed the credits
on articles previously written by another writer
just to spite him. (Van Smith over at Van's
Hardware.) Bad. I have absolutely no respect or
trust for Tom's anymore and never will because
of these two incidents... and there have been a
few more. I'm sure other /. posters will
eventually point them all out.

Fuck it, I'll link the examples myself.

Link One - Kyle from HardOCP's
comment about Tom's misleading video.
Found in the Ace's Hardware Forums.

Link Two - Post taken from AMDZone
posted on Ace's Hardware Forums about Tom's
Hardware modifying Van's articles to credit a
different author. Forum responses results in
some additional info. Read through the threads.

The Opteron was intended to be used in multiprocessor configurations with a NUMA design, and functions optimally with processor-local memory and a NUMA-aware OS. This benchmark was done with a degenerate motherboard on which all of the system memory is attached to one of the processors. The other processor must access all system memory indirectly through its peer, and its integrated dual-channel DRAM controller is not utilized at all, halving the maximum memory bandwidth of the system.

Few mass-market dual Opteron boards available now support processor-local memory on both CPUs. Sadly, most vendors seem reluctant to discuss this rather important detail in their whitepapers and marketing material. I think Tyan's boards, specifically their K8W desktop board, does this correctly and is a good choice from this point of view, but costs upwards of $450.

Even with a better designed motherboard, this benchmarker used Windows XP, which is not NUMA-aware. More recent Server 2003 and Linux releases are NUMA-aware, and would have to have been used to take advantage. Such details have been shown to boost performance by 20% in different but more reputable benchmarks.

The Opteron's new memory architecture is arguably a larger advantage over previous generations than its 64-bit arithmetic and addressing modes. This is a feature that it does not share with the G5.

If you haven't seen any documentation it's only because you haven't looked hard enough!

There have been a number of tests comparing Opteron and Athlon64 processors in 32-bit and 64-bit mode under Linux and even a few that use Windows (beta version of WinXP). Here are a few links:

First off, some SPEC CINT2000 numbers: 32-bit OS + 32-bit apps, 64-bit OS + 32-bit apps and 64-bit OS + 64-bit apps. Unfortunately there are no similar CFP2000 numbers since GCC Fortran isn't up to the task, so you end up with lots of different variables making it nearly impossible to compare.

There is also this areticle at Ace's Hardware, and this little bit on Anandtech. Other tests exist.

Long story short, 64-bit support on the Opteron can and often does improve performance, even on apps that don't require lots of memory or use 64-bit integers. The extra registers help.

As for compilers, Microsoft plans on supporting AMD64 in their Visual.net 2003 compiler (beta versions are available now) and GCC supports the instruction set now. That makes up the compilers used for the vast majority of applications. As you mention, PGC is also doing a compiler, and it seems that Sun will support AMD64 with their compiler as well. Here is the AMD64 Developer Resource Kit page which lists all sorts of software with support for the AMD64 instruction set.

" a 400 Mz P2,"
" the AMD chips are not nearly as capable as Intel chips, even today."

Interesting how the poster talks about modern CPU capabilities, then proceeds to tell us a delightful story about how he had problems using a pair of 5 year old processors.

As for benchmarks being only good for producing reproducable numbers, this is in fact the case for synthetic benchmarks. Most hardware sites now test using actual games, reporting the average framerate received, and test how long it takes to render a given image or sequence, reporting the time taken to do so. Now, what part of "you get 40 frames per second while playing this game if you use this CPU, or 30 frames per second if you use this other CPU." is not "indicative of actual performance based on real usage"?

Use Ace's Specmine to search Specint2000 and Specfp2000 data. This is the best frontend I have seen for the data. Keep in mind the details of a system before you start trolling chipA over chipB. Of course, you can also use this to feed such trolls. ;)

Ace's (Recommended)

Ars

HardOCP

Tom's

Anandtech (Recommended)

Take all benchmark results with a grain of salt. Many things can influence the results, and some sites like Tom's have long been known to be quite biased. If you read enough sites though, you tend to get a much better overall picture of how things really are.

"A few other popular sources of information include:"

Not to mention Ace's if you're really into all the nitty gritty details of things. They do outstanding reviews and technical articles, but can get pretty heavy on the technical details. So far, Ace's is the only place I've found that actually goes over my head from time to time. I do enjoy the challenge. ;)

I've been benchmarking the opteron for the last week, it is at least 26% faster on high mysql load vs a comparably priced opteron system.

Tom's Hardware, Anandtech and aceshardware have all benchmarked the opteron on linux. Tom's hardware's benchmarking isn't that great, aces hardware does the best job.. The Opteron kicked butt in all reviews.

This is by far the best review so far IMO:

http://aceshardware.com/read.jsp?id=60000275

We're going to order a bunch of them by the end of this year so the government doesn't hit us with too many taxes, woo hoo!

there is something, err, nope I still don't see any server with anything like a pedegree that runs AMD chips.

Oh now it's about sales to major corporations? All that I was saying is if Cray, IBM, and Sun servers don't have a decent pedigree then who does?

The Opteron is not a from scratch design, it's an evolution of the XP/MP Athlons so much of the underlying technology is more mature than its new moniker may imply. The chip has been out in its present state for less than a year and has gotten a number of supercomputer wins so it's no secret that these are monster chips.

There's also the fact that in many cases they outperform equivalent Intel chips at cooler temps and lower prices. If they aren't adopted, it will probably have more to do with marketing than technology.

I am not a Sun suporter, but apparently Solaris 10 should have this kind of implementation, according to this article. It will have "military grade" security as default, and the root user will be eliminated in favor of "specific roles" (I don't know what this means, the article is very thin). Something to keep an eye on.

" Is the Itanium's (Itanic?) 64 bit setup faster or better then AMDs?"

Most of the performance comparisons you'll find would be at Ace's. The big problem with Itanium (aside from the price), is the hit you take when you try to do something with 32-bit code. Itanium requires heavy optimization on all fronts before it begins to perform reasonably well. Opteron will run whatever the hell you throw at it, and it'll run it quickly. Aside from that, why drop $10,000 on an Itanium when a faster Opteron can be had for $1,000? AMD's 64-bit platform was never really designed to compete with Itanium anyway. The Athlon64 competes with the higher-end P4s and low-end Xeons, where it offers excellent performance and 64-bit technology. The AthlonFX competes with low-end to high-end Xeons in workstations and gaming machines (think EE) where it, again, offers comparable or higher performance while sporting 64-bit instructions that allow for things like more addressable memory. The Opteron competes with mid to high-end Xeon single and multi-processor workstations and servers. Opteron also competes somewhat with the low-end Itanium market; those who want/need 64-bits but can't really afford Itanium's price tag. Once you get into the higher end of Itanium's spectrum, there's plenty of competition from Sun, IBM, and others. Opteron might do better here once AMD starts throwing multiple cores on each chip, but probably won't even try for these types of customers (except with clusters) with this generation of chips(K8/K9).

"For that matter, is WindowsXP 64bit compatible with BOTH 64bit chips or only with the AMD ones?"

My understanding is such that M$'s 64-bit Windows is still in development for both chips, but that the Itanium version is set to be released sooner. In any event, they're supposedly specifically optimizing 64-bit Windows for the AMD 64-bit instruction set, which should give us some outstanding performance boosts. Look for the 64-bit Windows for AMD64 to be released to the public some time around Q3 '04.

Your XP on the other hand is different. A lot higher clock speed, higher memory speed, a LOT more heat

After this be sure to check out Ace's Hardware

The move to a Java-based web application marks a giant step forward for our site software. While the "applications" we previously ran on Apache and PHP were little more than individual scripts interpreted by the webserver on request, the new site is in and of itself a complete, running, multithreaded application. When a request is made, the application starts a new thread to serve the request. Database connections are allocated as needed from a shared connection pool, maintained by the application.

In the case of the interpreted scripts of old, programs were compiled and executed on the fly in a stateless manner. The scripts only ran when they were requested, and so there was no communication between threads or components and no sharing of resources.

Our new software platform enables us to build true stateful applications that can create and share global resources. For instance, our message forums make use of a shared message index cache that, for all in intents and purposes, frees the database from nearly all read activity. The cache is shared in memory amongst all threads and it is only updated when a write operation is made to the database for a new posting, an edit, or a deletion. Such a cache would be very difficult to implement in something like PHP or PERL because its not possible to share persistent objects among different instances of an interpreted script.

Our old web application was written in PHP and ran on Apache, a "pre-fork" multiprocess HTTP server. Apache works by starting a parent process which then forks several child processes to listen and wait for HTTP connections. Since, each of these child processes serves one HTTP request at a time, Apache creates a pool of processes to handle connections in a timely fashion.

The disadvantage of this approach is that it can result in a great deal of overhead due to the 1:1 ratio between processes and requests. This can be particularly true in the case of HTTP keepalives, a feature designed to speed up web serving by handling multiple sequential requests from a client on the same connection, saving the time of having to build up a new connection for each request. The disadvantage comes into play when a child process is forced to wait a given amount of time on a client before accepting a connection from a different client. If the keepalive timeout is 15 seconds, then each Apache process will be unable to handle any other connections for 15 seconds following the final request from a client.

This means an Apache web server using keepalives will need to have more child processes running than connections. Depending upon the configuration and the amount of traffic, this can result in a process pool that is significantly larger than the total number of concurrent connections. In fact, many large sites even go so far as to disable keepalives on Apache simply because all the blocked processes consume too much memory.

Another issue with a multiproces

The move to a Java-based web application marks a giant step forward for our site software. While the "applications" we previously ran on Apache and PHP were little more than individual scripts interpreted by the webserver on request, the new site is in and of itself a complete, running, multithreaded application. When a request is made, the application starts a new thread to serve the request. Database connections are allocated as needed from a shared connection pool, maintained by the application.

In the case of the interpreted scripts of old, programs were compiled and executed on the fly in a stateless manner. The scripts only ran when they were requested, and so there was no communication between threads or components and no sharing of resources.

Our new software platform enables us to build true stateful applications that can create and share global resources. For instance, our message forums make use of a shared message index cache that, for all in intents and purposes, frees the database from nearly all read activity. The cache is shared in memory amongst all threads and it is only updated when a write operation is made to the database for a new posting, an edit, or a deletion. Such a cache would be very difficult to implement in something like PHP or PERL because its not possible to share persistent objects among different instances of an interpreted script.

Our old web application was written in PHP and ran on Apache, a "pre-fork" multiprocess HTTP server. Apache works by starting a parent process which then forks several child processes to listen and wait for HTTP connections. Since, each of these child processes serves one HTTP request at a time, Apache creates a pool of processes to handle connections in a timely fashion.

The disadvantage of this approach is that it can result in a great deal of overhead due to the 1:1 ratio between processes and requests. This can be particularly true in the case of HTTP keepalives, a feature designed to speed up web serving by handling multiple sequential requests from a client on the same connection, saving the time of having to build up a new connection for each request. The disadvantage comes into play when a child process is forced to wait a given amount of time on a client before accepting a connection from a different client. If the keepalive timeout is 15 seconds, then each Apache process will be unable to handle any other connections for 15 seconds following the final request from a client.

This means an Apache web server using keepalives will need to have more child processes running than connections. Depending upon the configuration and the amount of traffic, this can result in a process pool that is significantly larger than the total number of concurrent connections. In fact, many large sites even go so far as to disable keepalives on Apache simply because all the blocked processes consume too much memory.

Another issue with a multiproces

The move to a Java-based web application marks a giant step forward for our site software. While the "applications" we previously ran on Apache and PHP were little more than individual scripts interpreted by the webserver on request, the new site is in and of itself a complete, running, multithreaded application. When a request is made, the application starts a new thread to serve the request. Database connections are allocated as needed from a shared connection pool, maintained by the application.

In the case of the interpreted scripts of old, programs were compiled and executed on the fly in a stateless manner. The scripts only ran when they were requested, and so there was no communication between threads or components and no sharing of resources.

Our new software platform enables us to build true stateful applications that can create and share global resources. For instance, our message forums make use of a shared message index cache that, for all in intents and purposes, frees the database from nearly all read activity. The cache is shared in memory amongst all threads and it is only updated when a write operation is made to the database for a new posting, an edit, or a deletion. Such a cache would be very difficult to implement in something like PHP or PERL because its not possible to share persistent objects among different instances of an interpreted script.

Our old web application was written in PHP and ran on Apache, a "pre-fork" multiprocess HTTP server. Apache works by starting a parent process which then forks several child processes to listen and wait for HTTP connections. Since, each of these child processes serves one HTTP request at a time, Apache creates a pool of processes to handle connections in a timely fashion.

The disadvantage of this approach is that it can result in a great deal of overhead due to the 1:1 ratio between processes and requests. This can be particularly true in the case of HTTP keepalives, a feature designed to speed up web serving by handling multiple sequential requests from a client on the same connection, saving the time of having to build up a new connection for each request. The disadvantage comes into play when a child process is forced to wait a given amount of time on a client before accepting a connection from a different client. If the keepalive timeout is 15 seconds, then each Apache process will be unable to handle any other connections for 15 seconds following the final request from a client.

This means an Apache web server using keepalives will need to have more child processes running than connections. Depending upon the configuration and the amount of traffic, this can result in a process pool that is significantly larger than the total number of concurrent connections. In fact, many large sites even go so far as to disable keepalives on Apache simply because all the blocked processes consume too much memory.

Another issue with a multiproces

Some of the 5% could be organizations that only had MS expertise in-house, and were attempting to convert to Linux, only to find that it turned out more expensive for them because they were forcing their Linux servers to act like windows. See here.

Oh, and...

Or perhaps it came with a hardware upgrade and they got it packaged. So they just replaced the linux system with the win2003.

I believe I read a quote from just such a PHB while reading some of the Win 2003 rollout coverage. It was a guy who was saying something like, "yeah, we're replacing 10 of our old linux servers with only 3 new Windows 2003 servers. What a cost savings!"

The linux machines were probably Pentium-1's or something. Ugh.

Follow this link ... 2.8Ghz Athlon FX for talk and benchmarks.

P4 Emergency Edition looks like from past centruy in light of this. Ok, probably one can overclock that chip too.

HardOCP
Tom's hardware
Ace's Hardware
As you would expect, no chip is dominate. though the more interesting thing for me than the nip and tuck between $800 CPUs, is the Athlon64 3200+ performs right there with the 3.2C in mosts lets. Not bad considering it retails for more than $100 less.

Here are some more benchmarks

AMDzone
AnandTech
XbitLabs
Ace Hardware

There are even more at AMDZones main page.

Apple used GCC in their P4 benchmarks. It's a well known fact that GCC doesn't produce very fast code.

Here are some real results:

Spec Int base, 1 CPU:
2GHz Opteron: 1248
3.06GHz Xeon with 1MB of L3: 1242
3.2GHz Pentium 4: 1221

Apple score:
2GHz G5: 800

Spec FP base, 1 CPU:
2GHz Opteron: 1209
3.06GHz Xeon with 1MB of L3: 1173
3.2GHz Pentium 4: 1271

Apple score:
2GHz G5: 840

Spec Int rate, 2 CPUs:
2GHz Opteron: 28.8
3.06Ghz Xeon with 1MB of L3: 25.8

Apple score:
2GHz G5: 17.2

Spec FP rate, 2 CPUs:
2GHz Opteron: 28.1
3.06Ghz Xeon with 1MB of L3: 19.6

Apple score:
2GHz G5: 15.7

In single CPU benchmarks new G5 reaches 2/3 of Opterons/P4s performance. In dual CPU benchmarks Opteron is twice as fast as G5!

Ace's Hardware has a review you might be interested in reading:
Professional Grade Revisited

However IBM's recent entry, the PPC970, has radically altered the desktop landscape. The new Apple computers powered with the PPC970 are genuine workstations sold as desktops. The ARS Technica article indicates that the SPEC2000 performance for the PPC970 is 937 and 1051 for integer applications and floating-point applications, respectively. The Athlon64 is a weaker version of the server chip, the Opteron. The PPC970 has about the same performance as the Opteron. (reference: SPEC performance list)Hence, the PPC970 is sure to beat Athlon64 across a broad range of applications.

What is particularly interesting about the PPC970 is that it was designed and built largely without H-1B employees. Both IBM and HP have a policy of not hiring anyone who does not have American citizenship or permanent residence unless that applicant has a Ph.D. Clearly, American companies do not need H-1B employees to produce awesome products.

I guess AGP 3.0 Spec allows this. Although the next reply seems to disagree, but the one after that agrees. hmm.

Also, the Alpha Server has 2 AGP slots as an option, but that's not a typical gamer machine.

Here, is further proof that AGP 3.0 allows 2 AGP slots:

The general layout of the A7N8X Deluxe shows one AGP Pro slot and five PCI slots. This is different from the A7N266(-E) and also different from the preproduction boards that were circulated courtesy of AMD and that featured the additional ACR slot for modem and sound riser cards. Also keep in mind that we have taken it granted for the longest time that the one AGP slot we are looking at is always the only AGP slot possible. This has changed with the definition of the AGP3.0 specifications that brought us AGP 8X mode and, among other goodies allows 2 AGP slots. On the A7N8X we are still looking at a single AGP slot, though. It will be interesting to see who will come out with a dual AGP board first.

Freakin Cool Man, I may have to upgrade from my awesome machine once they come out if DRM/Palladium isn't too overwhelming on these new boards. I also think the processor has to have support for AGP 3.0 for it to be worthwhile as well, but I'm not sure.

Aces Hardware article about how to handle a "slashdotting" with one 500MHz UltraSPARC IIe CPU (Sun Blade 100/Blade 150 system) driving both the webserver and the database server.

I've seen SMP Sun servers with Oracle and Weblogic choke under lower load. Basically, for the guy asking about .NET: No magic fairy is going to come in the box set for .NET to make his application scale well. He really is on his own to do it right.

You idiot. I am sick of hearing people say how slow Java is, I've had enough. Look here (a repeat of benchmarking done 2 years ago found here) to find benchmarks showing some Java code (using jdk1.4.1) running faster then C++ code compiled with GCC. I'm not saying Java is faster then C++, what I am saying is that Java is not slow, the difference is small and getting smaller, and I think it speaks directly to the intellect of "malocchio" when he bases his opinions on what may have been the case SEVERAL years ago. But that's just me.

This page posted earlier lists the Dual Xeon has having a much higher set of scores than the ones Apple posted for their G5... what gives?

Compare Apple's numbers against the official SPEC results from other companies.

The PPC970 wit its Power4 core, clocked at 1.6GHz completely trashes a 3GHz P4. Faster bus, faster integer, and completely outclasses the P4 for FPU and SIMD.

Running at 1.8 GHz on a 0.13-micron process, the PowerPC 970 is estimated to deliver 937 SPECint2000 and 1051 SPECfp2000. By comparison, the current 3.06 GHz Pentium 4 achieves 1085 SPECint2000 Base and 1092 SPECfp2000 Base.

There are benchmarks comparing the Athlon XP 3200+ vs the Intel P4-C 3 Ghz. Here is an article that does that, showing the P4-C beating the Athlon XP 3200+ in 6 out of 10 benchmarks. The problem with benchmarks, though, is they can unfairly take advantage of particular features of the hardware to show a result that is unrepresentative of what you would see if you were using it. For example, the benchmarks that Tom's Hardware use strongly favor processors with 'Hyperthreading' and SSE2 instructions. The P4 has those features while the Athlon XP does not, benchmarks which favor those features will indicate a better result with the P4-C. This would be fine if all, or even most, software supported hyperthreading and SSE2 but the reverse is true so the benchmarks which exclusively favor these features are therefore unrepresentative of the software in use.

The 970 is a great chip. It's benchmarks at the Microprocessor Forum VERY HANDILY beat EVERY processor put up against it - even the AMD 64 bit!

Java isn't an interpreted language, in the traditional sense. Interpretation implies that the runtime environment interprets the source as it progresses, and e.g. that errors that would have been caught compiletime by others, are reported runtime.

When it comes to performance, it's about time to kill the old idea that java performs so incredibly bad. Look at e.g. this article for a measurement of how well java performed a few years ago. I didn't at first glance find any articles doing similar comparisions using the more recent VMs, but as vendors put effort into still more optimizations, I'd not expect the results to be worse now.

Another aspect of this that you might not have considered is how the JVM is at an advantage over static compilers, as it has the possibility to generate native code *runtime*, using real information on e.g. branching to generate native code which'll keep the CPU pipelines filled. A static compiler cannot do this to the same degree, so it is possible to construct scenarios where Java performs better than natively compiled binaries.

He did play an important role in creating the modern Internet, though.

Interesting, if you look at the pipeline design of the PowerPC it is much closer to Intel than AMD. The PowerPC pipeline has sixteen stages, the Pentium 4 twenty, and the Athlon ten.

Presumably the P4 can reach higher clock speeds than the Athlon because there is less work to do at each pipeline stage. On the other hand a longer pipeline increases the probability of a stall, so the work done per clock cycle goes down.

I'd speculate that the PowerPC ought, therefore, to be able to achieve clock rates approaching but not equalling the P4, since they are both comparatively "over-pipelined". At the same time, the PowerPC ought to deliver slightly more throughput per clock cycle because the pipeline is slightly shorter.

Meanwhile, the Athlon will be running at a significantly lower clock rate, but delivering comparable throughput.

No, that's just not true. "64 bit" these days only tells you something about the size of a pointer but not much more.

It is very unlikely that on a well-defined 64 bit processors, half the processor remains idle when you use 32 bit operations.

From my understanding, that's exactly what happens. x86-64 simply extends the existing x86 standard of allowing each register to hold smaller values, but only a certain number of them by giving each portion of the register its own name. You don't gain access to 4 times the registers in 32-bit mode, unfortunately. In fact, you only have access to the standard 8 registers because 32-bit x86 only knows about 8 registers. But not even by running 32-bit data in 64-bit mode do you gain the ability to store two 32-bit values in each GPR.

Check out this chart from the article I linked in my earlier post.

The Opteron has 64-bit general purpose registers, so any code that uses 64-bit integer operations should benefit a lot - using 2 32-bit registers, to do a 64-bit integer multiply takes 4 32-bit multiplies, and a 64-bit add requires 2 32-bit adds. To show this we have a custom micro-benchmark just on the Opteron which performs a "dot product" operation on two arrays of integers, which requires a lot of multiplies, with 32-bit and 64-bit integer versions and x86-32 and x86-64 code, using GCC.

[chart omitted]

The x86-64 version is 33% faster for 32-bit integers, probably due to greater loop-unrolling. With 64-bit operations, the x86-64 version is a massive 354% (4.54x) faster, with a combination benefit of more registers and 64-bit processing. Notice also that the 64-bit x86-64 result is the same as the 32-bit x86-32 result - with double the complexity of the data, performance is the same.

So that's what I was talking about, it simply takes more time, more iterations, for a 32-bit processor (one that operates on 32-bit data) to virtually process a 64-bit variable.

--Shon

Its much better at finding server-centric applications to benchmark:

Ace's Hardware Review

Here

The review is very good and contains lot of real-world Linux benchmarks.

Ace's hardware as an in-depth review as well, and it isn't slashdotted.
http://www.aceshardware.com/read.jsp?id=55000251

If your throwing enough money around to afford dual Xeon's then hyperthreading support be included.

More information about it is here and you can have virtual dual cpu's per processor. In theory you can have the performance of 4 cpu's with a dual processor setup.

For databases and ERP this could be a very nice and cheaper alternative to expensive IBM and Sun boxes.

My question is does Linux currently support hyperthreading? If not then it may be wise to put off the purchase or buy dual Athlon MP's which are alot cheaper and offer similiar benefits.

FWIW, Sun has a long-standing behavior of taking extra time to test new hardware, losing the cutting edge in favor of higher stability.

This appears to be true. For example, their UltraSPARC IIIi "just around the corner" press release was dated October, 2001.

It seems that the "less enlightened" folks out there stomp all over Sun for doing this and, then, take for granted that their server room seems to never cry for attention. Their hardware tends to be unusually durable, too, as I still see SPARCstation 5 or Ultra 1 workstations serving e-mail, dns, etc. without a hiccup.

Also, too many people are still on the Gigahertz craze. I find it interesting that Ace's Hardware runs off a single dinky 500MHz UltraSPARC IIe CPU. Even Slashdot appears to need only several obselete Pentium III and Xeons to handle a Slashdotting, literally, every moment of the day.

The chips are evolving, as described in the Marc Tremblay interview at Ace's Hardware.

The part that makes me happy is the idea of running other threads when one blocks on a memory fetch: my own experiments (with Samba and smbclient) in a benchmark show 80% of the time I'm waiting for a cache update from main memory, 20% of the time I'm making progress.

Being able to run a different thread until it blocks, then another and so on is a good idea, especially for a small server (4 threads per core, 8 cores per die, 32 threads per chip). This is being targeted for low-cost chipsets/boards like the blade servers, so it hits my area of interest right smack on the head.

The chips are evolving, as described in the Marc Tremblay interview at Ace's Hardware.

The part that makes me happy is the idea of running other threads when one blocks on a memory fetch: my own experiments (with Samba and smbclient) in a benchmark show 80% of the time I'm waiting for a cache update from main memory, 20% of the time I'm making progress.

Being able to run a different thread until it blocks, then another and so on is a good idea, especially for a small server (4 threads per core, 8 cores per die, 32 threads per chip). This is being targeted for low-cost chipsets/boards like the blade servers, so it hits my area of interest right smack on the head.

Anyway, my point is is that mainframe is a dated term, now synonymous w/ server.

If I'm mistaken, please, let me know.

What you're talking about are midrange servers. Mainframes are in an entirely different class.

Ace's Hardware had a good overview of them awhile ago.

Mainframes are a completely different world than what most people nowadays think of as computer systems. They are unbelievably hardcore. Imagine the computer equivalent of a cinderblock weapons factory in the former Soviet Union, full of workers chain-smoking cheap cigarettes. They get the job done well, but they are devoid of anything remotely resembling fun.

Please let me know what, from a business point of view, a mainframe can't do that a Solaris (or *laughs sarcastically* a Windows) box can?
Mainframes are in a different league, when it comes to reliablity, scalability and raw transaction power. Take a look at this article.

Wow, this is much faster than any ethernet cards on the market.

A DVD is 4.7gigs, just under 5gigabytes. They can transfer that in just under 5 seconds. So they claim to send about 1gig/sec. This is the bandwidth of PC133!! In therory. In reality it is lower. So you'll need DDR memory to sustain this tranfer speed.

Basically if all my Athlon 1200 with DDR was doing is streaming I can get 1120MB/sec, enough to read a DVD worth of data from memory in 4.3 seconds.

They claim they've made the internet as fast as my memory in my PC simply by using some new protocol?

I think I'm a skepic.

They run the whole thing off of a Sun Blade 500MHz with 2GB RAM.

Pretty cool actually.

And they have survived Slashdotting many times with a single 500MHz UltraSparc CPU and 2GB of SDRAM. More details can be found here and here.

And they have survived Slashdotting many times with a single 500MHz UltraSparc CPU and 2GB of SDRAM. More details can be found here and here.

Sun isn't about raw CPU power. For that we have POWER and x86. Sun is about massive scaling. Sure, 1 POWER4 or P4 or Athlon beats an Ultrasparc. And 8 USIIIs lose out to 8 POWER4s or Xeons or Hammer CPUs. But Intel and AMD drop off at about 8P systems (though ItaniumII can handle larger systems, and Opteron can scale past 8P with a HT bridge), and the POWER architecture scales to hundreds of processors. Sun though can pack a thousand chips in a single system image, with plans to scale to 4096 (IIRC) within the next 2 years.

I'm sure Sun would love to have a high-performance CPU to field against massive clusters being deployed for highly parallelizable tasks such as rendering, but the fact is that's not where their strengths lie. Huge tasks which cannot be efficiently split are what Sun is good at, tasks where superb scalability in terms of both CPU power and memory are an absolute must.

For more, read Ace's Hardware's excellent volume multiprocessor articles:
Part 1
Part 2
Part 3