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
