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