Lower than C?

[Don Clugston]

Christopher Wright wrote:
> bearophile wrote:
>> Jesse Phillips:
>>
>> Thank you for your comments.
>>
>>> That is to say the less specific something is described the more one 
>>> can optimize to build for it.<
>>
>> But you need a quite more intelligent compiler to do (optimize) it, 
>> and to build a more intelligent compiler you need much more work and 
>> time. You can see how the Intel compiler optimizes compared to DMD, 
>> and the Intel compiler is quite primitive still compared to some of 
>> the things said in that article.
>>
>>
>>> I would also like to say that going to a language lower that C is 
>>> working backwards. There was a reason languages have begun to 
>>> abstract hardware features in cost to efficiency. Its to much coding 
>>> for trivial things. It sounds as though he wanted a code base where 
>>> people could take optimized code for these trivial tasks. My question 
>>> is why doesn't he start this, he already has a language, asm is the 
>>> lower level C.<
>>
>> I am not advocating the creation of a new language between ASM and C. 
>> ASM can be used in D code already, but it may require too much work 
>> (the nice High Level Assembly too: 
>> http://webster.cs.ucr.edu/AsmTools/HLA/). And it looks like C is less 
>> and less able to use well the features of the modern CPUs. Sometimes 
>> even the VM of C# 3.0 is able to automatically use hardware better 
>> than "easy" C compiled with GCC... So maybe some things can be added 
>> to D to allow a better usage of the modern CPU, such things aren't 
>> useful for the whole program and for trivial tasks, but only for the 
>> small speed-critical parts of the D code where you may need max speed 
>> (like tight loops, etc) (where some people today are already using ASM 
>> in the middle of D code, so the readability my improve). (The 
>> disadvantage is this may increase the language complexity, but not 
>> much the compiler complexity).
>>
>> Bye,
>> bearophile
> 
> I think there will be a lot of specific but common cases in which some 
> assembly tricks like they mention would result in a significant speed 
> increase. These will probably be relatively difficult for the compiler 
> to suss out. I think a library of templates containing inline asm is the 
> way to go: you get most of the benefits of custom-crafted assembly, and 
> quite possibly better than you yourself could write, but you don't have 
> to spend the time writing assembly every time you encounter a similar 
> problem.
Exactly true. That's what I've been working on the past month or so.

> The only problem is that combining these may not be nearly as efficient 
> as writing the code manually. I'm sure there's a workaround, though.

Yes. It's called CTFE + string mixins. And you can do better than a traditional 
hand-crafted library of asm code, because you can also optimise the way it's 
called. Eg, checks for special cases can be moved out of the asm library into 
the user's D code, so that the compiler has a chance to optimise them away.
<g>.