D does pretty well overall with the Shootout benchmarks, but there are a couple of areas where I'm sure someone could come up with faster/more elegant solutions to a few (if not all) of them.

Main site:
http://shootout.alioth.debian.org/
Intel box (*):
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all&calc=Calculate&xfullcpu=1&xmem=0&xloc=0

There are three that are just plain slow:
- chameneos
- cheap-concurrency
- regex-dna

One that could probably be optimized:
- mandlebrot

In addition, there are two that run much slower on the GP4 test machine than
they do on my machine, which is roughly the same base hardware (P4 2.2 Ghz, 512
KB cache, 512 MB RAM). If anyone can solve this mystery (*), it be great.
- binary-trees
- cheap-concurrency

(*) At first I thought it could be an issue with the way they were running the
test or "probing" for memory use during the test runs, but they ran a couple of
the problem tests with 'time' and the results were the same - much slower on the
GP4 box than either mine (Intel) or the other (AMD) box.

Obviously feel free to attack any of them you feel like - any help would be much appreciated - but remember to follow the 'rules' for each <g> There may be a couple where someone's come up with a better algorithm since I stole, err, I mean, 'ported' the original D versions ;)

Also, the current compiler is DMD v0.137 on the site, but if something you submit requires a new feature or bug fix since then, they've been pretty good about updating the compiler if asked nicely ;) Just submit it following the FAQ (I'm the "committer") or drop it here and I'll take care of the rest.

Thanks,

- Dave

"Dave" <Dave_member@pathlink.com> wrote in message news:dt60fd$12pp$1@digitaldaemon.com...
>
> D does pretty well overall with the Shootout benchmarks, but there are a
> couple
> of areas where I'm sure someone could come up with faster/more elegant
> solutions
> to a few (if not all) of them.
>

If I understand you correctly, optimisations boosting D's scores are most welcome, but we are not necessarily expected to help the competing PLs too much, right?     ;-)

While I am with you from the marketing perspective, I am a bit worried that we might get some misleading illusions when browsing your benchmark results.

This brings me to a question:

Why was 'Ackermann' removed? It is quite a neat little application which can show you quickly some aspects of compiler optimisation. I've checked it out some time ago and it appeared that D had real problems there catching up with the competition.

Was THAT the reason why Ackermann had to go?

In article <dt6vhh$1v3n$1@digitaldaemon.com>, Bob W says...
>

More below.

>"Dave" <Dave_member@pathlink.com> wrote in message news:dt60fd$12pp$1@digitaldaemon.com...
>>
>> D does pretty well overall with the Shootout benchmarks, but there are a
>> couple
>> of areas where I'm sure someone could come up with faster/more elegant
>> solutions
>> to a few (if not all) of them.
>>
>
>If I understand you correctly, optimisations boosting D's scores are most welcome, but we are not necessarily expected to help the competing PLs too much, right?     ;-)
>

Nope. Feel free to do whatever you want, obviously, and if it happens that you come up with something that performs even better in another language, post that on the Shootout for the benefit of others, and also *here* so D can improve.

The following from the archives explains the 'original intent' well: http://www.digitalmars.com/d/archives/digitalmars/D/announce/13.html

The OP for 'help' is because lately it seems that alot of proponents for other languages have posted better algorithms or further 'tuned' the code for their language. I have been doing the lions-share of posting to the Shootout (with great contributions from a few others) and don't have the time anymore. As I said in the OP, others can probably come up with better solutions anyhow, whether or not it is a new algorithm or a 'port' of a better one already up there.

The intent of the OP is certainly not to "hide" D problems with better algorithms, but to level the playing field so D gets a fair shake and is not unfairly dismissed as slow(er) when really it's a difference in algorithms and not in D or the implementation(s).

As an aside, this exercise has actually provided Walter with some good feedback that's been acted on already. It's had a direct impact on improving the performance of a few things like AA's, buffered IO and parts of the GC that all D compilers share.

>While I am with you from the marketing perspective, I am a bit worried that we might get some misleading illusions when browsing your benchmark results.
>
>This brings me to a question:
>
>Why was 'Ackermann' removed? It is quite a neat little application which can show you quickly some aspects of compiler optimisation. I've checked it out some time ago and it appeared that D had real problems there catching up with the competition.
>
>Was THAT the reason why Ackermann had to go?
>

Absolutely not - I don't have any control whatsoever what they select to benchmark.

Ackermann is included here now anyway: http://shootout.alioth.debian.org/gp4/benchmark.php?test=recursive&lang=all

And, given the logistics of quite a few tests and many languages and implementations, I think the info. the Shootout gives us is pretty good and is why I think the Shootout is a good overall benchmark 'suite' as far as that goes.

There are other deficiencies in the DMD compiler and/or r.t. library as well, and I hope they are addressed before v1.0. A few of D's language features give D exceptional performance potential and I want to see that realized - in the end that is the most important thing to me (and I think to D's acceptance by quite a few others).

