Today's Best CPUs Compared... To a Pentium 4

Dr. Damage writes "How do current $74 CPUs compare to the $133 ones? To exclusive $1K Extreme Editions? Interesting questions, but what if you took a five-year-old Pentium 4 at 3.8GHz and pitted it against today's CPUs in a slew of games and other applications? The results are eye-opening." Note that this voluminous comparison is presented over 18 pages with no single-page view in sight.

Comments

P4 pride

[dushkin]

I'm at work, where I have a P4 winXP machine.

AND I'M PROUD OF IT.

Re:P4 pride

[MrNaz]

I bought 5 surplus P4 machines with 512mb ram and 40gb HDDs for my community center's library. They have *CRT* monitors. Beat that!

Re:P4 pride

[Shadow of Eternity]

My gaming setup used to be two computers (pentium4 and a q9450) both hooked up to dual-input FW9012 and P260 trinitron CRTs. That was two computers both running at 3500x1200 and putting a combined weight of about 300lbs on my desk.

We almost didn't need to heat the apartment in winter.

Re:P4 pride

[silent_artichoke]

(Obviously she doesn't access the Internet)

Reading that made my arms itch like a junkie without a fix.

Re:P4 pride

[tomhudson]

Why "obviously"? Win3.1 + chameleon netsock worked fine for connecting to the net on any 386 with 2 megs of ram, (though it worked better with 4 or 8 megs).

Games don't use multiple cores?

[damburger]

From the article:

For about the same price as the Core i3-530, the Athlon II X4 635 offers four cores that perform better in applications that rely heavily on multiple threads, such as video encoding, 3D rendering, and Folding@Home. In other uses, such as video games and image processing, these two CPUs perform almost identically. The Athlon II X4 635 leads slightly in overall performance and, as we established on the previous page, in terms of performance value. If that's all you care about when choosing a processor, then your decision has been made.

How can game engines not take advantage of multiple cores? I had no idea this was the case, and find it very surprising given that the PS3 has 7 cores to work with. Are games so lazily programmed that they don't take advantage of that either?

Re:Games don't use multiple cores?

[zaibazu]

The so called 7 Cores are pretty specialized sub units. With the lack of good middleware and development kits at the PS3 release, the platform is just now after years starting to get somewhat used

Re:Games don't use multiple cores?

[Rhaban]

advantages of multiple cores are not so evident when dealing with real-time physics/rendering/etc.
If all your processes must communicate with each other constantly, you lose the benefits of having each process processed by a different core.

Re:Games don't use multiple cores?

[h00manist]

Are games so lazily programmed that they don't take advantage of that either?

Obviously it's not exactly easy to make programs that can run either on multiple cpu's or a single one just as well.

Re:Games don't use multiple cores?

[SharpFang]

Goddamnit Dwarf Fortress. It could really, really use multiple cores to handle physics. A good enemy flooding system based on a dam and an artificial lake will hog the fastest CPU.

Re:Games don't use multiple cores?

[dwater]

OpenGL Performer managed to enable applications to run on different platforms, from single CPU, single GPU, all the way up to hundreds of CPUs and upto (IIRC) 16 GPUs, without any changes.

OK, so the developers of OpenGL Performer were clever and motivated, but it certainly proves that it isn't a technical limitation and (IMO) invalidates your assertion that they "have to go for some version of the lowest common denominator".

http://en.wikipedia.org/wiki/OpenGL_Performer

Re:Games don't use multiple cores?

[Verunks]

How can game engines not take advantage of multiple cores? I had no idea this was the case, and find it very surprising given that the PS3 has 7 cores to work with. Are games so lazily programmed that they don't take advantage of that either?

this was the case a couple of years ago, nowadays all major games(dragon age, mass effect 2, battlefield bad company 2, etc..) uses my dual core at 100%

the frostbite engine(used in bfbc2 and bf1943) is even designed to use up to 16 threads http://repi.blogspot.com/2009/11/parallel-futures-of-game-engine.html

Re:Games don't use multiple cores?

[Dunbal]

Because not everyone has multiple cores so PC games have to go for some version of the lowest common denominator

      Which is honestly quite strange, because most games I know require you have the latest uber-$500 graphics card to run properly. I would argue that there is something else involved (eye candy important, multi-core not) in the design process.

Re:Games don't use multiple cores?

[TheThiefMaster]

Speaking as a PS3 dev, the SPUs are very different to program for than a normal multi-core cpu (and you only get to use five and a half of them anyway, not 7).

On the flip side, everything based on UE3 (which is most big cpu-hungry multi-platform titles these days) is multithreaded to two or three significant threads: Game, rendering, and possibly physics (depending on physics engine used). None of them are SPU threads (though they may use the SPUs for some tasks), so PS3 performance isn't generally as good as the 360's, but in most games it's a non-issue as both platforms go over the 30 fps cap.

On PC, most UE3 games will run best on two cores, with anything above that being unnecessary.

Re:Games don't use multiple cores?

[Anonymous Coward]

Yeah, you're right, it's all really about having multiple threads in your soft. All these deadlocks, stravations and races blahs are just there to frighten kiddies!

Re:Games don't use multiple cores?

[hvm2hvm]

Physics is very friendly to multithreading since most computations are done in parallel anyway. N objects interacting with each other would be simulated in a series of steps, and for each step you need to calculate the next attributes taking into account the previous ones of all the objects. Then, you would save this instance and start again. During each step, threads can more or less operate independent to each other.

A very good example of this would be NVidia PhysX.

Re:Games don't use multiple cores?

[aaaaaaargh!]

The main reasons:

• Many problems cannot be parallelized at all. If a problem is sequential in nature, multiple cores cannot solve it faster.
• Even when a task can be parallelized, this is at times complicated. Many developers lack the skills to implement or even invent efficient parallel algorithms. It's not just about spawing a few additional threads, there are usually complicated interprocess communication problems involved.
• Since mainstream machines currently may contain everything from 1 to 8 cores (including the virtual ones created by hyperthreading), developing for n cores is always going to involve tradeoffs. The program should still run well on a single core machine.
• Many game engines in use by studios are not yet updated to take full advantage of multiple cores and it is completely non-trivial or too expensive to change them accordingly.

Re:Games don't use multiple cores?

[MrNemesis]

As noted, the PS3 is more of a single core PPC processor plus 6 SSE-on-steroids units. Whilst it's true that parallelism needs to be incorporated into the engine design, the tasks you'd farm out to the SPE's or whatever they're called are very different from what you'd ask core3 to do on your x86 processor.

The CPU in the 360, however, is a genuine triple-core PPC processor.

Re:Games don't use multiple cores?

[dwater]

> Jeez, the pedants are out in force today...

Well, if you're wrong, you're wrong. Don't blame us since the bit you got wrong is pivotal to the discussion.

> Let me try again: SGI always had multi CPU machines available for running Performer

Well, I'm sure they[1] did since they made the things. Customers, on the other hand, did not. Heck, there were several games for SGI that ran on single CPU systems just fine.

> PC games not using multiple CPUs is completely separate from SGI machines running Performer

Well, again, that's irrelevant. My point is that, if SGI can do it, then "PC games" can too - ie there's no necessity to always code for the lowest common denomitor.

[1] I say 'they', when I should say 'we' - I worked there and my specialty was Onyx2 and OpenGL Performer and I used it mostly on single CPU systems since otherwise I would have to go into a lab.

Re:Games don't use multiple cores?

[Brian Feldman]

Because not everyone has multiple cores so PC games have to go for some version of the lowest common denominator

      Which is honestly quite strange, because most games I know require you have the latest uber-$500 graphics card to run properly. I would argue that there is something else involved (eye candy important, multi-core not) in the design process.

You need your hyperbole license revoked until you can use some semblance of realism. BioShock 2 literally came out less than a week ago and it runs at a full 60fps at 1920x1080, all graphics settings at their highest, on a Radeon 4870 -- a $200 graphics card when I got it a YEAR ago.

Re:Games don't use multiple cores?

[Quantumstate]

I would guess a fairly big factor is because generally the game logic which runs of the processor doesn't degrade well. With graphics you can lower resolutions, change texture sizes and add additional lighting effects which are optional so the game just looks a bit worse but plays the same. Trying to do the same with game logic is much harder, maybe some adaptive AI could be made to play better on faster hardware plus some extra graphical effects probably need some extra processor time but these changes would be much less.

Then the developers want the game to be playable on as many machines as is feasible so they head for as low a target as possible which is a single threaded machine. Making it work on multiple cores then turns into a pretty difficult task for very little gain because of the above.

Re:Games don't use multiple cores?

[jittles]

I work on flight simulators and we DEPEND on multiple core processors to get everything done at once. What used to take multiple racks of computers can now be done on a single computer with dual quad-core CPUs.

You think IPC is slow on a single machine? Try using reflective memory across multiple computers. Of course we have to handle a bit more than your typical video game since we have to handle hundreds of buttons and switches from multiple crew member stations, night vision, FLIR and day TV cameras, as well as out the window displays.

Re:Games don't use multiple cores?

[Mashdar]

+1. Rhaban, physics/graphics is one of the MOST parallelizable operations we have. The "shared dataset" is the previous solved set, and no communication is needed so long as the previous set is in shared memory of some sort. The new data should be deterministically determined by the previous set. Graphics processors use this in a non-core-based system where specialized hardware modifies the data set in a pre-determined way massively in parallel.

Re:Games don't use multiple cores?

[MikeBabcock]

That's hardly insightful being completely wrong. Physics is one of those tasks that lends itself very well to multi-threading actually.

Its just a completely different way of designing software. Its very hard to find good programmers. Its even harder to find good programmers who are skilled in threaded software design. Just guess how hard it is to find the ones who can debug it :-).

