On 8 April 2013 17:21, Jacob Carlborg <doob@me.com> wrote:
On 2013-04-08 05:12, Manu wrote:

Bear in mind, most remaining C/C++ programmers are realtime programmers,
and that 2ms is 12.5% of the ENTIRE AMOUNT OF TIME that you have to run
realtime software.
If I chose not to care about 2ms only 8 times, I'll have no time left. I
would cut off my left nut for 2ms most working days!
I typically measure execution times in 10s of microseconds, if something
measures in milliseconds it's a catastrophe that needs to be urgently
addressed... and you're correct, as a C/C++ programmer, I DO design with
consideration for sub-ms execution times before I write a single line of
code.
Consequently, I have seen the GC burn well into the ms on occasion, and
as such, it is completely unacceptable in realtime software.

The GC really needs to be addressed in terms of performance; it can't
stop the world for milliseconds at a time. I'd be happy to give it
~150us every 16ms, but NOT 2ms every 200ms.
Alternatively, some urgency needs to be invested in tools to help
programmers track accidental GC allocations.

An easy workaround is to remove the GC and when you use the GC you'll get linker errors. Not pretty but it could work.

Hehe, yeah I'm aware of these tricks. But I'm not really keen to be doing that. Like I said before, I'm not actally interested in eliminating the GC, I just want it to be usable.
I like the concept of a GC, and I wish I could trust it. This requires me spending time using it and gathering experience, and perhaps making a noise about my pains here from time to time ;)


I cope with D in realtime software by carefully avoiding excess GC
usage, which, sadly, means basically avoiding the standard library at
all costs. People use concatenations all through the std lib, in the
strangest places, I just can't trust it at all anymore.
I found a weird one just a couple of days ago in the function
toUpperInPlace() (!! it allocates !!), but only when it encountered a
utf8 sequence, which means I didn't even notice while working in my
language! >_<
Imagine it, I would have gotten a bug like "game runs slow in russian",
and I would have been SOOOO "what the ****!?", while crunching to ship
the product...

To address this particular case, without having looked at the code, you do know that it's possible that the length of a Unicode string changes when converting between upper and lower case for some languages. With that in mind, it might not be a good idea to have an in place version of toUpper/Lower at all.

... I don't think that's actually true. Can you suggest such a character in any language? I think they take that sort of thing into careful consideration when designing the codepoints for a character set.
But if that is the case, then a function called toUpperInPlace is flawed by design, because it would be incapable of doing what it says it does. I'm not convinced that's true though.


d) alternatives need to be available for the functions that allocate by
nature, or an option for user-supplied allocators, like STL, so one can
allocate from a pool instead.

Have you seen this, links at the bottom:


http://3d.benjamin-thaut.de/?p=20

I hadn't. Interesting to note that I experience all the same critical issues listed at the bottom :)
Most of them seem quite fix-able, it just needs some focused attention...
My biggest issue not mentioned there though, is that when the datasets get large, the collects take longer, and they are not synced with the game, leading to regular intermittent spikes that result in regular lost frames.
A stuttering framerate is the worst possible kind of performance problem.