<div dir="ltr">On 8 April 2013 17:21, Jacob Carlborg <span dir="ltr"><<a href="mailto:doob@me.com" target="_blank">doob@me.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 2013-04-08 05:12, Manu wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Bear in mind, most remaining C/C++ programmers are realtime programmers,<br>
and that 2ms is 12.5% of the ENTIRE AMOUNT OF TIME that you have to run<br>
realtime software.<br>
If I chose not to care about 2ms only 8 times, I'll have no time left. I<br>
would cut off my left nut for 2ms most working days!<br>
I typically measure execution times in 10s of microseconds, if something<br>
measures in milliseconds it's a catastrophe that needs to be urgently<br>
addressed... and you're correct, as a C/C++ programmer, I DO design with<br>
consideration for sub-ms execution times before I write a single line of<br>
code.<br>
Consequently, I have seen the GC burn well into the ms on occasion, and<br>
as such, it is completely unacceptable in realtime software.<br>
<br></div><div class="im">
The GC really needs to be addressed in terms of performance; it can't<br>
stop the world for milliseconds at a time. I'd be happy to give it<br>
~150us every 16ms, but NOT 2ms every 200ms.<br>
Alternatively, some urgency needs to be invested in tools to help<br>
programmers track accidental GC allocations.<br>
</div></blockquote>
<br>
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.</blockquote><div><br></div><div style>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.</div>
<div style>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 ;)</div><div><br></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I cope with D in realtime software by carefully avoiding excess GC<br>
usage, which, sadly, means basically avoiding the standard library at<br>
all costs. People use concatenations all through the std lib, in the<br>
strangest places, I just can't trust it at all anymore.<br>
I found a weird one just a couple of days ago in the function<br>
toUpperInPlace() (!! it allocates !!), but only when it encountered a<br>
utf8 sequence, which means I didn't even notice while working in my<br>
language! >_<<br>
Imagine it, I would have gotten a bug like "game runs slow in russian",<br>
and I would have been SOOOO "what the ****!?", while crunching to ship<br>
the product...<br>
</blockquote>
<br></div>
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.</blockquote>
<div style><br></div><div style>... 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.</div>
<div style>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.</div><div style><br>
</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
d) alternatives need to be available for the functions that allocate by<br>
nature, or an option for user-supplied allocators, like STL, so one can<br>
allocate from a pool instead.<br>
</blockquote>
<br></div>
Have you seen this, links at the bottom:<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://3d.benjamin-thaut.de/?p=20" target="_blank">http://3d.benjamin-thaut.de/?<u></u>p=20</a></div></div></blockquote><div><br></div><div style>I hadn't. Interesting to note that I experience all the same critical issues listed at the bottom :)</div>
<div style>Most of them seem quite fix-able, it just needs some focused attention...</div><div style>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.</div>
<div style>A stuttering framerate is the worst possible kind of performance problem.</div></div></div></div>