Re:Games don't use multiple cores?

[Lord Ender]

Left 4 Dead and Team Fortress 2 both have options to use multiple cores. I believe that, when enabled, the other cores to "physics processing." My understanding is that "physics processing" is geek-speak for "making the bodies of your slain foes collapse into realistic piles of death as they hit the ground."

Re:Games don't use multiple cores?

[bluefoxlucid]

People always say this, but I don't understand the difference between multi-threaded and single-threaded programming. In multi-threaded programming, I have to lock around non-lockless data structures and make sure my code is logically able to complete without waiting for any other code that's holding the same lock. Beyond that, it makes more sense when I have multiple shit going on at once; there's no juggling, I just write my physics engine to track exactly one moving object with the environment and I'm good. Wind? Wind is a force that finds objects in its way and applies a force to them, which in turn causes another thread (controlling their movement) to process different data than with no wind. Lighting is the same way, as is player input (this one's way easy).

The hard part is WRITING A GIANT GAME. It's hard. Writing individual small programs is easy.

Re:Games don't use multiple cores?

[Bakkster]

Multicore programming isn't really that hard due to the fact your OS is suppose to handle what thread goes onto which core for you.

I can tell you've never written a multi-core program before...

All you really need to do is to split a single thread game into 4 threads. And no, you are not running more overhead. Who told you that? Your OS doesn't simply run every task in the same thread.

The overhead comes from keeping track of 4 separate threads. Between processor scheduling, task switching, memory/cache thrashing, and message passing alone, a 4-thread sequential program will never run faster than an equivalent single-thread program on a single core.

The only possible benefit is to allow the program to split out tasks with a long wait (such as reading from HDD/optical drive) from those that can be done while waiting, but this gains the exact same speed advantage on a single- or multi-core processor.

The real problem with multi threaded game is syncing. Let's say if you break your game into graphics engine, audio engine, i/o handler, and resource fetcher. Of course resource fetcher has to be the parent thread that spawns everything else as siblings since resource access has to be shared. The real problem is when an event is triggered. not all threads will respond to it immediately due to the fact they are all at different stages of execution. So you end up having to write interrupts for each and every thread.

Again, you've definitely never written a multi-core program. Synchronization is simple compared to the real issues. What are those? Deadlock and Race Conditions. Most developers not being capable of handling these issues (particularly on such large programs) is the reason we don't see more multi-thread programs.

Conclusion

[houghi]

http://techreport.com/articles.x/18448/18 is the page with the conclusion

Re:Conclusion

[Jazzbunny]

Just install AutoPager and you get the article in one long page. You find performance per dollar at page 17 and other interesting nuggets of information well before that last page conclusion.

Eye-opening?

[spge]

I had a job keeping my eyes open at all, reading that over-long, poorly structured article with no useful conclusion.

Re:Eye-opening?

[Anonymous Coward]

The conclusion I made is that liberal arts majors have no business trying to convey technical information. (Jump to the conclusions page to verify that the author was a liberal arts major.)

Re:Eye-opening?

[LtGordon]

Way too verbose. We want the numbers and a valid, non-emotive conclusion based on said numbers.

P4 and MythTV

[Yeechang Lee]

I've been using a Pentium 4 3.0GHz-powered box as a MythTV frontend/backend for more than four years. It often records four high-definition over-the-air or FireWire MPEG-2 streams while playing back another.

For the first three years I used an Nvidia video card with Xv output to play the recordings at very good quality with 50-70% CPU usage. A year ago I moved to VDPAU, which gives me even better playback with under 5% CPU usage, and will do the same with h.264 recordings (generated by the Hauppauge HD-PVR, for example). Thanks to VDPAU, there's every possibility I'll be able to use the Pentium 4 box for another four years.

Re:P4 and MythTV

[wvmarle]

I have the same idea. The slowest CPU on the market is way fast enough for almost anything, unless you have very specific needs. The CPU speed issue is solved and done with. I lost interest some 10 years ago, and started to get more interested in what we are actually doing with it: the software that runs on it, and user interfaces.

Re:P4 and MythTV

[Big_Breaker]

With 100 watts of power consumption at ~10 cents a kilowatt hour you would be spending about $88 a year to run your backend 24x7. That doesn't count the extra draw for air conditioning in summer months (the benefit in winter is pretty minor). Different costs per kwh or power consumption scale accordingly. Hopefully your P4 is a northwood and not a prescott! At some point the reduction in power costs will justify a switch to something like the Revo. My total power costs are about $0.30c a kwh (don't get me started!) so I could pay for the switch in a year.

