Slashdot Mirror

I will start with mandatory links to the great series of articles that Ace's Hardware ran, describing their server scenario and their migration from PHP to Java/J2EE:

1. Building a Better Webserver
2. Building a Better Webserver in the 21st Century
3. Scaling Server Performance

The PHP Scalability Myth starts of by defining three types of server architectures. The first, two-tier, and the last, logical-three-tier, are the same conceptually (there is the slight distinction between whether display and business logic code is "mingled", but this is typically not a performance issue, but just an aesthetic or design issue). This two-tier/logical-three-tier architecture is the only one PHP supports natively. The article then proceeds to compare a two-tier PHP architecture against the most elaborate full three-tier Java architecture, which is used rarely in practice, and extremely rarely in the same domain in which a PHP solution is feasible. Instead of comparing apples and oranges (if PHP supported a full three-tier architecture, I would imagine two-tier PHP vs. three-tier PHP would have the same performance discrepencies), let's simply compare the only architecture PHP supports natively, two-tier, against JSP talking directly to a database, as this scenario is the most analogous to the PHP one. Let's also discard any caching as again this is something that Java handily accomodates but is not natively (or at least easily) available in PHP due to lack of state. And let's assume the database is the largest bottleneck.

The article states:

At the time when the first versions of the JSP and EJB standards were released, the prevalent web server was (and still is) Apache 1.x, which had a process model that was not compatible with Java's threading model. This meant that a small stub was required on the web server side to communicate with the servlet engine. The remains a non-trivial performance overhead for those that decide to pay it, and was a significant performance overhead when the first scalability comparisons were made.

I'm not sure what "stub" the article is referring to, but I will assume it means an Apache module which talks a "native" protocol to the servlet engine. The first such module was mod_jserv, which could run the servlet engine both in-process and over a compact protocol called AJP (Apache Java Protocol), which represents essentially a pre-parsed HTTP requests. This module, as well as the AJP protocol itself has gone through severel revisions, from mod_jk, to mod_jk2. I cannot quite recall, but I think some version of mod_jk might have lost the ability to run in-process. Every other version, including the most current, can, if I recall correctly. This is besides the point, because as far as I know, AJP always has been a trivial performance overhead (I believe recent versions can run over Unix domain sockets). In fact, Apache is routinely used in production as the front-end web server, instead of the built-in servlet engine web server, simply because it is faster at serving static content, and that the AJP protocol is negligable. If the "stub" referred to in the quote is not the AJP module, then this may not be relevant, nevertheless AJP has always been highly efficient and typically negligable with regard to performance (the same typical connection min/max/idle count configurations apply as do to Apache itself).

The article goes on to proclaim the complexities of caching and data object persistence which we have eliminated from our comparision. Let's move on to the real bottleneck - the database. The article says "PHP's connectivity to the database consists of either a thin layer on top of the C data access functions, or a database abstraction layer called PEAR::DB. There is nothing to suggest tha

I will start with mandatory links to the great series of articles that Ace's Hardware ran, describing their server scenario and their migration from PHP to Java/J2EE:

1. Building a Better Webserver
2. Building a Better Webserver in the 21st Century
3. Scaling Server Performance

The PHP Scalability Myth starts of by defining three types of server architectures. The first, two-tier, and the last, logical-three-tier, are the same conceptually (there is the slight distinction between whether display and business logic code is "mingled", but this is typically not a performance issue, but just an aesthetic or design issue). This two-tier/logical-three-tier architecture is the only one PHP supports natively. The article then proceeds to compare a two-tier PHP architecture against the most elaborate full three-tier Java architecture, which is used rarely in practice, and extremely rarely in the same domain in which a PHP solution is feasible. Instead of comparing apples and oranges (if PHP supported a full three-tier architecture, I would imagine two-tier PHP vs. three-tier PHP would have the same performance discrepencies), let's simply compare the only architecture PHP supports natively, two-tier, against JSP talking directly to a database, as this scenario is the most analogous to the PHP one. Let's also discard any caching as again this is something that Java handily accomodates but is not natively (or at least easily) available in PHP due to lack of state. And let's assume the database is the largest bottleneck.

The article states:

