www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Lower than C?

reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 05 2007
parent reply Jesse Phillips <jessekphillips gmail.com> writes:
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.
Dec 05 2007
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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 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
Dec 06 2007
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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 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.
Dec 06 2007
parent reply Don Clugston <dac nospam.com.au> writes:
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 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>.
Dec 07 2007
parent Christopher Wright <dhasenan gmail.com> writes:
Don Clugston wrote:
 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>.
I meant, you have your inline asm library, and given a certain pattern of usage, the best registers to use in a certain step will be different. You can do that if it's not at compile time, but CTFE doesn't allow you to alter global state. So you'd have to pass in the full guts of your loop rather than assembling out of parts, though the CTFE parser could pawn off portions by telling the modular asm interpreters which registers to use. Not so hard a problem, then; you just need a pretty good CTFE parser.
Dec 07 2007
prev sibling parent reply Jesse Phillips <jessekphillips gmail.com> writes:
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 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.
Dec 06 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
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.
Dec 06 2007
parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 06 2007
next sibling parent reply Dan <murpsoft hotmail.com> writes:
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.
Dec 06 2007
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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]).
Dec 06 2007
parent Jan Claeys <digitalmars janc.be> writes:
Op Thu, 06 Dec 2007 20:01:12 -0500, schreef Jarrett Billingsley:

 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]).
GCC supports Intel syntax too... -masm=dialect Output asm instructions using selected dialect. Supported choices are intel or att (the default one). Darwin does not support intel. -- JanC
Dec 08 2007
prev sibling parent Walter Bright <newshound1 digitalmars.com> writes:
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.
Dec 06 2007
prev sibling parent reply renoX <renosky free.fr> writes:
Jesse Phillips a écrit :
 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.
That's the theory yes: giving more information to the compiler should produce better performing programs, the truth is that all our high level language are usually slower than C.. Regards, renoX
Dec 09 2007
parent reply Adolf Mathias <adolf.mathias googlemail.com> writes:
 That's the theory yes: giving more information to the compiler should 
 produce better performing programs, the truth is that all our high level 
 language are usually slower than C..
I beg to disagree - The Ocaml and Clean compilers are pretty much on par with gcc (http://shootout.alioth.debian.org), and these languages are pretty high level.
Dec 09 2007
parent bearophile <bearophileHUGS lycos.com> writes:
Adolf Mathias:

 I beg to disagree -  The Ocaml and Clean compilers are pretty much on par with
gcc
 (http://shootout.alioth.debian.org), and these languages are pretty high level.
You probably mean this page: http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=all It shows that a really simple C compiler can be even slower than Clean, that is indeed an efficient language, you can see a little example here, where Clean is (mysteriously? Does someone knows why?) faster than C: http://shootout.alioth.debian.org/sandbox/benchmark.php?test=sumcol&lang=all Ocaml is indeed quite fast, and beside normal compilation you can use it on a VM too, and even in an interactive shell like Python that's really useful. And Ocaml has compile-time pattern matching that can be useful. So if you accept a little speed reduction, you can gain some expressivity (Ocalm (ML-style) type system is probably quite better than C-like type system). Bye, bearophile
Dec 09 2007