There is a great product called the "Kill-a-watt" that will measure the power consumption of a device simply by plugging it in through the kill-a-watt box. My Q6600 rig draws 120-140 watts for a good fraction of the day as measured by my kill-a-watt. It's a non-trivial cost and a 45nm chip might pay for itself in a year and a half.

Anandtech 'Bench' compares ALL recent CPUs...

[distantbody]

And its constantly growing. check it out: http://www.anandtech.com/bench/default.aspx?b=2&c=1

Re:And the answer is...

[SharpFang]

...and the fastest modern CPU is still not fast enough for another 2%.

"...no single-page view in sight"

[macraig]

There's an easy way to thwart that advertising blackmail for users of Firefox: the AutoPager extension. Antipagination would probably still work for older versions of Firefox.

Re:"...no single-page view in sight"

[Dr.Syshalt]

If you annoy your visitors to the point they start looking for ad-blocking/skipping solutions - there's something wrong with your business model. Either you fix it or you leave the business, it's just that's easy. Whining about your customers not liking some part of your business doesn't make sense. Google was probably the first to realize there is no point in annoying the hell out of surfers - that's why their ads are text-only and quite modest.

P3 Pride!

[AliasMarlowe]

I still have a P3 working at home - it's a Dell Dimension XPS T450 from about 1998. It came originally with Windows 98, and over the years it has received extra RAM, new graphics, and so forth, so it now boasts 384MB RAM and an ATI Rage Pro, as well as a 20GB disk.