At the time when the first versions of the JSP and EJB standards were released, the prevalent web server was (and still is) Apache 1.x, which had a process model that was not compatible with Java's threading model. This meant that a small stub was required on the web server side to communicate with the servlet engine. The remains a non-trivial performance overhead for those that decide to pay it, and was a significant performance overhead when the first scalability comparisons were made.

I'm not sure what "stub" the article is referring to, but I will assume it means an Apache module which talks a "native" protocol to the servlet engine. The first such module was mod_jserv, which could run the servlet engine both in-process and over a compact protocol called AJP (Apache Java Protocol), which represents essentially a pre-parsed HTTP requests. This module, as well as the AJP protocol itself has gone through severel revisions, from mod_jk, to mod_jk2. I cannot quite recall, but I think some version of mod_jk might have lost the ability to run in-process. Every other version, including the most current, can, if I recall correctly. This is besides the point, because as far as I know, AJP always has been a trivial performance overhead (I believe recent versions can run over Unix domain sockets). In fact, Apache is routinely used in production as the front-end web server, instead of the built-in servlet engine web server, simply because it is faster at serving static content, and that the AJP protocol is negligable. If the "stub" referred to in the quote is not the AJP module, then this may not be relevant, nevertheless AJP has always been highly efficient and typically negligable with regard to performance (the same typical connection min/max/idle count configurations apply as do to Apache itself).

The article goes on to proclaim the complexities of caching and data object persistence which we have eliminated from our comparision. Let's move on to the real bottleneck - the database. The article says "PHP's connectivity to the database consists of either a thin layer on top of the C data access functions, or a database abstraction layer called PEAR::DB. There is nothing to suggest tha

I will start with mandatory links to the great series of articles that Ace's Hardware ran, describing their server scenario and their migration from PHP to Java/J2EE:

1. Building a Better Webserver
2. Building a Better Webserver in the 21st Century
3. Scaling Server Performance

The PHP Scalability Myth starts of by defining three types of server architectures. The first, two-tier, and the last, logical-three-tier, are the same conceptually (there is the slight distinction between whether display and business logic code is "mingled", but this is typically not a performance issue, but just an aesthetic or design issue). This two-tier/logical-three-tier architecture is the only one PHP supports natively. The article then proceeds to compare a two-tier PHP architecture against the most elaborate full three-tier Java architecture, which is used rarely in practice, and extremely rarely in the same domain in which a PHP solution is feasible. Instead of comparing apples and oranges (if PHP supported a full three-tier architecture, I would imagine two-tier PHP vs. three-tier PHP would have the same performance discrepencies), let's simply compare the only architecture PHP supports natively, two-tier, against JSP talking directly to a database, as this scenario is the most analogous to the PHP one. Let's also discard any caching as again this is something that Java handily accomodates but is not natively (or at least easily) available in PHP due to lack of state. And let's assume the database is the largest bottleneck.

The article states:

At the time when the first versions of the JSP and EJB standards were released, the prevalent web server was (and still is) Apache 1.x, which had a process model that was not compatible with Java's threading model. This meant that a small stub was required on the web server side to communicate with the servlet engine. The remains a non-trivial performance overhead for those that decide to pay it, and was a significant performance overhead when the first scalability comparisons were made.

I'm not sure what "stub" the article is referring to, but I will assume it means an Apache module which talks a "native" protocol to the servlet engine. The first such module was mod_jserv, which could run the servlet engine both in-process and over a compact protocol called AJP (Apache Java Protocol), which represents essentially a pre-parsed HTTP requests. This module, as well as the AJP protocol itself has gone through severel revisions, from mod_jk, to mod_jk2. I cannot quite recall, but I think some version of mod_jk might have lost the ability to run in-process. Every other version, including the most current, can, if I recall correctly. This is besides the point, because as far as I know, AJP always has been a trivial performance overhead (I believe recent versions can run over Unix domain sockets). In fact, Apache is routinely used in production as the front-end web server, instead of the built-in servlet engine web server, simply because it is faster at serving static content, and that the AJP protocol is negligable. If the "stub" referred to in the quote is not the AJP module, then this may not be relevant, nevertheless AJP has always been highly efficient and typically negligable with regard to performance (the same typical connection min/max/idle count configurations apply as do to Apache itself).

