Programming language benchmarks

Daniel Gibson metalcaedes at gmail.com
Thu Apr 28 09:19:46 PDT 2011


Am 28.04.2011 18:10, schrieb Alexander:
> On 28.04.2011 17:44, Andrej Mitrovic wrote:
> 
>>
>> But then these are not programming >language< benchmarks, they are >compiler< benchmarks.
> 
>   "compiler benchmark" is something that should measure compilation speed, for instance, but "language benchmark" shows how good specific language (+ compiler, of course) is in efficiency of compiled code.
> 
>> If you can get more performance out of a language with less code and simpler syntax, then that language is better performing in my book.
> 
>   "language" is a pure language without any libraries (there are dozens of each for any kind of task, anyway).
> 
>   After all, libraries are written in language, so, performance of compiled code matters. You may even use Perl for matrix multiplication, interfacing it to external asm library, and it will beat pure C ;)
> 
>   But of course, it all depends on application - if you can find something already implemented and use it - then you are right, but, if you have to write something on your own (something that doesn't exists), and you *need* performance, then your
> priorities will be shifted, I think ;)
> 
> /Alexander

But there's no need for a D compiler to optimize loops that just copy
parts of an array into another array (and similar stuff), because in D
you use slices for that - they're (probably) faster and easier to use.
So IMHO it's fair to use slices where possible.
(And they're a language feature and not just part of the library)
Furthermore this particular benchmark is a "programming language
benchmark" and not a compiler benchmark, so it's fair to use every
feature of the language.

Cheers,
- Daniel


More information about the Digitalmars-d mailing list