Actually, it's really in semi-retirement, as it's a bit slow for modern applications, but it is still on our LAN and occasionally roused from its grave^Wslumber. At one time, it had Win2000, which it could run OK, but it was a little sluggish running Office2000. Nowadays, it dual boots between Ubuntu/Gnome and PCLinuxOS/KDE, which are about as responsive as Win2000 was. It's fine for most web browsing, IRC, file viewing (graphics, PDF, PS, etc.), text editing, and suchlike. It can handle Gimp and Inkscape once the files being edited aren't too big, and can even run LaTeX well enough, but it sucks rocks trying to run OpenOffice.

Where's the P4 vs. Modern CPUs conclusion ?

[MasJ]

Isn't this what the article summary gets at ? I couldn't find anywhere in the conclusion how the P4 actually compares to present day processors.
I'm not about to read through 17 pages of all of that just to open my eyes.

Oh, and for CPU comparisons, I usually use:
http://www.cpubenchmark.net/cpu_list.php

It's quite reliable for my choices. I just need everything to boil down to a number these days. Too much choice out there. Was simpler when you could just look at Ghz and know which is better. Now a P7700 and T8600 (examples I just made up..) could be at the same clock speed, be called Core 2 Duo and have totally different performance numbers. Confusing!

Re:Where's the P4 vs. Modern CPUs conclusion ?