The article goes on to proclaim the complexities of caching and data object persistence which we have eliminated from our comparision. Let's move on to the real bottleneck - the database. The article says "PHP's connectivity to the database consists of either a thin layer on top of the C data access functions, or a database abstraction layer called PEAR::DB. There is nothing to suggest tha

Are you really so stupid that you're going to link to a bunch of discredited microbenchmarks that use different algorithms for implementation, as well as superfluous and broken techniques for writing C and C++?

Pardon me, but didn't someone state that C/C++ was inherently *faster* than Java? Can it be? Is it possible that you can write bad code IN ANY LANGUAGE? Does that even mean that you can write good code IN ANY LANGUAGE?! The HORROR!!!

On a more serious note Mr. Troll, welcome to the wild and wooly world of Benchmarks. There is simply no way of giving an "accurate" measurment of language performance since either side can always argue that something was done incorrectly. However, there is one thing we can glean from these benchmarks (in a very general sense): Java and C are evenly matched competitors. Sometimes C will appear a bit faster, sometimes Java. So use what gets the job done right.

Some more benchmarks for you:

OS News
Older Benchmark on Ace's Hardware


Now, most of these benchmarks have been mentioned on Slashdot at one time or another. To date, I have not seen a *single* benchmark that displays results different to those in the above benchmarks. As I troll, I release you'd never want to reveal your secret identity (*snigger*), but perhaps you'd like to be the first to bring forward a viable benchmark showing the MASSIVE (i.e. non-existant) performance difference between Java and C? Or perhaps you'd like to continue this and get yourself pummeled that much harder?

Considering the fact that Athlon 64 FXs running at 2 to 2.4GHz beat the crap out of various P4 and P4EE with up to 3.4GHz, I can't really take your clockrate argument seriously. Ok, the P4 scored better on some closed-source renderers, but then consider that most applications in the benchmarks have not even been optimized for 64 bit yet!

I understand your reasoning, but according to this article (I found the link on Ace's Hardware) the dual core chips will be compatible with current motherboards and sockets with as little as a BIOS flash (to recognise the new CPUID I assume). The downside of this is that the two cores will SHARE the dual channel memory bus. But because the bus is so effiencent, each core will probably STILL get more bandwidth than most P4s. At worst it shouldn't be much worse than having two single channel Athlon64s (which also are often faster than the P4). I think this is FANTASTIC news. For one thing, this means you could put FOUR CORES in that dual opteron SFF PC that was revealed a short while ago.

Really, it only makes sense. A dual channel processor has 939 pins, a single channel has 754 pins. So while some are power, you're looking at about 190 pins for the second memory channel. So that would mean that to have two cores on one die with their own memory channels, you'd need 1120 pins or so. That's a LOT of pins.

Instead of that enginering nightmare (you'd probably need 7 layer mobos to support that), we get drop in replacements that meet the same thermal requirements. Just think. You're dual operton not cutting the mustard any more? Buy two processors, drop 'em in, flash the BIOS, and now you've got FOUR processors without a new mobo or anything. All you'd have to worry about then is software licenses (unless of course you don't use any software that requirs that, for example you're all open source).

So to answer the grandparent's question, I'd say buy now. That said, I'm not sure if socket 939 will get dual cores or if it's only for 940s. I assume 939 will get them too.

Speculation: I'd like to know if the dual channel memory controler is shared by the two cores (like some kind of cross-bar architecture thing like nVidia used to promote) or if each core got exclusive access to one of the two channels. My guess is the former.

More speculation: Will there be a socket 754 dual core? That'd be cool, and I don't think the performance would be too much of a problem memory wise, unless you were doing memory intensive tasks. For CPU bound tasks I think you'd be fine.

AcesHardware found that disabling the 2T memory timing in the BIOS improved S939 performence by over 10%. The only limitation with this is one DIMM per memory channel.

A lot of reviews you read today will not be using this, and the results will therefore be significantly lower than what is possible.

Here are some more review links for those who are interested:
Tom's Hardware
Bit-Tech
Driver Heaven
AMD Zone
Hard Tecs 4U
PC Perspective
Ace's Hardware
Sudhian

FYI, the server is using a single 500MHz UltraSparc IIe CPU...

1) Memory latency will be a bigger and bigger bottleneck in systems as cpu frequencies scale

2) Technology will not allow memory latency to keep pace with cpu frequency.

