"Bob W" <nospam@aol.com> wrote in message news:dt8l4k$bej$1@digitaldaemon.com...
>
> "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.
>

Not too seriously ;)  You raised some good points that I wanted to respond to though. <g>

>
>> 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.
>

Thanks! I'll put it up soon. It's good to see someone else here looks at the Shootout ;)

Mike Capp wrote:
> 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.)

'auto' has gained a new meaning, and using it for both is somewhat confusing.  Also, in some cases I want a guarantee that heap allocation will not occur rather than to rely on the knowledge that stack allocating is simply a common optimization.


Sean