[Quirkz]

The P4 appears to be included in every one of the performance benchmarks (or at least on the one performance page I bothered to check on). The headline here is badly skewed. It's a new chip comparison that includes benchmarks for a lot of older chips, including the P4. Not a "how far have we come" article remembering the bygone days of P4 yore. Bad /. headline.

P4 is quite enough...?

[indre1]

P4 3,2Ghz Northwood @3,6Ghz and a decent graphics card can easilly run Modern Warfare 2 @ 1280x1024 - what else do you need from a processor on a desktop computer?
All these multicores barely give any real advantage to a regular gamer/desktop user at the moment.

Re:P4 is quite enough...?

[thejynxed]

You do realize that overclocking Northwood core CPUs is a bad idea, right?

They have been known to suffer from random heat death, even with water cooling. They also tend to have computational errors and actually suffer worse performance when overclocked. This last bit is very batch dependent though - it really depends on where the chip was manufactured. The heat issue is still valid for every Northwood. There's a good reason most OEMs blocked overclocking in BIOS for their Northwood equipped systems.

something missing....

[pjrc]

Did anyone else notice how the Q9550 and Q9650 are absent from this article?

Probably the last thing Intel wants is these previous generation (and attractively priced) chips appearing in the "overall performance per dollar" chart on "Page 17 - The value proposition". Instead, we get a graph where only the i5 and i7 chips appear to perform well beyond any of the older options, but it's a carefully crafted illusion because the faster (and attractively priced) versions of those older chips weren't tested.

Other factors

[HalfFlat]

The article makes a strong case for the i3-530 and the i5-750, but unlike the comparable AMD processors, they have no support for ECC.

If you're using a computer just for game playing and email, that's fine. On the other hand, if you are doing anything which requires reliability — both in terms of machine stability and the consistency of results and data — ECC is a must. The premium that Intel charge for what should be a standard feature prices them out of the value computing market.

Re:Other factors

[Timothy Brownawell]

AMD processors and the newer (i3, i5, i7) Intel processors have the memory (DRAM) controller built in. The ECC here is for the DRAM, I have no idea about internal cache. Google released a study a few months ago with various information about actual observed memory error rates... after a bit of crunching on their numbers, I came up with an expected 1/5 chance of a single random bit-flip over a 6-year lifespan, and a 1/3 chance of part of your memory going bad (and causing crashes, corruption, etc, if not caught with ECC) after a couple years.

Re:Other factors

[SIGBUS]

The ECC support involves the motherboard RAM itself - each DIMM has extra chips to carry the error-correcting information. It's mainly used in servers that run 24x7. Single-bit errors are automatically corrected, and, if they occur, multiple-bit errors are at least detected. The point is of course to keep the server from crashing, or worse, silently corrupting data.

Up until about the mid-1990s, most PCs had parity memory, which provides error detection but not correction. But, in the rush to make things cheaper, computer makers realized that they could shave a few pennies off the cost of a machine by eliminating the parity chips. By doing so, they made it very easy for bad RAM to cause all sorts of hard-to-diagnose problems. Unfortunately, non-parity, non-ECC RAM became the standard, and there are very few places you can buy ECC DIMMs off-the-shelf.

Socket AM2+ and AM3 boards can easily support ECC RAM, but it's up to the motherboard maker to enable it. My recent Asus board for an OpenSolaris box has 4G of ECC memory installed.

Re:Other factors

[Entrope]

To be precise, multi-bit errors are *usually* detected. Any ECC scheme will accept faults that happen to convert stored data from one valid pattern (called a codeword in the literature) and another. They just trade off the likelihood of correctable, detectable-but-not-correctable and undetected faults (according to some model of what causes faults) versus the space and time overhead. The fault origin models are pretty good at matching what most servers see, and the standard ECC schemes are enormously valuable for long-running servers.

Mirror

[plaincorgi]

Site appears to be down;Coral mirror: http://techreport.com.nyud.net/articles.x/18448

And now for reality.

[Anonymous Coward]

