It is always about compiler benchmark. There are no slow or fast languages, there are slow or fast implementations of a given language.
The only point that you can make about language related performance, is to say that a given language feature cannot be made to run any faster given the best compiler implementation for the language. Having said this, the point is always about implementations. -- Paulo "Alexander" <aldem+dm...@nk7.net> wrote in message news:ipe1d9$1e0u$1...@digitalmars.com... > On 28.04.2011 18:19, Daniel Gibson wrote: > >> 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. > > But applicability of language features is a bit limited, I would say. I > think, this is not exactly fair - to take any domain-specific task (like > "matrix multiplication") and use it as a "language benchmark". > > In this particular case (matrix multiplication) - yes, we may gain from > specific features. But another example - I need to write MIME headers > parses in D - this involves (mostly) scanning of strings, comparisons > etc - it is hardly possible to use > some feature which could really help and will be fast (std.string is > mostly slow as it is a bit too generic, regexps are even more slow). > > So, I've to write my own version - using only core features of the > language (as there is no highly-optimized nor any version in standard > library anyway). > > Now, when this is done - what it will be - "compiler benchmark" or > "language benchmark"? To me, of course it does matter - how good is > generated code, as it directly affect performance of my application. > > /Alexander