See ace's previous interview

A snippet:

Chris Rijk [Ace's Hardware]: Stalled on waiting for data, basically.

Dr. Marc Tremblay: Yes. In large multiprocessor servers, waiting for data can easily take 500 cycles, especially in multi-GHz processors. So there are two strategies to be able to tolerate this latency or be able to do useful work. One of them is switching threads, so go to another thread and try to do useful work, and when that thread stalls and waits for memory then switch to another thread and so on. So that's kind of the traditional vertical multithreading approach. The other approach is if you truly want to speed up that one thread and want to achieve high single thread performance, well what we do is that we actually, under the hood, launch a hardware thread that while the processor is stalled and therefore not doing any useful work, that hardware thread keeps going down the code as fast as it can and tries to prefetch along the program path. Along the predicted execution path [it] will prefetch all the interesting data and by going along the predicted path [it] will prefetch all the interesting instructions as well.

Anyone know this machine with the 1.25 GHz G4 processor fares against the new Intel 3.2Ghz processor with 1Gb RAM?

The 1.25Ghz G4 fares extremely well - It costs a lot less!

While the P4 3.2 costs between $300 and $400 just fo rthe chip, this $800 unit includes the 1.25 G4, Combo drive, 40GB hd, 256K Ram, CRT built in custom housing, video, networking, USB 2, Firewire800, Airport Extreme upgrade path, Bluetooth upgrade path, OS X Jaguar, iLife (Garageband, iMovie, iDVD, iPhoto, iTunes) and the cache of owning an Apple.

You can check out this review of the 1.25 Ghz G4 when it first came out and this review of the P4 3.2Ghz vs. an Athlon

Simple answer is that an SMP opteron ('cos only 940 pin opterons work in SMP) would kick ass because they don't share memory bandwidth between processors. In fact available memory size and bandwidth scales linearly as you add processors and all available benchmarks show that overall performance scales at least twice as fast on Opteron systems as Xeon systems.

For a great aticle comparing SMP systems check out this article at Ace's Harware. I know that its not a BSD based comparison, but it should give you some idea.

Can you provide a reference to back this up?

http://www.aceshardware.com/read_news.jsp?id=80000 460

There's always a chance that this is wrong, but this is just to prove that I didn't pull it out of midair ;)

1) If you are doing anything in Lightwave by all means don't use AMD's XP :) There must be some major tweak they are missing.

It's called SSE2. Lightwave uses it, the AthlonXP doesn't support it. The chip also has the lowest memory bandwidth of any of these chips.

As for the scale thing, you're right. A lot of the processor performance they're seeing just doesn't matter much for todays applications. One could argue that they might help out for future applications that strain the processor a bit more, but it seems a bit pointless to spend a lot of money today on a CPU for software that might appear a year from now when a much faster CPU will be dirt-cheap.

4) With all of the tests there wasn't one compiler test :(

I'm sure that one of the multitude of other reviews out there did a compiler test or two. If all else fails, there is always SPEC CPU2000. One of the CINT sub-benches tests compiling performance with GCC. You have to do a bit of sorting by sub-test, but Ace's hardware have a nifty SPECmine tool that can help you in this regard.

actually, we might see FMB 1.5 compatible chips (which newer S478 boards like the Abit IC7-Max3 should support), up to 3.8ghz by the end of the year.
Older 865 and 875 boards will only support chips for FMB 1.0 (limited to 3.2ghz).
Ace's Hardware has a nice layout.

Here are some more benchmarks

AMDzone

AnandTech

XbitLabs

Ace Hardware

There are even more at AMDZones main page.

I'd have to say Ace's Hardware, since they seem to do the most thorough testing and have the best understanding of what's going on. They don't review much but the forum is at least decent.

The RPC and DCOM changes are much more likely to have wider impacts - especially for enterprise applications.

The ICF changes are fairly light (unfortunately in my view) and not that hard for end users\admins to modify so even if there are issues workarounds will be fairly simple.

The RPC and DCOM changes are much more likely to have wider impacts - especially for enterprise applications.

