Slashdot Mirror
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.
http://techreport.com/articles.x/18448/18 is the page with the conclusion
Don't fight for your country, if your country does not fight for you.
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
And its constantly growing. check it out: http://www.anandtech.com/bench/default.aspx?b=2&c=1
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
Max.
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
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.
ics
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.
@Mindless Drivel: 100% of Twitter posts ever Tweeted.
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.
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.
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.
Oh, no! You have walked into the slavering fangs of a lurking grue!
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.
+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.
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.
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!
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.
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.
The Quirkz Handbook of Self-Improvement for People Who Are Already Pretty Okay
and only uses 5 times as much energy to do the same tasks!