<div dir="ltr">On 8 April 2013 16:35, 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">On Monday, 8 April 2013 at 03:13:00 UTC, Manu wrote:<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"><div class="im">
On 7 April 2013 20:59, Paulo Pinto <<a href="mailto:pjmlp@progtools.org" target="_blank">pjmlp@progtools.org</a>> wrote:<br>
<br>
</div><div class="im"><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">
I am not giving up speed. It just happens that I have been coding since<br>
1986 and I am a polyglot programmer that started doing system programming<br>
in the Pascal family of languages, before moving into C and C++ land.<br>
<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<br>
case even before starting to code, this is what I don't approve.<br>
<br>
</blockquote>
<br></div><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 as<br>
such, it is completely unacceptable in realtime software.<br>
</div></blockquote>
<br>
<br>
I do understand that, the thing is that since I am coding in 1986, I remember people complaining that C and Turbo Pascal were too slow, lets code everything in Assembly. Then C became alright, but C++ and Ada were too slow, god forbid to call virtual methods or do any operator calls in C++'s case.<br>
</blockquote><div><br></div><div style>The C++ state hasn't changed though. We still avoid virtual calls like the plague.</div><div style>One of my biggest design gripes with D, hands down, is that functions are virtual by default. I believe this is a critical mistake, and the biggest one in the language by far.</div>
<div><br></div><div><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">
Afterwards the same discussion came around with JVM and .NET environments, which while making GC widespread, also had the sad side-effect to make younger generations think that safe languages require a VM when that is not true.<br>
</blockquote><div><br></div><div style>I agree with this sad trend. D can help address this issue if it breaks free.</div><div><br></div><div><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">