The ICF changes are fairly light (unfortunately in my view) and not that hard for end users\admins to modify so even if there are issues workarounds will be fairly simple.

You do seem to be correct that companies don't want to emphasize NUMA too much from the software side of things. AMD has also been known to say that their Opterons don't need any NUMA optimizations.

They actually used the term "SUMO" (complete with a drawing of a sumo wrestler in one of their presentations! :) ), for Sufficiently Uniform Memory Organization.

Regardless of what the marketing depertment says and to who, it's still NUMA. A test on Ace's Hardware a while back showed that a 2P Opteron can see up to a 20% faster with NUMA optimizations, and presumably a 4P Opteron will see an even bigger boost.

I would guess that Anand's test linked in this article had those NUMA optimizations enabled already, though he doesn't specify any BIOS options. He did use Win2K3 which is NUMA aware.

"People bash the x86 architecture and at the same time, bash anything that isn't x86."

Well, I think that people look at the x86 architecture, and they can see the many, many horrible hacks that have been used to sustain it. That much is pretty obvious if you spend even 10 minutes looking over things. You sit there scratching your head and going, "What the hell? Why'd they do that?", and then realize it's because something, somewhere, was broken until they did it. The reason people don't like to start looking into replacement architectures is exactly as you expressed; the must-have software. You can try running that software under emulation, but the best architecture in the world is always going to take a performance nosedive when running code under emulation. I can look at what IBM has been doing, or even at what Intel was doing with EPIC back in the day, and I can say, "wow, that's pretty cool". But what I can't do is put down the x86, toss all the old software, and hope that all the new software, written for a completely new architecture, is going to work in some sort of reliable fashion. What you really get with x86 is 20 years of experience, and thus, a measure of predictability. In essence, you're paying for predictable problems (much better than unpredictable ones) with old, poor architecture.

"The AMD solution doesn't do away with x86"

