Re: D on next-gen consoles and for game development

[Dmitry Olshansky]

24-May-2013 18:35, Manu пишет:
On 24 May 2013 19:40, Dmitry Olshansky <dmitry.o...@gmail.com
<mailto:dmitry.o...@gmail.com>> wrote:
    24-May-2013 09:02, Manu пишет:

        On 24 May 2013 14:11, Marco Leise <marco.le...@gmx.de
        <mailto:marco.le...@gmx.de>
        <mailto:marco.le...@gmx.de <mailto:marco.le...@gmx.de>>> wrote:

             Am Thu, 23 May 2013 20:21:47 -0400
             schrieb "Jonathan M Davis" <jmdavisp...@gmx.com
        <mailto:jmdavisp...@gmx.com>
             <mailto:jmdavisp...@gmx.com <mailto:jmdavisp...@gmx.com>>>:


              > At some point, we're probably going to need to
              > benchmark stuff more agressively and optimize Phobos in
        general
             more, because
              > it's the standard library. And eliminating unnecessary
        memory
             allocations
              > definitely goes along with that.
              >
              > - Jonathan M Davis

             On a related note, a while back I benchmarked the naive Phobos
             approach to create a Windows API (wchar) string from a D
             string with using alloca to convert the string on a piece of
             stack memory like this: http://dpaste.1azy.net/__b60d37d4
        <http://dpaste.1azy.net/b60d37d4>
             IIRC it was 13(!) times faster for ~100 chars of English text
             and 5 times for some multi-byte characters.
             I think this approach is too hackish for Phobos, but it
             demonstrates that there is much room.


        I don't think it's hack-ish at all, that's precisely what the
        stack is
        there for. It would be awesome for people to use alloca in
        places that
        it makes sense.
        Especially in cases where the function is a leaf or leaf-stem
        (ie, if
        there is no possibility of recursion), then using the stack
        should be
        encouraged.
        For safety, obviously phobos should do something like:
            void[] buffer = bytes < reasonable_anticipated_buffer___size ?
        alloca(bytes) : new void[bytes];

        toStringz is a very common source of allocations. This alloca
        approach
        would be great in those cases, filenames in particular.


    Alternatively just make a TLS buffer as scratchpad and use that
    everywhere.


How is that any different than just using the stack in practise?

Can pass across function boundaries up/down. Can grow arbitrary large 
without blowing up.

--
Dmitry Olshansky