The earliest wayback machine for the link is https://web.archive.org/web/20060522132352/http://shootout.a... which puts Java at 1.7x C's speed and Lisp at 3.3. It does the same toy programs in the current implementation (rather than the 'hash access', 'reverse lines', 'array access' and 'list processing' benchmarks cited in the article)
> The best choice of benchmarks to measure performance is real applications… Attempts at running programs that are much simpler than a real application have led to performance pitfalls. Examples include:
> Kernels, which are small, key pieces of real applications
> Toy programs, which are 100-line programs from beginning programming assignments…
> Synthetic benchmarks, which are small, fake programs invented to try to match the profile and behavior of real applications…
> All three are discredited today, usually because the compiler writer and architect can conspire to make the computer appear faster on these stand-in programs than on real applications.
> Note that the current site argues against the benchmarks cited on norvig.
The current site tells you some of the negatives of measuring tiny toy programs (like those shown on the current website) and tells you why in-spite-of-that we're going to measure some tiny toy programs.
As-you-noted the micro micro programs referenced by Norvig were replaced a decade ago.
The article links to http://shootout.alioth.debian.org/gp4/benchmark.php?test=all... (which is a dead link).
The earliest wayback machine for the link is https://web.archive.org/web/20060522132352/http://shootout.a... which puts Java at 1.7x C's speed and Lisp at 3.3. It does the same toy programs in the current implementation (rather than the 'hash access', 'reverse lines', 'array access' and 'list processing' benchmarks cited in the article)
The last 2018 crawl of the link is a 301 to https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (the current site).
Note that the current site argues against the benchmarks cited on norvig. In https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> The best choice of benchmarks to measure performance is real applications… Attempts at running programs that are much simpler than a real application have led to performance pitfalls. Examples include:
> Kernels, which are small, key pieces of real applications
> Toy programs, which are 100-line programs from beginning programming assignments…
> Synthetic benchmarks, which are small, fake programs invented to try to match the profile and behavior of real applications…
> All three are discredited today, usually because the compiler writer and architect can conspire to make the computer appear faster on these stand-in programs than on real applications.