Inherent code performance advantages of D over C?

[Manu]

On 12 December 2013 21:16, Dicebot <public at dicebot.lv> wrote:

> On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:
>
>> Currently I always advocate that C and C++ development should
>> always be done with warnings as errors enabled, coupled with
>> static analyzers at very least during CI builds, breaking them if
>> anything is found.
>>
>
> I literally can't imagine any large C project surviving any long
> without mandatory doing all listed stuff. It gets to state of
> unmaintainable insanity so fast.
>

I feel quite the opposite, I would say that about C++ personally.

I've built a C codebase from the ground over the course of a decade with
~25 programmers.
It takes discipline, and a certainly sense of simplicity in your solutions.
I personally advocate C over C++ for this very reason, it emphasises
simplicity in your solutions. It's impossible to get carried away and
create the sort of unmaintainable bullshit that C++ leads to.
I like C, I just find it verbose, and prone to boiler plate, which has a
tendency to waste programmers time... and what is more valuable than a
programmers time?


That said, there are very different C projects. When I am
> speaking that coding C in D is less convenient than in C I don't
> mean some "normal" but performance-intensive application. I can't
> imagine anyone picking C motivated only by performance - it is
> more about being very controllable. Of course with modern
> optimizers C can no more be called "macro assembler" but it is
> still much much closer to that than D. To remove all "smart"
> side-effects in D you need to get rid of all druntime, avoid
> using some language features and resort to inline assembly
> relatively often. It is definitely possible and Adam has done
> some very nice job to prove it. But it leaves you with a very
> crippled language that does not even help you in sticking with
> that crippled subset. At this point you really start asking
> yourself - what does this give me over raw C to motivate the
> transition? So far I don't see anything convincing.
>

I still consider C a macro assembler... I can easily (and usually do)
visualise the asm output I expect the compiler to produce while I'm coding.
If I'm writing performance intensive code, I am constantly disassembling
and checking that the compiler is producing the code I am expecting. This
feels normal to me.

What would you want inline assembly for in D? Inline assembly is almost
always a mistake, unless you're writing a driver. You can't possibly
schedule code better than the compiler. And in my experience, without
breaking the ABI, I don't know any constructs I could produce manually in
assembly that I can't easily coerce the compiler to generate for me (with
better scheduling). Perhaps prefetching branch prediction hinting, which
the compiler would typically require running a profile guided optimisation
pass to generate, but there are intrinsics to insert those manually which
don't interrupt the compiler's ability to reschedule the function.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131212/15ff5037/attachment-0001.html>