Genralised benchmarks are nearly always useless. That is to say, producing a benchmark that tests a feature or set of features in isolation of a real application for it or them, produces a set of numbers that have little relevance to anything--other than the benchmark.

For example, it's not hard to produce a benchmark that shows that some string operations have gotten slower in recent versions of Perl. But what those numbers won't indicate is that those recent Perl's now support unicode operations. If you don't need unicode, that may seems detrimental; but if you do need unicode, the performance benefit of it being integral to Perl rather than an add-on (or worse, self-implemented) is huge.

Likewise, benchmarking assembler against Perl would (probably; I haven't tried it:), show that assembler is faster--but you will almost certainly not switch to assembler for performing most of the things that you would do with Perl. That's because once you consider the time taken to write the programs, as well as the time taken to run them, Perl wins hands down. At least until the program has been run hundreds, if not thousands of times. If the program has to run on two or more platforms, Perl's performance will look even better.

Benchmarking is only really useful for comparing different implementations of actual applications. Any other use only provides ammunition for endless and pointless debate:)