Slashdot Mirror

So clock speed means everything when comparing different CPUs and not their raw performance. Got it.

Not exactly, but close for single-core performance. The "MHz Myth" is largely a myth itself. As this table shows, per-MHz single-core performance between the infamously bad (even at the time) P4 and the current best (Core i7) has only improved by a factor of less than 2.6, since October 2004! (When the Pentium 3.6 EE was released).

Perhaps more importantly, the ratio between the most productive (per-mhz) chip from 2004 (Athlon64 2.6) and the most productive on the chart now is a mere 1.6! That's a 60% improvement in almost 7 years!

That is a joke. For reference, we went from the Pentium 100 (March 1994) to the Pentium 200 (June 1996) - approximately a 100% improvement in a little over 2 years.

So, no, improvements in instructions per cycle are not even close to keeping pace with what improvements in MHz used to give us. (And if you looked at instructions per cycle per transistor, it would be abysmal - which is another way of saying Moore's law is hardly helping single-threaded performance any more).

My reply

Sure kid, I got one for ya.

Nice work there. Could also serve as a "how many things are wrong with this picture" shot.

am I the only one who thinks this picture is actually really terrible quality?

Sure kid, I got one for ya.

Speaking of which, here's a photo of an Iran vs Spain matchup at RoboCup 2007, which was in Atlanta, GA. (Heck, I wouldn't be surprised at all if some of those Iranian university students do run seti@home). So, the idea that they're all just a bunch of backwards lunatics living in caves, and the surprise that they could somehow acquire commodity PC parts, seems a little odd to me.

Thank me later.

It was interesting, but the graphs are what struck me. It seems to me all the graphs should have been XY plots instead of pairs of histograms.

I agree with you on the importance of this article but ... bzip2 ? C'mon.

Here's a scatterplot of resulting file sizes and compression times from the text compression data (lower is better), and as my luck would have it, bzip2 is really the only one that's out of line - i.e. the furthest from the pareto frontier. But then, looking at the same data with file sizes plotted in the range of [0.0, 1.0], it seems like there's a major case of diminishing returns for the expensive algorithms anyways. If you care at all about compression time, good ol' gzip is still a pretty decent choice!

I agree with you on the importance of this article but ... bzip2 ? C'mon.

Here's a scatterplot of resulting file sizes and compression times from the text compression data (lower is better), and as my luck would have it, bzip2 is really the only one that's out of line - i.e. the furthest from the pareto frontier. But then, looking at the same data with file sizes plotted in the range of [0.0, 1.0], it seems like there's a major case of diminishing returns for the expensive algorithms anyways. If you care at all about compression time, good ol' gzip is still a pretty decent choice!

Mostly it works by discriminating on the basis of source or destination port. A couple apps are nice enough to set the "type of service" bits in the ip header, so you don't need to look at port numbers.

Here is my bandwidth shaping script for linux. It does work, but I admit I still get a little bit of choppiness when running p2p. (Maybe a smaller MTU would help?)

But the great-grandparent above was correct that you can't do much if your upstream truly varies moment to moment. In that case you'll get queueing within your cable modem, which you cannot prioritize.

Worse yet, due to the assyemtry, if you let BitTorrent use that full 384Kbps upstream, all other Internet use will be abysmally slow. So you're best off capping it at half that, or so.

It does work. With this in place the effect of running BitTorrent (or whatever) in the background is tiny.

I liked it better in the old days.

The graphs are at the end.

The result is that PC's have recently surpassed these 5-6 year-old SGIs in rendering of basic texture-mapped lighted polygons, but the PC hardware doesn't accelerate some things at all (like the accumulation buffer).