Slashback: Memory, Constancy, Triumph

Tonight's slashback with news of how you can help rebuild the foundations of the Internet (at least a small corner), more on slimming down the old Cathode Ray Tube, a new compiler which costs a bit more than GCC, and more.

Why not put 'em on Freenet while you're at it ... Imran Ghory writes: "Google has put out an appeal to get NetNews CDs (produced by Sterling Software and CD Publishing Corporation) which archived usenet between 1992 to 1995. Looks like Google is reviving Deja's idea of a total usenet archive."

This sounds like a worthy objective, worth rooting around for -- maybe they'll even give you a credit somewhere.

They know that of which they speak. Hot on the heels of the inexorable GCC project's 3.0.1 release, zealot (and a number of other people) wrote with the news that "Intel will release its latest compilers (the ones that optimize for P4 and can do some auto-vectorization of code) for Linux this Thursday. I'd love to see some performance numbers for compiled code on a P4 if anyone gets their hands on this ... maybe the autovectorization could help some gimp plugins speed up."

You cannot stop the chess updates Álvaro Begué writes: "Junior is the new World Micro Computer Chess Champion, Shredder won in the single processor category (five years in a row) and Goliath won the blitz tournament. Congratulations to all of them. Check out the official website."

Maybe the durned things will stick around forever. In addition to the IBM research on making ultra-slim CRT monitors, an Anonymous Coward points to another article on the future of CRTs: "This is a new technology that can integrate into existing production lines and can halve the depth of a CRT type tube. A TV normally 22 inches deep would be only 11 inches."

Comments

Re:GCC vs. Intel

[wfmcwalter]

>Would you be surprised if Intels compiler >produced faster code than GCC?

Not really. As the GCC folks readily admit, GCC is presently suboptimal at generating code for highly superscalar instruction sets. This isn't too much of a problem for P1->P4 (but gets progressivly stickier) which aren't very rich in that regard, but it gets to be a significant issue for LIW and VLIW architectures (including IA64).

This isn't a bad reflection on GCC or its developers, however - writing such a compiler (in particular, an instruction scheduler that keeps the various pipelines efficiently filled) is very hard, and this hitherto hasn't been an issue for the mainstream architectures at which GCC is targeted.

I remember reading somewhere that Philips spent more writing the compiler for its TriMedia VLIW chip (which is 5x5, as I recall) than they did actually designing the chip itself.