- Dave

In article <dt7kmf$2g2o$1@digitaldaemon.com>, Dave says...
>
>In article <dt6vhh$1v3n$1@digitaldaemon.com>, Bob W says...
>>
>
>More below.
>
>>"Dave" <Dave_member@pathlink.com> wrote in message news:dt60fd$12pp$1@digitaldaemon.com...
>>>
>>> D does pretty well overall with the Shootout benchmarks, but there are a
>>> couple
>>> of areas where I'm sure someone could come up with faster/more elegant
>>> solutions
>>> to a few (if not all) of them.
>>>
>>
>>If I understand you correctly, optimisations boosting D's scores are most welcome, but we are not necessarily expected to help the competing PLs too much, right?     ;-)
>>
>
>Nope. Feel free to do whatever you want, obviously, and if it happens that you come up with something that performs even better in another language, post that on the Shootout for the benefit of others, and also *here* so D can improve.
>
>The following from the archives explains the 'original intent' well: http://www.digitalmars.com/d/archives/digitalmars/D/announce/13.html
>
>The OP for 'help' is because lately it seems that alot of proponents for other languages have posted better algorithms or further 'tuned' the code for their language. I have been doing the lions-share of posting to the Shootout (with great contributions from a few others) and don't have the time anymore. As I said in the OP, others can probably come up with better solutions anyhow, whether or not it is a new algorithm or a 'port' of a better one already up there.
>
>The intent of the OP is certainly not to "hide" D problems with better algorithms, but to level the playing field so D gets a fair shake and is not unfairly dismissed as slow(er) when really it's a difference in algorithms and not in D or the implementation(s).
>
>As an aside, this exercise has actually provided Walter with some good feedback that's been acted on already. It's had a direct impact on improving the performance of a few things like AA's, buffered IO and parts of the GC that all D compilers share.
>
>>While I am with you from the marketing perspective, I am a bit worried that we might get some misleading illusions when browsing your benchmark results.
>>
>>This brings me to a question:
>>
>>Why was 'Ackermann' removed? It is quite a neat little application which can show you quickly some aspects of compiler optimisation. I've checked it out some time ago and it appeared that D had real problems there catching up with the competition.
>>
>>Was THAT the reason why Ackermann had to go?
>>
>
>Absolutely not - I don't have any control whatsoever what they select to benchmark.
>
>Ackermann is included here now anyway: http://shootout.alioth.debian.org/gp4/benchmark.php?test=recursive&lang=all
>
>And, given the logistics of quite a few tests and many languages and implementations, I think the info. the Shootout gives us is pretty good and is why I think the Shootout is a good overall benchmark 'suite' as far as that goes.
>
>There are other deficiencies in the DMD compiler and/or r.t. library as well, and I hope they are addressed before v1.0. A few of D's language features give D exceptional performance potential and I want to see that realized - in the end that is the most important thing to me (and I think to D's acceptance by quite a few others).
>
>- Dave
>
>

I don't want to pull this thread off it's original intentions, but just talking about improving performance and showing off D's features, I was curious if there's been any news on the change Walter was making (I think?) so that an object could be allocated on the stack or heap by means of the syntax:

Obj o = Obj(); // stack
or
Obj 0 = new Obj(); // class

Possibly with that feature enhancment, some of the algorithms that use the heap might improve performance by using the stack?  Anyway, I was just curious about news of that.  Sorry for going O.T. :P

-Kramer

In article <dt7tv8$2npe$1@digitaldaemon.com>, Kramer says...
>
>I don't want to pull this thread off it's original intentions, but just talking about improving performance and showing off D's features, I was curious if there's been any news on the change Walter was making (I think?) so that an object could be allocated on the stack or heap by means of the syntax:
>
>Obj o = Obj(); // stack
>or
>Obj 0 = new Obj(); // class

Alternatively... it's often been observed that auto objects could and probably should be allocated on the stack, so why not implement and use that, rather than adding new syntax? If the class in question has no destructor there shouldn't be any cleanup overhead.

(Disclaimer: I believe 'auto' has gained extra meanings since last time I looked at D in any detail; I'm talking about the old limited-RAII attribute.)

cheers,
Mike

"Kramer" <Kramer_member@pathlink.com> wrote in message news:dt7tv8$2npe$1@digitaldaemon.com...
>
> I don't want to pull this thread off it's original intentions, but just
> talking
> about improving performance and showing off D's features, I was curious if
> there's been any news on the change Walter was making (I think?) so that
> an
> object could be allocated on the stack or heap by means of the syntax:
>
> Obj o = Obj(); // stack
> or
> Obj 0 = new Obj(); // class
>
> Possibly with that feature enhancment, some of the algorithms that use the
> heap
> might improve performance by using the stack?  Anyway, I was just curious
> about
> news of that.  Sorry for going O.T. :P
>
> -Kramer
>

No problem - discussions like this are a very welcome side-effect IMHO ;)

