Inherent code performance advantages of D over C?

[Dicebot]

On Thursday, 12 December 2013 at 17:56:12 UTC, Walter Bright 
wrote:
>> that does not even help you in sticking with that crippled 
>> subset.
>
> Is there a point to having a compiler flag that'll warn you if 
> you use "pure"?

Ugh, how "pure" is relevant? (I have not tried it but would 
expect it to work in C-like code, it is just an annotation after 
all). I am speaking about control about hidden allocations / gc, 
referring to TypeInfo's and stuff like that. Stuff you get in C 
out-of-the box because it does no clever magic. In D right now 
all you can is to get rid of runtime and check for linker errors 
- not impossible to do, but clearly less convenient than 
compile-time errors.

> Off the top of my head:
>
> 1. compile speed

Only partially true. Large projects need separate compilation and 
D does not behave that good in such scenario. Still better than 
C, but not good enough to make a difference.

> 2. dependable sizes of basic types

Not a real issue as your platform SDK always includes some kind 
of "stdint.h"

> 3. unicode

Number one my list of advantages. Does not apply to plenty of 
projects though.

> 4. wchar_t that is actually usable

Same as (3)

> 5. thread local storage

It is lot of pain and source of problems, not advantage. Extra 
work to hack the druntime to get stuff working on barebone.

> 6. no global errno being set by the math library functions

This has made me smile :) It shows how different applications we 
have in mind speaking about "C domain".

> 7. proper IEEE 754 floating point

Potentially useful but largely mitigated by platform-specific 
development.

> 8. no preprocessor madness

Would have called this a feature if one could actually use 
something instead out of the box. But there is no way to control 
symbol visibility right now so templates / CTFE are often out of 
the toolset. And what to do without those?

> 9. modules

Other than (1) it is also more a problem than help in current 
implementation - you need to care also about emitted ModuleInfo.

> 10. being able to pass array types to functions without them 
> degenerating to pointers

Agreed,

> 11. inline assembler being a part of the language rather than 
> an extension that is in a markedly different format for every 
> compiler

Not an issue. You almost always stick to specific compiler in 
barebone world (one adapted for your platform).

> 12. forward referencing (no need to declare everything twice)

Not an issue. C programmers are not tired from typing.

> 13. no need for .h files

Same as (9)

> 14. no ridonculous struct tag name space with all those silly
>
>     typedef struct S { ... } S;
>
> declarations.

Nice but just a syntax sugar yet again.

> 15. no need for precompiled headers

Same as (9)

> 16. struct alignment as a language feature rather than an ugly 
> extension kludge

Same as (11)

> 17. no #include guard kludges

OH MY GOD EXTRA <10 LINE OVERHEAD PER HEADER

> 18. #define BEGIN { is thankfully not possible

Very tempting but partially mitigated by (8)

> 19. no need for global variables when qsorting

Doesn't matter

> 20. no global locale madness

(no idea what this means)

> And if you use D features even modestly, such as auto, purity, 
> out variables, @safe, const, etc., you can get a large 
> improvement in clarity in function APIs.

`auto` has no real value in C world because there are not crazy 
template types. @safe is a joke for barebone, you almost never be 
able to apply it :) Purity, transitive immutability - yeah, those 
are also top reasons in my list why I'd really love to see D in 
that domain.

But most of those advantages are high-level advantages. To get 
there and make use of those you need to get through issues that 
hit you from the very beginning and frustrate _before_ you can 
see how awesome high-level stuff is:

- Allocation for stuff like array literals making those unusable 
once you remove runtime away
- No internal linkage or reliable LTO  - no way to take care of 
unused symbols and control binary size / layout
- Requried to stub out TypeInfo / ModuleInfo to use literally 
anything

Note that those are not _fundamental_ language issues. It is 
possible to fix those via slight tweaks to compiler / spec. But 
it is state of affairs right now and I need to include time 
estimates to implement those any time when asked how feasible 
would have been to use D in that domain (some of my old 
colleagues have been casually asking me about it).