Inherent code performance advantages of D over C?

Dicebot public at dicebot.lv
Fri Dec 13 09:07:31 PST 2013


On Friday, 13 December 2013 at 17:01:21 UTC, Manu wrote:
> On 14 December 2013 02:50, Dicebot <public at dicebot.lv> wrote:
>
>> On Friday, 13 December 2013 at 16:28:33 UTC, Manu wrote:
>>
>>> I could still REALLY do with __forceinline though. D doesn't 
>>> have an
>>> effective macro.
>>> Obviously, if by 'language X' you mean 'any non-compiled 
>>> language with
>>> pointers', then I totally agree! People who make claims like 
>>> you say,
>>> don't
>>> generally know what they're talking about, or what C is 
>>> actually used for.
>>>
>>
>> I believe (and have posted it over 100 times in NG already :P) 
>> D
>> absolutely needs either way to force internal linkage or good 
>> LTO symbol
>> elimination. Without preprocessor there is not much you can do 
>> to eliminate
>> code duplication other than templates / CTFE - and it bloats 
>> resulting
>> executables damn lot, something that was very controllable in 
>> C.
>>
>
> templates aren't guaranteed to inline, and they produce 
> horrible symbol
> bloat. ctfe isn't inlining, it's pre-computation/runtime 
> elimination.
> mixin is the closest, but it can't be used effectively in 
> expressions, is
> horribly dangerous and generally horrible, and requires much 
> keyword
> pollution.

What I mean is that right now symbols always make their way to 
object file, whenever they are inlined or not. So bloat is 
completely unaffected by inlining here. And spec currently kind 
of prevents removing those. One option could have been to fix 
`export` like http://wiki.dlang.org/DIP45 proposes and get some 
kind of LTO. Simpler solution I personally would favor is to make 
template symbols internally linked by default and available only 
if explicitly aliased. But anything is really better than the 
current state.



More information about the Digitalmars-d mailing list