As somebody working in the gaming industry, let me correct you on each of your points.

1) A great many game-related problems can be parallelized quite well. It differs by genre, but most games today could easily split graphics, audio, input processing, game logic and AI into separate threads. Some gaming engines have started to do this. AI is one area that really benefits from multiple threads of execution, so that we can simulate several different outcomes at a time.

2) This was true in the 1970s. We've come a long way since then. From compiler-assisted technology like OpenMP to a variety of higher-level approaches and techniques, multithreaded programming doesn't have to be difficult. Even just making your data immutable, like functional programmers have been trying to teach us for decades, removes many of the IPC woes you mention.

3) This isn't a problem at all. Aside from netbooks, most consumer laptops and virtually all consumer desktops sold since 2006 have had at least two cores. Intel's Core i7 has been out for over a year now, and has seen very good adoption rates. The average number of virtual CPUs (ie. physical, cores or threads) on the average gaming PC today is roughly 2.7. Besides, games shouldn't care how many CPUs are present. They adapt to the available resources. If you have one CPU, we do everything on it. If you have 8, we'll distribute the load appropriately.

4) Where did you hear this from? Again, this was true in 2003, but things have changed a lot since then. Virtually every engine written since then, by a half-decent team, has included mulitprocessor support.

Re:Mod parent up

[Timothy Brownawell]

You wouldn't happen to know the sorts or reductions in errors running registered memory brings (compared to just ECC)? If you must run registered as well, it's a comparison between Opterons and Xeons.

My understanding is that registered memory is less about error correction and more about being able to plug in way too many DIMMs per memory channel, so you don't want it unless you need ridiculous amount of memory.

If you are concerned about data integrity you might also want to look at an operating system that has ZFS - which means OpenSolaris or FreeBSD, and running mirrored or RAIDZ.

Or use Btrfs; ZFS isn't the only option with integrity checks.

Good form sir!

[Anonymous Coward]

Good, intelligent response, that respectfully corrects and didn't flame down the parent; wish we could get more of that on slashdot.

Re:Mod parent up

[swordgeek]

"Or use Btrfs; ZFS isn't the only option with integrity checks."

Oh yeah, because nothing screams "reliable" like filesystem that is still in beta.

Mod this down, wrong!

[multimediavt]

If all your processes must communicate with each other constantly, you lose the benefits of having each process processed by a different core.

This statement is just flat wrong, and hardly insightful. The only time this condition is true is if you are dealing with processors *completely isolated* from each other's memory resources. To my knowledge, there is no such beast (cluster or multi-core system) and hasn't been since the days before MPI and OpenMP (or their predecessors) existed. The only bottlenecks in the above quoted situation are latency and bandwidth so that each process CAN communicate simultaneously with any other process, running on any core, tied to the same high-speed bus/network. There are actually other ways to create data parallelism within a system so that even discrete processors can still contribute work toward a larger problem.

I build supercomputers, so I should know!

Re:And the answer is...

[nxtw]

Pentium 4 is still fast enough for 97% of the applications.

and only uses 5 times as much energy to do the same tasks!

Re:More interesting question: Pentium M vs Atom et

[RichiH]

Definitely!

What OS do you run?
If Linux, what WM/DM do you use?
If KDE 4, which is faster?

When compiling stuff, which of them is faster?

What is your overall feeling about their relative responsiveness?

Anything else I missed and you deem important :)

The most interesting part of the review:

[yourlord]

Is this little jewel on page 14:

Still, although PC hardware gets faster over time, software often gets slower. If you go look at our review from back in the day, the Pentium 4 670 rendered this same scene in 309 seconds using a single thread. Now it's taken over 600 seconds to do it with POV-Ray 3.7. Just to make sure we didn't have a configuration problem, I installed an old version of POV-Ray 3.6.1 64-bit from March, 2005 on our LGA775 test system. Lo and behold, the P4 670 completed the render in about the same time we'd measured way back when.

This to me is the most telling thing in the review. The bloat that has crept into the software made the same cpu take twice as long to render the same scene. This is why we have machines now that make the machines we used 10 years ago look stupid by the numbers, while they don't really offer that much of an improvement in experience due to the incredible amounts of software bloat eating all the extra resources available. This one little paragraph should make the people involved with POVray bow their heads in shame.