On Tue, Dec 10, 2013 at 08:28:14AM +0100, Joseph Rushton Wakeling wrote: > On 09/12/13 20:45, Araq wrote: > >That language X is faster than C in "practice" because X is much more > >developer friendly and thus you can tweak your code much easier etc. > >is an argument of every language out there. > > Yes, but most languages (certainly most "friendly" ones) do not > allow you to drill down into the details in the way that D does. > > The claim that's made for most languages in my experience is that, > sure, the language is ultimately slower, but the developer time > saved is worth more than the performance hit, and if you ever > _really_ need to gain that extra performance, you can always drop > down into C. Of course, that assumption doesn't hold for some > domains (e.g. intensive scientific simulation, games...) which is > why C/C++ still has a significant presence there. > > By contrast with D you get all that friendliness of refactoring and > redesigning and extra time to experiment with alternatives, but in a > language which is speed-wise on a par with C anyway; and if its > higher-level constructs cause any problems, you can drill down to > micro-management of your program _while still writing in D_. That's > why D is very useful for heavy-duty scientific simulation and why > unlike most other friendly languages it's a genuine contender for > games programming.
Recently I rewrote one of my personal pet projects in D. It turned out a lot better than the original C version -- D's high-level features made it easier to implement complex functionality with relatively simple (and readable!) code. Then I came to a CPU-intensive bit, and initially things didn't look very good: a particular medium-sized problem that I was using as a real-life test case ran in seconds in the C version, but took a very long time with the D version (about 40 *minutes*, if I remember). I was a bit disappointed, but remembered that the D version was still not yet refined. It turned out that I had overlooked a simple but very significant optimization present in the C version that hadn't been implemented in the D version yet. (Basically, it's a brute-force combinatorial algorithm, so the complexity is exponential, and every little problem reduction can make a big difference. In this case, it was a matter of recognizing the equivalence of certain problem combinations that allowed the reduction of the search space by a factor of about n factorial.) In the original C code, it took quite a while to implement this optimization because ... well, in C, you had to spell out every last thing, otherwise it just won't work. In D, I kicked a crude version of it out in under a day. Result? The D version now runs faster than the C version -- perhaps up to an order of magnitude. I was suitably impressed. It's not all roses and flowers yet, of course -- the D version has some memory usage issues that I need to work on, but the fact that an almost optimal-performing version of the code could be done so smoothly in such a short time speaks good things about D. Plus, D's ease of expression made it so easy to implement new algorithms without incurring runtime costs -- I easily implemented an A* search algorithm instead of the original plain BFS, and now, for certain problems, the D version flat out beats the C version in terms of performance. Could I have implemented an A* search in the C version? Sure, after weeks or months of careful reworking of the C code to make sure I didn't break anything or introduce any segfaults. Arguably, the result would perform better than D. But the fact of the matter is, with D, I achieved extremely good performance for just a few days' work. And I think that's the crux of the issue here: sure in C you can code in a way that will beat every other language out there. But it requires a lot of careful effort to get you there (not to mention dealing with all the associated pitfalls). D may not get you all the way to absolute every-last-drop-from-the-CPU performance, but it gets you 90% of the way there, with far, far less effort. Most of the time, this is a far better ROI than in C. T -- Three out of two people have difficulties with fractions. -- Dirk Eddelbuettel