D benchmark code review

Manu turkeyman at gmail.com
Sun Dec 15 06:43:19 PST 2013


On 15 December 2013 23:25, <"Ola Fosheim Grøstad\"
<ola.fosheim.grostad+dlang at gmail.com>"@puremagic.com> wrote:

> On Sunday, 15 December 2013 at 12:29:46 UTC, Joseph Rushton Wakeling wrote:
>
>> Again, better I think to create first-class iOS support in D itself.  The
>> alternative you suggest really feels like sticking one's feet in the flames
>> to get out of having to do a firewalk ... :-)
>>
>
> Yes,  I thought that too for a while, in general, but then it turns out
> that C++ has kind of become a "portable source-level object format" which
> most new platforms are claiming support for. And new platforms keep coming
> in areas where you least expect them to. Like Chrome PNaCl for the web. So,
> it is a moving target. Not being able to generate C/C++ if you later decide
> to port is a lock-in unless the runtime is so minimal and simple that you
> can make do with generic LLVM IR…
>
>
>  If that's the use-case you're looking for, fair enough.  What I was
>> concerned with was whether you were overlooking other use-cases that might
>> potentially benefit you, because while looking at D through the prism of
>> "C++ replacement" is valid, it misses a whole load of other things one can
>> do with the language.
>>
>
> I am looking for a language that let me do experimental realtime audio.
> C++ is not a good fit because of the "experimental" part suggest a clean
> language where you can quickly change the code. C++ is a bit
> verbose/tedious to be a good fit. There is nothing in D that prevents it
> from providing very clean low level support, but I sense that this is not
> the direction the language is going. I could be wrong though, maybe I'll
> give it a spin after new year. :)
>

I think D can do this well. D has fairly nice stream constructs and
algorithms, and also has reasonable out-of-the-box threading features.
Audio involves so much bit-twiddling, I'd never want to do audio work in a
non-native language!

I only worry about the garbage collector. Audio processing is my biggest
fear case when there is a GC involved that is known to execute
unpredictably, often taking a very long time in the rare event it does
execute.
More work, less often, is a workload pattern that is fundamentally
incompatible with realtime software.
Incidentally, this is a significant factor in the reasoning behind calling
for a community music-game side project. I'd like to prove it out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131216/b06d0e16/attachment.html>


More information about the Digitalmars-d mailing list