Re: make faster Richards benchmark
Jack Diederich <jack@performan cedrivers.com> wrote in message news:<mailman.5 24.1084468656.2 5742.python-list@python.org >...
[color=blue]
> I would leave python and some other languages out of the comparison.
> You can do near line-for-line translations for languages in the same class
> - say C++ and Java, or Assembly and C. Requiring the python/perl/ruby
> versions to look like a C++ program just measures how badly C++ maps to
> Python, and not much else.[/color]
There's no requirement that Python versions look like a C++ program.
Peter Hansen chose to write a Python version closely based on the C
implementation. I've now replaced that with a faster version initially
based on a Smalltalk OO implementation.
-snip-[color=blue]
> Writing benchmarks is just hard, if you allow people to solve the problem
> in whatever way they like you end up measuring how good a coder the
> language A guy is compared to the language B submitter.[/color]
Maybe the hardest thing about benchmarks is keeping some perspective
on what they might and might not mean ;-)
Yes, the fine performance of the BCPL interpreter implementation (and
the C implementation) has a lot to do with programmer skill. But I'm
not that sure about the other versions ;-)
Jack Diederich <jack@performan cedrivers.com> wrote in message news:<mailman.5 24.1084468656.2 5742.python-list@python.org >...
[color=blue]
> I would leave python and some other languages out of the comparison.
> You can do near line-for-line translations for languages in the same class
> - say C++ and Java, or Assembly and C. Requiring the python/perl/ruby
> versions to look like a C++ program just measures how badly C++ maps to
> Python, and not much else.[/color]
There's no requirement that Python versions look like a C++ program.
Peter Hansen chose to write a Python version closely based on the C
implementation. I've now replaced that with a faster version initially
based on a Smalltalk OO implementation.
-snip-[color=blue]
> Writing benchmarks is just hard, if you allow people to solve the problem
> in whatever way they like you end up measuring how good a coder the
> language A guy is compared to the language B submitter.[/color]
Maybe the hardest thing about benchmarks is keeping some perspective
on what they might and might not mean ;-)
Yes, the fine performance of the BCPL interpreter implementation (and
the C implementation) has a lot to do with programmer skill. But I'm
not that sure about the other versions ;-)
Comment