AMD64 actually does get rid of a lot of garbage in x86 that is no longer in use. Take a look at the presentation (link at Ace's) by the guy who designed AMD64. He was actually pretty thrilled (well, as thrilled as this guy gets) about being able to dump a lot of the cruft x86 has accumulated. Unfortunately, many things had to remain intact, for the obvious reason of compatibility. I have to warn you though, the guy from the AMD presentation is a real ball of fire. (Although, the ex-Intel guy from the other presenation was pretty interesting and funny)

Are you serious? Tom? Is that you?

Here:

"There is nothing finer than raising the hackles of delusional AMD lovers. However, today I do so with a heavy heart. This is no time to take aim at the pompous, self-righteous head-in-the-sand-ostriches of the alternative chip lifestyle. One must embrace them, hug them and wipe away their tears.

They are the freaks of low-cost computing, the poor, downtrodden users of products that never seem to be able to match PR numbers to actual performance, now almost beaten into marginality for all time. "
(Ridiculous remarks curteousy of Omid, General Manager, U.S. Operations for Tom's Hardware)

You need some serious psychological help if you're crazy enough to believe that they're actually pro-AMD. They're not just pro-Intel, they're pro-$ADVERTISER. Generally speaking, their articles are skewed towards a select few especially heavy advertisers. They'll even work with different driver revisions and bios settings to maximize the advantage for Intel et al. There was even an article in which Tom himself admitted that he sent the results 'back to the labs for more testing' after the AMD chips performed a bit too well for his tastes. He didn't say why he sent the results back, but when you look at the articles surrounding it and see 9 articles with a pro-Intel slant, 1 with benchmarks that seem favorable for AMD, and the 1 gets the results sent back for 'further testing', you get a good indication of what's happening. Tell me this: why is it that Tom's benchmarks tell such a different story from virtually every other hardware sites'? Is it some massive AMD conspiracy? Why is it that Ace's says one thing, and Tom's says something totally different? (Ace's is a technical-minded person's hangout, as opposed to the consumer-oriented Tom's)

Wake up - Tom's is a propaganda machine serving up dumbed-down consumer grade articles with rigged benchmarks and non-sequitur conclusions.

It's a joke, and quite frankly, it's becoming pathetic.

"I have lost respect for Tom and his publication."

I've never had much respect for Tom; he's an egomaniac. Also, the website sold out to Intel and a number of other advertisers a few years ago (roughly 3). You'll notice a fairly rapid change in the articles if you look in the archives - that is, if you can find articles that haven't been re-edited or removed. They also have a habit of removing the author title or changing it when they decide they don't like the original author anymore.

Tom's is now a joke. It's a site offering dumbed-down consumer grade articles with rigged benchmarks and conclusions that are non-sequitur. Attempts to hide the utter bias have faded with time, with AMD supporters now being openly labled as just a bunch of idiotic, delusional fanboys by some in the staff (Hi Omid!). The benchmarks are done with multiple driver versions, then vetted such that the best possible results for key advertisers can be shown. Anandtech still has a good deal of respect in the community, as well as from me (I'm more important! ;) ). Probably the best site I've run across is Ace's, which offers incredibly in-depth articles to those willing to learn a thing or two.

Here's an excerpt from a recent column on Tom's:

"There is nothing finer than raising the hackles of delusional AMD lovers. However, today I do so with a heavy heart. This is no time to take aim at the pompous, self-righteous head-in-the-sand-ostriches of the alternative chip lifestyle. One must embrace them, hug them and wipe away their tears.

They are the freaks of low-cost computing, the poor, downtrodden users of products that never seem to be able to match PR numbers to actual performance, now almost beaten into marginality for all time.

Of course, they won't admit this. They will howl at the moon, scream obscenities at nice, unassuming columnists with no axe to grind"

An article at aces's hardware has managed to pick up some information about ZFS (the zettabyte file system). If it's really as good as it promises (as other rumours indicate), then ZFS+NFSv4 will be an amazing combination.

N1 Grid Containers is a breakthrough approach to virtualization with multiple software partitions per single instance of the OS. N1 Grid Containers make consolidation simple, safe and secure.

* Superior Resource Utilization. N1 Grid Containers dynamically adjust resources to business goals within and across the container. With little management overhead (less than 1%), it offers over 4,000 containers per system.
* Increased Uptime. With N1 Grid Containers, applications are isolated from each other and from system faults. Using Instant Restart, each Container can be restarted in just seconds. Boot time in large systems can be reduced by as much as 70%.
* Reduced Costs. N1 Grid Containers simplifies and accelerates consolidation. It also significantly reduces system, admin and maintenance overhead.

So you want to move hundreds of millions of customers to a new CPU design that's elegeant and does away with all the x86 junk.

How do you get around the chicken and the egg problem where there's no software developing as there's no customers, and no customers interested because there's no software?

Here's how: You start in a market that can afford to spend lots of money on developing their own software. The only way to enter in this market is to make your CPU run these customers' programs the fastest. Eventually you'll get enough software support to move this CPU down and sell to the medium and eventually the low end servers, but it'll take a few years. In this range, OS's will be building the capability to emulate x86 with little or no performance hit, and programs will be migrating to run natively in the new format. A few more years and many native apps later, you'll get high-end desktops/workstations migrating. Finally, the flood of average consumers will start rolling in.

How long will this process take? Let's look at the closest example of switching consumers to something that wasn't backwards compatible: DOS/Win3.1 to Windows NT. WinXP was the first "NT" version marketed to, and accepted by the average consumer. NT 3.1 was first released to the public in October '93. We have a full ten years to make the migration.

So you really shouldn't be comparing these processors just because their bits are the same. They're all 64 because very soon now 4 gigs of memory will no longer be enough for the desktop. The real comparison is x86 vs IA64 and the big question is whether IA64 really has what it takes to beat out x86 a few generations down the road.

The Itanium is still a kid, and it has a lot of battles ahead of itself before it's a consumer CPU, but IMO it has passed its first tests. I hated NT once also, but I've learned my lesson now.

The other big news today was AMD's announcement of the HE and EE (wtf they mean is anyone's guess) of low-power Opterons. With these lines you get a full-scale Opteron that only puts out 35 or 50 watts! True they're expensive as heck, but they seem perfect for blades and other large-scale installations where power and AC requirements cost more than the CPUs themselves.

More information: AMD, Intel at xbit
Discussion: AMD, Intel at Ace's

The other big news today was AMD's announcement of the HE and EE (wtf they mean is anyone's guess) of low-power Opterons. With these lines you get a full-scale Opteron that only puts out 35 or 50 watts! True they're expensive as heck, but they seem perfect for blades and other large-scale installations where power and AC requirements cost more than the CPUs themselves.