Nowadays template based code beats C, systems programming is moving to C++ in mainstream OS, leaving C behind, while some security conscious areas are adopting Ada and Spark.<br></blockquote><div><br></div><div style>I don't see a significant trend towards C++ in systems code? Where are you looking?</div>
<div style>The main reason people are leaving C is because they've had quite enough of the inconvenience... 40 years is plenty thank you!</div><div style>I think the main problem for the latency is that nothing compelling enough really stood in to take the helm.</div>
<div style><br></div><div style>Liberal use of templates only beats C where memory and bandwidth are unlimited. Sadly, most computers in the world these days are getting smaller, not bigger, so this is not a trend that should be followed.</div>
<div style>Binary size is, as always, a critical factor in performance (mainly relating to the size of the targets icache). Small isolated templates produce some great wins, over-application of templates results in crippling (and very hard to track/isolate) performance issues.</div>
<div style>These performance issues are virtually impossible to fight; they tend not to appear on profilers, since they're evenly distributed throughout the code, making the whole program uniformly slow, instead of producing hot-spots, which are much easier to combat.</div>
<div style>They also have the effect of tricking their authors into erroneously thinking that their code is performing really well, since the profilers show no visible hot spots. Truth is, they didn't both writing a proper basis for comparison, and as such, they will happily continue to believe their program performs well, or even improves the situation (...most likely verified by testing a single template version of one function over a generalised one that was slower, and not factoring in the uniform slowless of the whole application they have introduced).</div>
<div style><br></div><div style>I often fear that D promotes its powerful templates too much, and that junior programmers might go even more nuts than in C++. I foresee that strict discipline will be required in the future... :/</div>
<div><br></div><div><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">
So for me when someone claims about the speed benefits of C and C++ currently have, I smile as I remember having this kind of discussions with C having the role of too slow language.</blockquote><div><br></div><div style>
C was mainly too slow due to the immaturity of compilers, and the fact that computers were not powerful enough, or had enough resources to perform decent optimisations.</div><div style>Back in those days I could disassemble basically anything and point at the compilers mistakes. (note, I was programming in the early 90's, so I imagine the situation was innumerably worse in the mid 80's)</div>
<div style>These days, I disassemble some code to check what the compiler did, and I'm usually surprised when I find a mistake. And when I do, I find it's usually MY mistake, and I tweak the C/C++ code to allow the compiler to do the proper job.</div>
<div style>With a good suite of intrinsics available to express architecture-specific concepts outside the language, I haven't had any reason to write assembly for years, the compiler/optimiser produce perfect code (within the ABI, which sometimes has problems).</div>
<div style><br></div><div style>Also, 6502 and z80 processors don't lend themselves to generic workloads. It's hard to develop a good general ABI for those machines; you typically want the ABI to be application specific... decent ABI's only started appearing for the 68000 line which had enough registers to implement a reasonable one.</div>
<div style><br></div><div style>In short, I don't think your point is entirely relevalt. It's not the nature of C that was slow in those days, it's mainly the immaturity of the implementation, combined with the fact that the hardware did not yet support the concepts.</div>
<div style>So the point is fallacious, you basically can't get better performance if you hand-write x86 assembly these days. It will probably be worse.</div><div style><br></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">
<div class="im"><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">
Walter's claim is that D's inefficient GC is mitigated by the fact that D<br>
produces less garbage than other languages, and this is true to an extent.<br>
But given that is the case, to be reliable, it is of critical importance<br>
that:<br>
a) the programmer is aware of every allocation they are making, they can't<br>
be hidden inside benign looking library calls like toUpperInPlace.<br>
b) all allocations should be deliberate.<br>
c) helpful messages/debugging features need to be available to track where<br>
allocations are coming from. standardised statistical output would be most<br>
helpful.<br>
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>
e) D is not very good at reducing localised allocations to the stack, this<br>
needs some attention. (array initialisation is particularly dangerous)<br>
f) the GC could do with budgeting controls. I'd like to assign it 150us per<br>
16ms, and it would defer excess workload to later frames.<br>
</blockquote>
<br>
<br></div>
No doubt D's GC needs to be improved, but I doubt making D a manual memory managed language will improve the language's adoption, given that all new system programming languages either use GC or reference counting as default memory management.<br>
</blockquote><div><br></div><div style>I don't advocate making D a manual managed language. I advocate making it a _possibility_. Tools need to be supplied, because it wastes a LOT of time trying to assert your code (or subsets of your code, ie, an frame execution loop), is good.</div>
<div style><br></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">
What you need is a way to do controlled allocations for the few cases that there is no way around it, but this should be reserved for modules with system code and not scattered everywhere.<br>
<br>
<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">
<br>
Of course I think given time D compilers will be able to achieve C++ like<br>
<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">
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<br>
Assembly code.<br>
<br>
</blockquote>
<br></div><div class="im">
Apparently you don't write realtime software. I get so frustrated on this<br>
forum by how few people care about realtime software, or any architecture<br>
other than x86 (no offense to you personally, it's a general observation).<br>
Have you ever noticed how smooth and slick the iPhone UI feels? It runs at<br>
60hz and doesn't miss a beat. It wouldn't work in D.<br></div>
Video games can't stutter, audio/video processing can't stutter. ....<br>
</blockquote>
<br>
I am well aware of that and actually I do follow the game industry quite closely, being my second interest after systems/distributed computing. And I used to be a IGDA member for quite a few years.<br>
<br>
However I do see a lot of games being pushed out the door in Java, C# with local optimizations done in C and C++.<br></blockquote><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">
<br>
Yeah most of they are no AAA, but that does make them less enjoyable.<br></blockquote><div><br></div><div>This is certainly a prevaling trend. The key reason for this is productivity I think. Game devs are sick of C++. Like, REALLY sick of it. Just don't want to waste their time anymore.</div>
<div>Swearing about C++ is a daily talk point. This is an industry basically screaming out for salvation, but you'll find no real consensus on where to go. People are basically dabbling at the moment.</div><div>They are also lead by the platform holders to some extent, MS has a lot of influence (holder of 2 majorplatforms) and they push C#.</div>
<div><br></div><div>But yes, also as you say, the move towards 'casual' games, where the performance requirements aren't really critical.</div><div>In 'big games' though, it's still brutally competitive. If you don't raise the technology/performance bar, your competition will.</div>
<div>D is remarkably close to offering salvation... this GC business is one of the final hurdles I think.</div><div> </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">
I also had the pleasure of being able to use the Native Oberon and AOS operating systems back in the late 90's at the university, desktop operating systems done in GC systems programming languages. Sure you could do manual memory management, but only via the SYSTEM pseudo module.<br>

<br>
One of the applications was a video player, just the decoder was written in Assembly.<br>
<br>
<a href="http://ignorethecode.net/blog/2009/04/22/oberon/" target="_blank">http://ignorethecode.net/blog/<u></u>2009/04/22/oberon/</a><br>
<br>
<br>
In the end the question is what would a D version just with manual memory management have as compelling feature against C++1y and Ada, already established languages with industry standards?<br>
<br>
Then again my lack of experience in the embedded world invalidates what I think might be the right way.<br></blockquote><div><br></div><div style>C++11 is a joke. Too little, too late if you ask me.</div><div style>It barely addresses the problems it tries to tackle, and a lot of it is really lame library solutions. Also, C++ is too stuck. Bad language design that can never be changed.</div>
<div style>It's templates are a nightmare in particular, and it'll be stuck with headers forever. I doubt the compile times will ever be significantly improved.</div><div style><br></div><div style>But again, I'm not actually advocating a D without the GC like others in this thread. I'm a realtime programmer, and I don't find the concepts incompatible, they just need tight control, and good debug/analysis tools.</div>
<div style>If I can timeslice the GC, limit it to ~150us/frame, that would do the trick. I'd pay 1-2% of my frame time for the convenience it offers for sure.</div><div style>I'd also rather it didn't stop the world. If it could collect on one thread while another thread was still churning data, that would really help the situation. Complex though...</div>
<div style>It helps that there are basically no runtime allocations in realtime software. This theoretically means the GC should have basically nothing to do! The state of the heap really shouldn't change from frame to frame, and surely that temporal consistency could be used to improve a good GC implementation? (Note: I know nothing about writing a GC)</div>
<div style>The main source of realtime allocations in D code come from array concatenation, and about 95% of that, in my experience, are completely local and could be relaxed onto the stack! But D doesn't do this in most cases (to my constant frustration)... it allocates anyway, even thought it can easily determine the allocation is localised.</div>
</div></div></div>