I agree with your sentiments on stack alloc. too -- "Everything on the heap" is a big reason for Java's poor perf. reputation and D needs to avoid that before the big 1.0 release.

- Dave

In article <dt7vh7$2phd$1@digitaldaemon.com>, Mike Capp says...
>
>In article <dt7tv8$2npe$1@digitaldaemon.com>, Kramer says...
>>
>>I don't want to pull this thread off it's original intentions, but just talking about improving performance and showing off D's features, I was curious if there's been any news on the change Walter was making (I think?) so that an object could be allocated on the stack or heap by means of the syntax:
>>
>>Obj o = Obj(); // stack
>>or
>>Obj 0 = new Obj(); // class
>
>Alternatively... it's often been observed that auto objects could and probably should be allocated on the stack, so why not implement and use that, rather than adding new syntax? If the class in question has no destructor there shouldn't be any cleanup overhead.
>
>(Disclaimer: I believe 'auto' has gained extra meanings since last time I looked at D in any detail; I'm talking about the old limited-RAII attribute.)
>
>cheers,
>Mike
>
>

It actually doesn't matter to me whether this type of functionality happens through a syntax change or through auto as you say.  I just mentioned it because I remember it being brought up (the new syntax), but hadn't heard anything yet. Also, auto now does type inference.  Please correct me though if it still retains some of it's former past.

Also, I think I understand what you're saying about "If the class in question has no destructor there shouldn't be any cleanup overhead.", but that just *feels* arbitrarily limiting.  For example, what if a class was designed to handle a database connection and for performance reasons, the user wants it on the stack.  However, after the app. is in production he realizes that he's not cleaning up any database resources so he needs to add a destructor.  But his users are addicted to the speed of his app. and throwing the class on the heap would ruin that.

I realize that example is quite contrived, but the fact that it could happen is something to consider.  Hopefully I didn't respond to a point you weren't trying to make. <g>

Going off your thought though (and maybe this is what you were trying to get at, sorry if I missed it), where do the type inference objects live -- heap or stack?

-Kramer

In article <dt83r1$2tbb$1@digitaldaemon.com>, Kramer says...
>
>Also, I think I understand what you're saying about "If the class in question has no destructor there shouldn't be any cleanup overhead.", but that just *feels* arbitrarily limiting.

I'm not suggesting that RAII-auto objects _can't_ have destructors; that would defeat their whole purpose. But RAII implies that the compiler has to do some extra work to ensure that a destructor gets called, which might (depending on the tradeoffs chosen in implementation) dissuade people from using it in very performance-critical code. I just meant that _if_ there was no destructor, there wouldn't be any overhead, hence to reason to avoid this syntax.

>where do the type inference objects live -- heap or stack?

As I read it, they live wherever they'd normally live. Class objects on the heap, structs and basic types on the stack. The example given is

#class C {}
#auto c = new C();   // type inferred, not RAII
#auto C d = new C(); // RAII

Personally this syntax makes me decidedly queasy, and I very much hope it'll change. Way too much scope for confusion and unintended behaviour.

cheers,
Mike

Kramer wrote:
> It actually doesn't matter to me whether this type of functionality happens
> through a syntax change or through auto as you say.  I just mentioned it because
> I remember it being brought up (the new syntax), but hadn't heard anything yet.
> Also, auto now does type inference.  Please correct me though if it still
> retains some of it's former past.

The 'auto' attribute performs both RAII and type-inference.  So `auto Class x = new Class;` still auto-desctructs 'x'.

-- Chris Nicholson-Sauls

"Dave" <Dave_member@pathlink.com> wrote in message news:dt7kmf$2g2o$1@digitaldaemon.com...
> In article <dt6vhh$1v3n$1@digitaldaemon.com>, Bob W says...
>>
>>If I understand you correctly, optimisations boosting D's scores are most welcome, but we are not necessarily expected to help the competing PLs too much, right?     ;-)
>>
>
> Nope. Feel free to do whatever you want, obviously, and if it happens that
> you
> come up with something that performs even better in another language, post
> that
> on the Shootout for the benefit of others, and also *here* so D can
> improve.

I hope you did not take my post too seriously. I actually quite appreciate the efforts to give the general public an overview how PLs are performing on certain tasks.



> Ackermann is included here now anyway: http://shootout.alioth.debian.org/gp4/benchmark.php?test=recursive&lang=all
>

Thanks for this info.

I have seen that a D version of 'recursive' was still missing. So in the attachment of this post you'll find a slightly modified gcc version (2 flaws removed) and an almost identical D version of 'recursive'. Due to time constraint I have not attempted to do any further checks nor optimisations.

In terms of execution speed the dmd (0.146) compiled code is
trailing the gcc version, because dmd appears to be lacking essential
optimisation methods, which would be badly needed for ackermann
and other similar code.