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>.

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.

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

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

> 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.

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