More information: AMD, Intel at xbit
Discussion: AMD, Intel at Ace's

"I still go there for the forums, as there are a few people there who have good insight."

I think you'd enjoy the forums at Ace's a lot more. The folks tend to be more intelligent, less 'fanboyish', and come out with insights you won't find anywhere else.

Go their benchmarks aslo show a marked improvement for Linux on 64bit.

Some tests scored about as much as a 20% improvement in performance, athough it's more realistic to expect a 8-10% average improvement across the board.

Of course windows likely will run slower since it's so optimized for the older 32bit platform.

Linux is just a much more mature platform for 64bit computers. I mean we've had Suse 64bit (aviable for free from Suse's ftp install stuff) for almost a year now.

Maybe you should try a good hardware site sometime. One that doesn't update quite as much but has more thought in the articles than "Wow it's 4fps faster in quake3!", with a forum full of people who know what they're talking about. If you avoid sites that review every minor cpu and video card speed bump under the sun, you'll probably find more quality content that actually means something to someone who can already figure out that x+y mhz > x mhz for a product that was exactly the same 2 months ago.

"Basically, looks like it's faster, but still not the fastest in all areas."

Just what definition are you using for the word "faster"? To my eyes, it's slower than the older Northwood core in the majority of real-world situations, clock-for-clock. If you're talking about absolute performance, then it's significantly slower than, say, the AthlonFX CPUs. Even the biased-as-hell airbags at Tom's didn't have much good to say about this CPU. That's not to say that it wont see strong performance gains as applications are recompiled to support the new features (SSE3 et al) of Prescott, but I don't have the slightest idea where from where your statment comes based upon the reviews and benchmarks published thus far.

You make it sound like it's a superb new chip that outperforms almost every other chip on almost every application. That's criminally wrong.

Tech-Report Prescott Review
accelenation Prescott Review
Ace's Hardware Prescott Review
Gamers Depot Prescott Review
HardTecs4U
Hexus
K-Hardware Prescott Review,
Legit Reviews Prescott Review
LostCircuits
MBReview Prescott Review
VR-Zone
X-bit labs Prescott Review
XtremeSystems Prescott Review
Extreme-tech Prescott Review

Some data: FP

Int

Some data: FP

Int

Hi -- I don't want to argue Microsoft's side too strenuously, but most of your counter-points are pretty shallow.

Windows XP Pro is $300 compared to Redhat at $180 is still a cost savings
Redhat ELWS is $180 Per Year, versus $300 (retail, which nobody pays) for XPPro for a 5 year support window. Not hard to figure out which is cheaper.

They may cost more per admin but it takes less to do the same job.
And that's the fun of doing TCO studies! Microsoft's numbers disagree with you, so a PHB is going to want to see a TCO study proving your assertation.

What I've noticed in places that I've worked is that the Windows and Unix people are doing very different things in different ways, so it's difficult to make an Apples to Apples comparison. Check out this article -- it that argues a cheaper Unix network "removes the user empowerment" Windows networks have. Which basically means the Unix Admin can do more because the users can do less.

in independent tests [Samba]was reported to be 2.5 times faster
Last thing people are worried about is speed. It's really the management tools.

"even with optimized code, clock-for-clock, the P3 is still faster"

This may not be true in specific applications that support both SSE-2 and hyperthreading. Though I don't have a spcific head-to-head matchup, one particular program I might expect to see higher clock-for-clock performance on the P4 than the P3 is Cinebench 2003.

This merely shows that under absolutely perfect circumstances, the P4 can perform well. What it also shows is that the P4 requires those perfect conditions to go much of anywhere.

You also forgot to mention that there was no "086". :)

P4 Willamette and Northwood have a 20 stage pipeline when seen from the trace cache. However, including the decode path which stores its results in the trace cache, the pipeline is 28 stages.

For those into the technical side of this type of stuff and heck of a lot higher S/N ration, check out the Ace's Hardware forum. There's a large thread going on overthere taking about the rumors and what it would actually mean.

For those into the technical side of this type of stuff and heck of a lot higher S/N ration, check out the Ace's Hardware forum. There's a large thread going on overthere taking about the rumors and what it would actually mean.

