<div dir="ltr">On 7 April 2013 20:59, Paulo Pinto <span dir="ltr"><<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">I am not giving up speed. It just happens that I have been coding since 1986 and I am a polyglot programmer that started doing system programming in the Pascal family of languages, before moving into C and C++ land.</span><br>
</div>
<br>
Except for some cases, it does not matter if you get an answer in 1s or<br>
2ms, however most single language C and C++ developers care about the 2ms case even before starting to code, this is what I don't approve.<br></blockquote><div><br></div><div style>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.</div>
<div style>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!</div><div style>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.</div>
<div style>Consequently, I have seen the GC burn well into the ms on occasion, and as such, it is completely unacceptable in realtime software.</div><div style><br></div><div style>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.</div>
<div style>Alternatively, some urgency needs to be invested in tools to help programmers track accidental GC allocations.</div><div style><br></div><div style>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.</div>
<div style>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! >_<</div>
<div style>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...</div><div style><br></div><div style>
That isn't so say I don't appreciate the idea of the GC if it was efficient enough for me to use. I do use it, but very carefully. If there are only a few GC allocations it's okay at the moment, but I almost always run into trouble when I call virtually any std library function within loops. That's the critical danger in my experience.</div>
<div style><br></div><div style>Walter's claim is that D's inefficient GC is mitigated by the fact that D produces less garbage than other languages, and this is true to an extent. But given that is the case, to be reliable, it is of critical importance that:</div>
<div style>a) the programmer is aware of every allocation they are making, they can't be hidden inside benign looking library calls like toUpperInPlace.</div><div style>b) all allocations should be deliberate.</div><div style>
c) helpful messages/debugging features need to be available to track where allocations are coming from. standardised statistical output would be most helpful.</div><div style>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.</div>
<div style>e) D is not very good at reducing localised allocations to the stack, this needs some attention. (array initialisation is particularly dangerous)</div><div style>f) the GC could do with budgeting controls. I'd like to assign it 150us per 16ms, and it would defer excess workload to later frames.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Of course I think given time D compilers will be able to achieve C++ like performance, even with GC or who knows, a reference counted version.<br>

<br>
Nowadays the only place I do manual memory management is when writing Assembly code.<br></blockquote><div style><br></div><div style>Apparently you don't write realtime software. I get so frustrated on this forum by how few people care about realtime software, or any architecture other than x86 (no offense to you personally, it's a general observation).</div>
<div style>Have you ever noticed how smooth and slick the iPhone UI feels? It runs at 60hz and doesn't miss a beat. It wouldn't work in D.</div><div style>Video games can't stutter, audio/video processing can't stutter. These are all important tasks in modern computing.</div>
<div style>The vast majority of personal computers in the world today are in peoples pockets running relatively weak ARM processors, and virtually every user of these devices appreciates the smooth operation of the devices interfaces. People tend to complain when their device is locking up or stuttering. These small, weak devices are increasingly becoming responsible for _most_ personal computing tasks these days, and apart from the web, most personal computing tasks are realtime in some way (music/video, skype, etc).</div>
<div style>It's not a small industry. It is, perhaps, the largest computing industry, and sadly D is yet not generally deployable to the average engineer... only the D enthusiast prepared to take the time to hold it's hand until this is important issue is addressed.</div>
</div></div></div>