Lacking background about order codes (what is it?) and not a native english speaker I may miss the point here. Anyway: * Tom Knight <tk@csail.mit.edu> [Jun 05. 2006 08:29]:
Some of us think that the Hennesey and Patterson book is the worst thing to happen to computer architecture ever. The obsession with performance,
Me: obsessed with performance. What exactly is _bad_ about it?
as measured by broken benchmarks
Hmmm... my copy of H/P "Computer Architecture, A Quantitative Approach" is the second edition. It is very critical about benchmarks, see pp.21ff Synthetic benchmarks and MIPS get a royal spanking at pp.44ff
written in languages which are incapable of rational expression made the
FORTRAN, and C However, these are compiled, at least today, to machine code that is very close to what a highly experienced coder can achieve with pure assembly. 99.9 percent of all programmers will not be able to improve on what the compiler emits. Assuming you'd like to see lisp here: wouldn't lisp-benchmarks just show how close the algorithms in the lisp-engine come to peak performance? And then, isn't lisp written in C? :o)
entire field a bad joke.
I've seen enough art for art's sake publications in computer science to be very happy about H/P's approach. I wish there was a up to date (wrt. current CPUs) edition.
The only thing that saved their collective butt was the improvement in silicon technology. Imagine what we could do with that technology and a decent architecture and language.
What should it look like? CPU: for some reason internal-RISC, external-CISC seems to have won the race. Note how spectacular the latest approach (Itanium) has failed. Surely not for lack of budget. Language: ruby, python, caml, scheme, ... All bad? Not naming nose-to-CPU languages here (such as C).
On Jun 4, 2006, at 1:39 PM, Henry Baker wrote:
Hennessey & Patterson's book "Computer Architecture: A Quantitative Approach" put the last nail in the coffin re pretty order codes: [...]
me clueless, jj