For those into the technical side of this type of stuff and heck of a lot higher S/N ration, check out the Ace's Hardware forum. There's a large thread going on overthere taking about the rumors and what it would actually mean.

--Wow, I can't believe this got modded as 'Insightful'. 3000+ is a performance rating that is designed to show the CPU performs equivalently to a P4-3Ghz.

If you look at some actual benchmarks, you will see that the P4 3.06 is actually better in some cases than an AthlonXP3000+ (note this is the 2.167Ghz Barton in the graph)

SpecFP
SpecInt

Additionally, the data shows that a 3Ghz P4 is in fact MORE than 3x faster at SpecFP than a 1Ghz P3. Perhaps you should inform yourself a little before posting FUD.

--Wow, I can't believe this got modded as 'Insightful'. 3000+ is a performance rating that is designed to show the CPU performs equivalently to a P4-3Ghz.

If you look at some actual benchmarks, you will see that the P4 3.06 is actually better in some cases than an AthlonXP3000+ (note this is the 2.167Ghz Barton in the graph)

SpecFP
SpecInt

Additionally, the data shows that a 3Ghz P4 is in fact MORE than 3x faster at SpecFP than a 1Ghz P3. Perhaps you should inform yourself a little before posting FUD.

Good job, Slashdot... This has only been covered at the Inquirer and Ace's for a couple of months. Some relevant articles can be had at Ace's here, there, and over yonder.

Look to the discussion forums for further analysis by competent folks.

Warning: Only hit the links if you're intelligent. The average mind need not apply.

Good job, Slashdot... This has only been covered at the Inquirer and Ace's for a couple of months. Some relevant articles can be had at Ace's here, there, and over yonder.

Look to the discussion forums for further analysis by competent folks.

Warning: Only hit the links if you're intelligent. The average mind need not apply.

Good job, Slashdot... This has only been covered at the Inquirer and Ace's for a couple of months. Some relevant articles can be had at Ace's here, there, and over yonder.

Look to the discussion forums for further analysis by competent folks.

Warning: Only hit the links if you're intelligent. The average mind need not apply.

Good job, Slashdot... This has only been covered at the Inquirer and Ace's for a couple of months. Some relevant articles can be had at Ace's here, there, and over yonder.

Look to the discussion forums for further analysis by competent folks.

Warning: Only hit the links if you're intelligent. The average mind need not apply.

You're way off, on several accounts. It's always fun to try and blame everything on corporate greed, but sometimes the facts just don't support it. Other posters have pointed out how Sun plans to use similar technology and how IBM plans to implement it. Do you think that they are just copying Intel blindly? They are all attacking the same problem: increasing throughput for fast CPUs. As you yourself pointed out, memory speed cannot come close to keeping up with modern CPUs. Increasing cache size is one way to combat this, but it is a very brute force way to do it. You increase the size, cost, and power consumption of the CPU when doing this. SMT and multi-core SMP systems allow for work to get done while waiting for memory to catch up. HT is just the tip of the iceberg, the stuff that Sun and IBM are working on is pretty amazing.

As for your knowledge of Intel, it is humorous at best. The Itanium was never meant to be the CPU of the future. It was never meant to be in home systems. It was designed to give Intel a way to compete with 64-bit servers that were all the rage in the late 90's. That's why Intel was willing to completely break with x86 instruction sets. If they were planning on trying to transition from PentiumXYZ to Itanium, then they would have never done that. Plus, for all its initial problems, the modern Itanium has put up some impressive numbers.

Have you tried Ace's HardwareThey have a server guide comparing Dual Xeons and Opterons along with a Quad Opteron system. You can also cross reference with their workstation tests for some dual Athlon MP tests.

I know they used Linux in their server guide review, but I'm foggy on their older reviews since I haven't read those for quite some time.

If you refer back to Marc Tremblay's CMT Article, you'll see that one of the approaches is to run one thread until it blocks on a memory read, then run another until it blocks and so on, repeating for as many threads as it takes to soak up all the wasted time waiting for the memory fetches.

The Sun paper on their plans for it is here. Have a look at page 5 for the diagram.

--dave (biased, you understand) c-b