You have have read this already, but I have found it interesting: http://my.opera.com/Vorlath/blog/2007/10/07/wasted-power

They show me why D may enjoy gaining some things at a level even lower than C, to allow it to use the modern CPUs better.
There one comment by spc476 reminds me that D can actually have vector ops too someday ;-)
I think it may exist a language that is both safe enough and allows to give hints to the compiler with a nice syntax to allow some of the optimizations that article discusses a lot about.

Bye,
bearophile

On Wed, 05 Dec 2007 13:25:54 -0500, bearophile wrote:

> You have have read this already, but I have found it interesting: http://my.opera.com/Vorlath/blog/2007/10/07/wasted-power
> 
> They show me why D may enjoy gaining some things at a level even lower than C, to allow it to use the modern CPUs better. There one comment by spc476 reminds me that D can actually have vector ops too someday ;-) I think it may exist a language that is both safe enough and allows to give hints to the compiler with a nice syntax to allow some of the optimizations that article discusses a lot about.
> 
> Bye,
> bearophile

If you look at the comments, someone said that the problem is C is too low level. I happen to mostly agree with is. I will use a non-computer related example.

I ask you to build me a 1991 Handa Civic CRX. This is nice and low level, you know exactly what I want, which will dictate what parts you use to build it. Now I ask for fast transportation from point A to point B. Well, you probably wouldn't build a CRX, maybe you'd go for a dragster. But you know what I want to get somewhere fast so you might even build an airplane.

That is to say the less specific something is described the more one can optimize to build for it. The problem comes in that the compiler has to have good reasoning as to what is being asked and thus where it can be optimized. I think D does a good job of telling the compiler what it needs to do without giving it too much detail.

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.

Don't get me wrong, it is important to know how interaction with hardware works, and where optimization can be added at that level. With that means that one has to understand the compiler they're using and how it optimizes code one writes so that he knows where he can manually optimize.

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

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.

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.

On Thu, 06 Dec 2007 06:12:11 -0500, 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 realize you weren't suggesting a new language between ASM and C, but even so, going lower in D may not be the way to go. If you start writing the compiler to be specific to the current machines what about the future ones? Don't get me wrong, D should pick up what it can so that optimizing for today's computers is easier, but that doesn't mean it has to be closer to the hardware level to do it.

To me D already has a lot of syntax to help the compiler make good optimization decisions, I don't know if it really fully optimizes yet either. The fact that it is moving towards pure functions seems to be good for multi-core.

Jesse Phillips wrote:
> To me D already has a lot of syntax to help the compiler make good optimization decisions, I don't know if it really fully optimizes yet either. The fact that it is moving towards pure functions seems to be good for multi-core.

High level language features are usually good for productivity. They can be good for optimization in that they give the compiler flexibility in how to implement a particular goal. An example of this is the foreach loops, where the compiler can decide whether to use indexing or pointers (the tradeoffs are CPU specific).

But some high level constructs can be bad for optimization, like dynamic typing. Dynamic typing means the code has to test, at runtime, the type of each operation and do the right thing according to the type. This kind of thing is why dynamically typed languages run 100x slower than statically typed ones.

Fortunately, since I've built optimizers, I think I'm in a good position to be able to tell if a high level construct is helpful or a hindrance to optimization.

Walter Bright:
> High level language features are usually good for productivity. They can be good for optimization in that they give the compiler flexibility in how to implement a particular goal.

I presume the "vector operations" (+, * among whole arrays) are in the group of "good for optimization" too :-)

Bye,
bearophile

bearophile Wrote:

> Walter Bright:
> > High level language features are usually good for productivity. They can be good for optimization in that they give the compiler flexibility in how to implement a particular goal.
> 
> I presume the "vector operations" (+, * among whole arrays) are in the group of "good for optimization" too :-)
> 

If one assumes that the D compiler optimizes correctly, then HLL is good.  While Walter certainly is a talented compiler writer, like gcc, I doubt he can get even most of it right.  For example, I don't think he's leveraging SSE2 for much and so on.

The good thing about D is that you can very readily plug away in x86 assembler.  The bad thing is that we can't do x86-64 or any other kind of assembler just yet, and we still don't have compile-time code reflection.

These are some good reasons why I now program in IDA Pro.

"Dan" <murpsoft@hotmail.com> wrote in message news:fja3kq$2gvl$1@digitalmars.com...
> bearophile Wrote:
>
> If one assumes that the D compiler optimizes correctly, then HLL is good. While Walter certainly is a talented compiler writer, like gcc, I doubt he can get even most of it right.  For example, I don't think he's leveraging SSE2 for much and so on.
>
> The good thing about D is that you can very readily plug away in x86 assembler.  The bad thing is that we can't do x86-64 or any other kind of assembler just yet, and we still don't have compile-time code reflection.

If you use GDC, you can use ASM for any platform -- the downside being that you have to deal with the *godawful* GCC assembler syntax (and with AT&T syntax for x86[-64]).

bearophile wrote:
> Walter Bright:
>> High level language features are usually good for productivity.
>> They can be good for optimization in that they give the compiler
>> flexibility in how to implement a particular goal.
> 
> I presume the "vector operations" (+, * among whole arrays) are in
> the group of "good for optimization" too :-)

Yes. Otherwise, they must be laboriously reconstructed from the low
level array operations, making for a very complex optimizer.