Disable GC entirely

[Manu]

On 8 April 2013 17:21, Jacob Carlborg <doob at 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 <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130408/85104fc8/attachment-0001.html>