www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - pi benchmark on ldc and dmd

reply Walter Bright <newshound2 digitalmars.com> writes:
http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98

Anyone care to examine the assembler output and figure out why?
Aug 01 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98
 
 Anyone care to examine the assembler output and figure out why?

Do you mean code similar to this one, or code that uses std.bigint? http://shootout.alioth.debian.org/debian/program.php?test=pidigits&lang=gdc&id=3 Bye, bearophile
Aug 01 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 Do you mean code similar to this one, or code that uses std.bigint?

It was something that used bigint. I whipped it up myself earlier this morning, but left the code on my laptop. I'll post it when I have a chance. I ran obj2asm on it myself, but was a little short on time, so I haven't really analyzed it yet.
Aug 01 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:
 
 It was something that used bigint. I whipped it up myself earlier
 this morning, but left the code on my laptop. I'll post it when
 I have a chance.

OK. In such situations it's never enough to compare the D code compiled with DMD to the D code compiled with LDC. You also need a reference point, like a C version compiled with GCC (here using GMP bignums). Such reference points are necessary to anchor performance discussions to something. Bye, bearophile
Aug 01 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
bearophile wrote:
 In such situations it's never enough to compare the D code compiled
 with DMD to the D code compiled with LDC. You also need a reference
 point, like a C version compiled with GCC (here using GMP bignums).
 Such reference points are necessary to anchor performance
 discussions to something.

Actually, I don't think that would be relevant here. The thread started with someone saying the DMD backend is garbage and should be abandoned. I'm sick and tired of hearing people say that. The Digital Mars code has many, many advantages over the others*. But, it was challenged specifically on the optimizer, so to check that out, I wanted all other things to be equal. Same code, same front end, same computer, as close to same runtime and library is possible with different compilers. The only difference should be the backend so we can draw conclusions about it without other factors skewing the results. So for this, I just wanted to compare dmd backend to ldc and gdc backend so I didn't worry too much about absolute numbers or other languages. (Actually, one of the reasons I picked the pi one was after the embarrassing defeat in floating point, I was hoping dmd could score a second victory and I could follow up on that "prove it" post with satisfaction. Alas, the facts didn't work out that way. Though, I still do find dmd to beat g++ on a lot of real world code - things like slices actually make a sizable difference.) But regardless, it was just about comparing backends, not doing language comparisons. === * To name a huge one. Today was the first time I ever got ldc or gdc to actually work on my computer, and it took a long, long time to do it. I've tried in the past, and failed, so this was a triumph. Big success. I was waiting over an hour just for gcc+gdc to compile! In the time it takes for gcc's configure script to run, you can make clean, build dmd, druntime and phobos. It's a huge hassle to get the code together too. I had to go to *four* different sites to get gdc's stuff together (like 80 MB of crap, compressed!), and two different ones to get even the ldc binary to work. Pain in my ASS. And this is on Linux too. I pity the fool who tries to do this on Windows, knowing how so much linux software treats their Windows "ports". I'd like to contrast to dmd: unzip and play with wild abandon.
Aug 01 2011
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
 LDC builds in under a half hour, even on my underpowered ARM SoC,
 so I don't see how you could be having trouble there.

Building dmd from the zip took 37 *seconds* for me just now, after running a make clean (this is on Linux). gdc and ldc have their advantages, but they have disadvantages too. I think the people saying "abandon dmd" don't know the other side of the story. Basically, I think the more compilers we have for D the better. gdc is good. ldc is good. And so is dmd. We shouldn't abandon any of them.
Aug 02 2011
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
I think I have it: 64 bit registers. I got ldc to work
in 32 bit (didn't have that yesterday, so I was doing 64 bit only)
and compiled.

No difference in timing between ldc 32 bit and dmd 32 bit.
The disassembly isn't identical but the time is. (The disassembly
seems to mainly order things differently, but ldc has fewer jump
instructions too.)

Anyway.

In 64 bit, ldc gets a speedup over dmd. Looking at the asm
output, it looks like dmd doesn't use any of the new registers,
whereas ldc does. (dmd's 64 bit looks mostly like 32 bit code with
r instead of e.)


Here's the program. It's based on one of the Python ones.

====
import std.bigint;
import std.stdio;

alias BigInt number;

void main() {
	auto N = 10000;

	number i, k, ns;
	number k1 = 1;
	number n,a,d,t,u;
	n = 1;
	d = 1;
	while(1) {
		k += 1;
		t = n<<1;
		n *= k;
		a += t;
		k1 += 2;
		a *= k1;
		d *= k1;
		if(a >= n) {
			t = (n*3 +a)/d;
			u = (n*3 +a)%d;
			u += n;
			if(d > u) {
				ns = ns*10 + t;
				i += 1;
				if(i % 10 == 0) {
					debug writefln ("%010d\t:%d", ns, i);
					ns = 0;
				}
				if(i >= N) {
					break;
				}
				a -= d*t;
				a *= 10;
				n *= 10;
			}
		}
	}
}
=====

BigInt's calls aren't inlined, but that's a frontend issue. Let's
eliminate that by switching to long in that alias.

The result will be wrong, but that's beside the point for now. I
just want to see integer math. (this is why the writefln is debug
too)

With optimizations turned on, ldc again wins by the same ratio -
it runs in about 2/3 the time - and the code is much easier to look
at.


Let's see what's going on.


The relevant loop from DMD (64 bit):

===
L47:		inc	qword ptr -040h[RBP]
		mov	RAX,-028h[RBP]
		add	RAX,RAX
		mov	-010h[RBP],RAX
		mov	RAX,-040h[RBP]
		imul	RAX,-028h[RBP]
		mov	-028h[RBP],RAX
		mov	RAX,-010h[RBP]
		add	-020h[RBP],RAX
		add	qword ptr -030h[RBP],2
		mov	RAX,-030h[RBP]
		imul	RAX,-020h[RBP]
		mov	-020h[RBP],RAX
		mov	RAX,-030h[RBP]
		imul	RAX,-018h[RBP]
		mov	-018h[RBP],RAX
		mov	RAX,-020h[RBP]
		cmp	RAX,-028h[RBP]
		jl	L47
		mov	RAX,-028h[RBP]
		lea	RAX,[RAX*2][RAX]
		add	RAX,-020h[RBP]
		mov	-058h[RBP],RAX
		cqo
		idiv	qword ptr -018h[RBP]
		mov	-010h[RBP],RAX
		mov	RAX,-058h[RBP]
		cqo
		idiv	qword ptr -018h[RBP]
		mov	-8[RBP],RDX
		mov	RAX,-028h[RBP]
		add	-8[RBP],RAX
		mov	RAX,-018h[RBP]
		cmp	RAX,-8[RBP]
		jle	L47
		mov	RAX,-038h[RBP]
		lea	RAX,[RAX*4][RAX]
		add	RAX,RAX
		add	RAX,-010h[RBP]
		mov	-038h[RBP],RAX
		inc	qword ptr -048h[RBP]
		mov	RAX,-048h[RBP]
		mov	RCX,0Ah
		cqo
		idiv	RCX
		test	RDX,RDX
		jne	L109
		mov	qword ptr -038h[RBP],0
L109:		cmp	qword ptr -048h[RBP],02710h
		jge	L137
		mov	RAX,-018h[RBP]
		imul	RAX,-010h[RBP]
		sub	-020h[RBP],RAX
		imul	EAX,-020h[RBP],0Ah
		mov	-020h[RBP],RAX
		imul	EAX,-028h[RBP],0Ah
		mov	-028h[RBP],RAX
		jmp	  L47
===


and from ldc 64 bit:

====
L20:		add	RDI,2
		inc	RCX
		lea	R9,[R10*2][R9]
		imul	R9,RDI
		imul	R8,RDI
		imul	R10,RCX
		cmp	R9,R10
		jl	L20
		lea	RAX,[R10*2][R10]
		add	RAX,R9
		cqo
		idiv	R8
		add	RDX,R10
		cmp	R8,RDX
		jle	L20
		cmp	RSI,0270Fh
		jg	L73
		imul	RAX,R8
		sub	R9,RAX
		add	R9,R9
		lea	R9,[R9*4][R9]
		inc	RSI
		add	R10,R10
		lea	R10,[R10*4][R10]
		jmp short	L20
===


First thing that immediately pops out is the code is a lot shorter.
Second thing that jumps out is it looks like ldc makes better use
of the registers. Indeed, the shortness looks to be thanks to
the registers eliminating a lot of movs.



So I'm pretty sure the difference is caused by dmd not using the
new registers in x64. The other differences look trivial to my
eyes.
Aug 02 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2011 12:49 PM, Adam D. Ruppe wrote:
 So I'm pretty sure the difference is caused by dmd not using the
 new registers in x64. The other differences look trivial to my
 eyes.

dmd does use all the registers on the x64, but it seems to not be enregistering here. I'll have a look see.
Aug 02 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Adam D. Ruppe:

 Here's the program. It's based on one of the Python ones.

The D code is about 2.8 times slower than the Haskell version, and it has a bug, shown here: import std.stdio, std.bigint; void main() { int x = 100; writefln("%010d", x); BigInt bx = x; writefln("%010d", bx); } Output: 0000000100 100 ---------------------------- The Haskell code I've used: -- Compile with: ghc --make -O3 -XBangPatterns -rtsopts pidigits_hs.hs import System pidgits n = 0 % (0 # (1,0,1)) where i%ds | i >= n = [] | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j%t where k = i+10; j = min n k (h,t) | k > n = (take (n`mod`10) ds ++ replicate (k-n) " ",[]) | True = splitAt 10 ds j # s | n>a || r+n>=d = k # t | True = show q : k # (n*10,(a-(q*d))*10,d) where k = j+1; t (n,a,d)=k&s; (q,r)=(n*3+a)`divMod`d j&(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1) main = putStr.pidgits.read.head =<< getArgs Bye, bearophile
Aug 02 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2011 12:49 PM, Adam D. Ruppe wrote:
 So I'm pretty sure the difference is caused by dmd not using the
 new registers in x64. The other differences look trivial to my
 eyes.

When I compile it, it uses the registers: L2E: inc R11 lea R9D,[00h][RSI*2] mov R9,R9 mov RCX,R11 imul RCX,RSI mov RSI,RCX add RDI,R9 add R8,2 mov RDX,R8 imul RDX,RDI mov RDI,RDX mov R10,R8 imul R10,RBX mov RBX,R10 cmp RDI,RSI jl L2E lea RAX,[RCX*2][RCX] add RAX,RDX mov -8[RBP],RAX cqo idiv R10 mov R9,RAX mov R9,R9 mov RAX,-8[RBP] cqo idiv R10 mov R12,RDX mov R12,R12 add R12,RSI cmp RBX,R12 jle L2E lea R14,[R14*4][R14] add R14,R14 add R14,R9 mov R14,R14 inc R13 mov RAX,R13 mov RCX,0Ah cqo idiv RCX test RDX,RDX jne LBD xor R14,R14 LBD: cmp R13,02710h jge LE3 mov RDX,RBX imul RDX,R9 sub RDI,RDX imul R10D,RDI,0Ah mov RDI,R10 imul R12D,RSI,0Ah mov RSI,R12 jmp L2E All I did with your example was replace BigInt with long.
Aug 02 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
Walter Bright wrote:
 All I did with your example was replace BigInt with long.

hmm.... this is my error, but might be a bug too. Take that same program and add some inline asm to it. void main() { asm { nop; } [... the rest is identical ...] } Now compile it and check the output. With the asm, I get the output I posted. If I cut it out, I get what you posted. My error here is when I did the obj2asm the first time, I added an instruction inline so I could confirm quickly that I was in the right place in the file. (I cut that out later but forgot to rerun obj2asm.)
Aug 02 2011
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2011 3:23 PM, Trass3r wrote:
 Any reason for all those mov x,x 's?

No. They'll get removed shortly. I see three problems with dmd's codegen here: 1. those redundant moves 2. failing to merge a couple divides 3. replacing a mul with an add/lea I'll see about taking care of them. (2) is the most likely culprit on the speed.
Aug 02 2011
prev sibling next sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
Ok.. I'm pretty sure that's a bug I discovered the other day in the 
initilization code of asm blocks.  I've already got a fix for it and will 
be sending a pull request shortly.

The asm semantic code calls the 32bit initialization code of the backend 
unconditionally, which is just wrong.

On Tue, 2 Aug 2011, Adam D. Ruppe wrote:

 Walter Bright wrote:
 All I did with your example was replace BigInt with long.

hmm.... this is my error, but might be a bug too. Take that same program and add some inline asm to it. void main() { asm { nop; } [... the rest is identical ...] } Now compile it and check the output. With the asm, I get the output I posted. If I cut it out, I get what you posted. My error here is when I did the obj2asm the first time, I added an instruction inline so I could confirm quickly that I was in the right place in the file. (I cut that out later but forgot to rerun obj2asm.)

Aug 02 2011
prev sibling parent Brad Roberts <braddr slice-2.puremagic.com> writes:
https://github.com/D-Programming-Language/dmd/pull/287

Before pulling this, though, the current win32 compilation failure should 
be fixed to avoid compounding problems:

  https://github.com/D-Programming-Language/dmd/pull/288

Later,
Brad

On Tue, 2 Aug 2011, Brad Roberts wrote:

 Ok.. I'm pretty sure that's a bug I discovered the other day in the 
 initilization code of asm blocks.  I've already got a fix for it and will 
 be sending a pull request shortly.
 
 The asm semantic code calls the 32bit initialization code of the backend 
 unconditionally, which is just wrong.
 
 On Tue, 2 Aug 2011, Adam D. Ruppe wrote:
 
 Walter Bright wrote:
 All I did with your example was replace BigInt with long.

hmm.... this is my error, but might be a bug too. Take that same program and add some inline asm to it. void main() { asm { nop; } [... the rest is identical ...] } Now compile it and check the output. With the asm, I get the output I posted. If I cut it out, I get what you posted. My error here is when I did the obj2asm the first time, I added an instruction inline so I could confirm quickly that I was in the right place in the file. (I cut that out later but forgot to rerun obj2asm.)


Aug 02 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--001636ed78413ae84604a97f3820
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Aug 1, 2011 at 8:38 PM, Adam D. Ruppe <destructionator gmail.com>wrote:

 bearophile wrote:
 In such situations it's never enough to compare the D code compiled
 with DMD to the D code compiled with LDC. You also need a reference
 point, like a C version compiled with GCC (here using GMP bignums).
 Such reference points are necessary to anchor performance
 discussions to something.

Actually, I don't think that would be relevant here. The thread started with someone saying the DMD backend is garbage and should be abandoned. I'm sick and tired of hearing people say that. The Digital Mars code has many, many advantages over the others*. But, it was challenged specifically on the optimizer, so to check that out, I wanted all other things to be equal. Same code, same front end, same computer, as close to same runtime and library is possible with different compilers. The only difference should be the backend so we can draw conclusions about it without other factors skewing the results. So for this, I just wanted to compare dmd backend to ldc and gdc backend so I didn't worry too much about absolute numbers or other languages. (Actually, one of the reasons I picked the pi one was after the embarrassing defeat in floating point, I was hoping dmd could score a second victory and I could follow up on that "prove it" post with satisfaction. Alas, the facts didn't work out that way. Though, I still do find dmd to beat g++ on a lot of real world code - things like slices actually make a sizable difference.) But regardless, it was just about comparing backends, not doing language comparisons. === * To name a huge one. Today was the first time I ever got ldc or gdc to actually work on my computer, and it took a long, long time to do it. I've tried in the past, and failed, so this was a triumph. Big success. I was waiting over an hour just for gcc+gdc to compile! In the time it takes for gcc's configure script to run, you can make clean, build dmd, druntime and phobos. It's a huge hassle to get the code together too. I had to go to *four* different sites to get gdc's stuff together (like 80 MB of crap, compressed!), and two different ones to get even the ldc binary to work. Pain in my ASS. And this is on Linux too. I pity the fool who tries to do this on Windows, knowing how so much linux software treats their Windows "ports". I'd like to contrast to dmd: unzip and play with wild abandon.

Yes, GDC takes forever and a half to build. That's true of anything in GCC, and it's just because they don't trust the native C compiler at all. LDC builds in under a half hour, even on my underpowered ARM SoC, so I don't see how you could be having trouble there. As for Windows, Daniel Green (hopefully I'm remembering right) has been posting GDC binaries. I do respect that DMD generates reasonably fast executables recklessly fast, but it also doesn't exist outside x86 and x86_64 and the debug symbols (at least on Linux) are just hilariously bad. Now if I could just get GDC to pad structs correctly on ARM... --001636ed78413ae84604a97f3820 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Mon, Aug 1, 2011 at 8:38 PM, Adam D. Ruppe <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destructio= nator gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">bearophile wrote:<br> &gt; In such situations it&#39;s never enough to compare the D code compile= d<br> &gt; with DMD to the D code compiled with LDC. You also need a reference<br=


&gt; discussions to something.<br> <br> </div>Actually, I don&#39;t think that would be relevant here.<br> <br> The thread started with someone saying the DMD backend is garbage<br> and should be abandoned.<br> <br> I&#39;m sick and tired of hearing people say that. The Digital Mars<br> code has many, many advantages over the others*.<br> <br> But, it was challenged specifically on the optimizer, so to<br> check that out, I wanted all other things to be equal.<br> <br> Same code, same front end, same computer, as close to same runtime<br> and library is possible with different compilers. The only<br> difference should be the backend so we can draw conclusions about<br> it without other factors skewing the results.<br> <br> <br> So for this, I just wanted to compare dmd backend to ldc and<br> gdc backend so I didn&#39;t worry too much about absolute numbers<br> or other languages. (Actually, one of the reasons I picked the<br> pi one was after the embarrassing defeat in floating point, I was<br> hoping dmd could score a second victory and I could follow up<br> on that &quot;prove it&quot; post with satisfaction. Alas, the facts didn&#= 39;t<br> work out that way. Though, I still do find dmd to beat g++<br> on a lot of real world code - things like slices actually make<br> a sizable difference.)<br> <br> But regardless, it was just about comparing backends, not<br> doing language comparisons.<br> <br> =3D=3D=3D<br> <br> * To name a huge one. Today was the first time I ever got ldc<br> or gdc to actually work on my computer, and it took a long, long<br> time to do it. I&#39;ve tried in the past, and failed, so this was<br> a triumph. Big success.<br> <br> I was waiting over an hour just for gcc+gdc to compile! In the<br> time it takes for gcc&#39;s configure script to run, you can make<br> clean, build dmd, druntime and phobos.<br> <br> It&#39;s a huge hassle to get the code together too. I had to go<br> to *four* different sites to get gdc&#39;s stuff together (like 80<br> MB of crap, compressed!), and two different ones to get even the<br> ldc binary to work. Pain in my ASS.<br> <br> <br> And this is on Linux too. I pity the fool who tries to do this<br> on Windows, knowing how so much linux software treats their<br> Windows &quot;ports&quot;.<br> <br> <br> I&#39;d like to contrast to dmd: unzip and play with wild abandon.<br></blo= ckquote><div><br></div><div>Yes, GDC takes forever and a half to build. Tha= t&#39;s true of anything in GCC, and it&#39;s just because they don&#39;t t= rust the native C compiler at all. LDC builds in under a half hour, even on= my underpowered ARM SoC, so I don&#39;t see how you could be having troubl= e there.=A0</div> </div>As for Windows, Daniel Green (hopefully I&#39;m remembering right) ha= s been posting GDC binaries.<div><br></div><div>I do respect that DMD gener= ates reasonably fast executables recklessly fast, but it also doesn&#39;t e= xist outside x86 and x86_64 and the debug symbols (at least on Linux) are j= ust hilariously bad.</div> <div><br></div><div>Now if I could just get GDC to pad structs correctly on= ARM...</div> --001636ed78413ae84604a97f3820--
Aug 01 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 02.08.2011, 05:38 Uhr, schrieb Adam D. Ruppe  
<destructionator gmail.com>:
 I was waiting over an hour just for gcc+gdc to compile! In the
 time it takes for gcc's configure script to run, you can make
 clean, build dmd, druntime and phobos.

Make sure you disable bootstrapping. Compiling gdc works pleasantly fast for me. Try compiling it on Windows, that's what I call slow.
Aug 02 2011
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e68ee3edf3ebcf04a98b2e25
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Aug 2, 2011 at 7:08 AM, Adam D. Ruppe <destructionator gmail.com>wrote:

 LDC builds in under a half hour, even on my underpowered ARM SoC,
 so I don't see how you could be having trouble there.

Building dmd from the zip took 37 *seconds* for me just now, after running a make clean (this is on Linux). gdc and ldc have their advantages, but they have disadvantages too. I think the people saying "abandon dmd" don't know the other side of the story. Basically, I think the more compilers we have for D the better. gdc is good. ldc is good. And so is dmd. We shouldn't abandon any of them.

For the record, I'm fine with the current arrangement and just playing devil's advocate here: So far, you've outlined that GDC takes a while to build and the build processes for GDC and LDC are inconvenient as the only disadvantages they have. LDC took about 3 minutes on a Linux VM on my laptop, and since it has proper incremental build support through CMake, I don't really see that qualifying as a disadvantage. The only people that really need to regularly build compilers are the folks that work on them, and that's why we have incremental builds. Now, DMD does have speed on its side. It doesn't have debugging support (you have to jump through hoops on Windows and Linux is just a joke), binary and object file compatibility (even GDC has more going for it on Windows than DMD does), platform compatibility (outside x86 and x86_64), name recognition (I'm a college student, and people look at me funny when I mention Digital Mars), shared library support, and acceptance in the Linux world. The reason I use GDC for pretty much all my development is that it has all those things, and the reason I think it's worth playing devil's advocate and really considering the current situation is that GDC and LDC get all this for free by wiring up the DMD frontend to a different backend. The current state of affairs is certainly maintainable, but I think it's worth some thought as to whether it would be better in the long run if we started officially supporting a more accepted backend. My example would be Go, which got all sorts of notice when gccgo became important enough to get into the GCC codebase. I'm not saying DMD is terrible because it isn't. I'm just saying that there are a lot of benefits to be had by developing a more mature compiler on top of GCC or LLVM, and that we should consider whether that's a goal we should be working more towards. --0016e68ee3edf3ebcf04a98b2e25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Aug 2, 2011 at 7:08 AM, Adam D. Ruppe <s= pan dir=3D"ltr">&lt;<a href=3D"mailto:destructionator gmail.com">destructio= nator gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class=3D"im">&gt; LDC builds in under a half hour, even on my underpow= ered ARM SoC,<br> &gt; so I don&#39;t see how you could be having trouble there.<br> <br> </div>Building dmd from the zip took 37 *seconds* for me just now, after<br=

<br> gdc and ldc have their advantages, but they have disadvantages too.<br> I think the people saying &quot;abandon dmd&quot; don&#39;t know the other = side<br> of the story.<br> <br> <br> Basically, I think the more compilers we have for D the better.<br> gdc is good. ldc is good. And so is dmd. We shouldn&#39;t abandon<br> any of them.<br></blockquote><div><br></div><div>For the record, I&#39;m fi= ne with the current arrangement and just playing devil&#39;s advocate here:= </div><div><br></div><div>So far, you&#39;ve outlined that GDC takes a whil= e to build and the build processes for GDC and LDC are inconvenient as the = only disadvantages they have.</div> <div>LDC took about 3 minutes on a Linux VM on my laptop, and since it has = proper incremental build support through CMake, I don&#39;t really see that= qualifying as a disadvantage. The only people that really need to regularl= y build compilers are the folks that work on them, and that&#39;s why we ha= ve incremental builds.</div> <div>Now, DMD does have speed on its side. It doesn&#39;t have debugging su= pport (you have to jump through hoops on Windows and Linux is just a joke),= binary and object file compatibility (even GDC has more going for it on Wi= ndows than DMD does), platform compatibility (outside x86 and x86_64), name= recognition (I&#39;m a college student, and people look at me funny when I= mention Digital Mars), shared library support, and acceptance in the Linux= world.</div> <div>The reason I use GDC for pretty much all my development is that it has= all those things, and the reason I think it&#39;s worth playing devil&#39;= s advocate and really considering the current situation is that GDC and LDC= get all this for free by wiring up the DMD frontend to a different backend= . The current state of affairs is certainly maintainable, but I think it&#3= 9;s worth some thought as to whether it would be better in the long run if = we started officially supporting a more accepted backend.</div> <div>My example would be Go, which got all sorts of notice when gccgo becam= e important enough to get into the GCC codebase.</div><div><br></div><div>I= &#39;m not saying DMD is terrible because it isn&#39;t. I&#39;m just saying= that there are a lot of benefits to be had by developing a more mature com= piler on top of GCC or LLVM, and that we should consider whether that&#39;s= a goal we should be working more towards.</div> </div> --0016e68ee3edf3ebcf04a98b2e25--
Aug 02 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 02.08.2011, 22:38 Uhr, schrieb Walter Bright  
<newshound2 digitalmars.com>:

 L2E:            inc     R11
                  lea     R9D,[00h][RSI*2]
                  mov     R9,R9

                  mov     R9,RAX
                  mov     R9,R9

                  mov     R12,RDX
                  mov     R12,R12

                  lea     R14,[R14*4][R14]
                  add     R14,R14
                  add     R14,R9
                  mov     R14,R14

Any reason for all those mov x,x 's?
Aug 02 2011
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
Am 02.08.2011, 22:35 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:

 pidgits n = 0 % (0 # (1,0,1)) where
  i%ds
   | i >= n = []
   | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j%t
   where k = i+10; j = min n k
         (h,t) | k > n = (take (n`mod`10) ds ++ replicate (k-n) " ",[])
               | True = splitAt 10 ds
  j # s | n>a || r+n>=d = k # t
      | True = show q : k # (n*10,(a-(q*d))*10,d)
   where k = j+1; t (n,a,d)=k&s; (q,r)=(n*3+a)`divMod`d
  j&(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1)

 main = putStr.pidgits.read.head =<< getArgs

Is this Indonesian cast to ASCII? :p
Aug 02 2011
parent bearophile <bearophileHUGS lycos.com> writes:
Marco Leise:

 Am 02.08.2011, 22:35 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:
 
 pidgits n = 0 % (0 # (1,0,1)) where
  i%ds
   | i >= n = []
   | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j%t
   where k = i+10; j = min n k
         (h,t) | k > n = (take (n`mod`10) ds ++ replicate (k-n) " ",[])
               | True = splitAt 10 ds
  j # s | n>a || r+n>=d = k # t
      | True = show q : k # (n*10,(a-(q*d))*10,d)
   where k = j+1; t (n,a,d)=k&s; (q,r)=(n*3+a)`divMod`d
  j&(n,a,d) = (n*j,(a+n*2)*y,d*y) where y=(j*2+1)

 main = putStr.pidgits.read.head =<< getArgs

Is this Indonesian cast to ASCII? :p

I agree it's very bad looking, it isn't idiomatic Haskell code. But it contains nothing too much strange (and the algorithm is the same used in the D code). This is formatted a bit better, but I don't fully understand it yet: import System (getArgs) pidgits n = 0 % (0 # (1, 0, 1)) where i % ds | i >= n = [] | True = (concat h ++ "\t:" ++ show j ++ "\n") ++ j % t where k = i + 10 j = min n k (h, t) | k > n = (take (n `mod` 10) ds ++ replicate (k - n) " ", []) | True = splitAt 10 ds j # s | n > a || r + n >= d = k # t | True = show q : k # (n * 10, (a - (q * d)) * 10, d) where k = j + 1 t (n, a, d) = k & s (q, r) = (n * 3 + a) `divMod` d j & (n, a, d) = (n * j, (a + n * 2) * y, d * y) where y = (j * 2 + 1) main = putStr . pidgits . read . head =<< getArgs The Shootout site (where I have copied that code) ranks programs for the performance and their compactness (using a low-performance compressor...), so there you see Haskell (and other languages) programs that are sometimes too much compact and often use clever tricks to increase their performance. In normal Haskell code you don't find those tricks (this specific program seems to not use strange tricks, but on the Haskell Wiki page about this problem (http://www.haskell.org/haskellwiki/Shootout/Pidigits ) you see several programs that are both longer and slower than this one). The first working implementation of a C program is probably long and fast enough, while the first working implementation of a Haskell program is often short but not so fast. Usually there are ways to speed up the Haskell code. My experience of Haskell is limited, so usually when I write some Haskell my head hurts a bit :-) The higher level nature of Python allows me to implement working algorithms that are more complex, so sometimes the code ends being faster than C code, where you often avoid (at a first implementation) too much complex algorithms for fear of too much hard to find bugs, or just too much long to write implementation. Haskell in theory allows you to implement complex algorithms in a short space, and safely. In practice I think you need lot of brain to do this. Haskell sometimes looks like a puzzle language to me (maybe I just need more self-training on functional programming). Bye, bearophile
Aug 02 2011
prev sibling next sibling parent reply Jason House <jason.james.house gmail.com> writes:
The post says they did "dmd -O". They did not mention "-inline -noboundscheck
-release". There may be extra flags that are required.

Walter Bright Wrote:

 http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98
 
 Anyone care to examine the assembler output and figure out why?

Aug 02 2011
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/2/2011 5:00 AM, Jason House wrote:
 The post says they did "dmd -O". They did not mention "-inline -noboundscheck
 -release". There may be extra flags that are required.

Often when I see benchmark results like this, I wait to see what the actual problem is before jumping to conclusions. I have a lot of experience with this :-) The results could be any of: 1. wrong flags used (especially by inexperienced users) 2. the benchmark isn't measuring what it purports to be (an example might be it is actually measuring printf or malloc speed, not the generated code) 3. the benchmark is optimized for one particular compiler/language by someone very familiar with that compiler/language and it exploits a particular quirk of it 4. the compiler is hand optimized for a specific benchmark, and the great results disappear if anything in the source code changes (yes, this is dirty, and I've seen it done by big name compilers) 5. the different benchmarks are run on different computers 6. the memory layout could wind up arbitrarily different for the different compilers/languages, resulting in different performance due to memory caching etc.
Aug 02 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Aug 2, 11 20:00, Jason House wrote:
 The post says they did "dmd -O". They did not mention "-inline -noboundscheck
-release". There may be extra flags that are required.

 Walter Bright Wrote:

 http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98

 Anyone care to examine the assembler output and figure out why?


Let dmd have an '-O9999' flag to as a synonym of '-O -inline -noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke]
Aug 02 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On the flags: I did use them, but didn't write it all out and
tried to make them irrelevant (by avoiding functions and arrays).

But, if the same ones are passed to each compiler, it shouldn't
matter anyway... the idea is to get an apples to apples comparison
between the two D implementations, not to chase after a number itself.
Aug 02 2011
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from KennyTM~ (kennytm gmail.com)'s article
 On Aug 2, 11 20:00, Jason House wrote:
 The post says they did "dmd -O". They did not mention "-inline -noboundscheck


 Walter Bright Wrote:

 http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98

 Anyone care to examine the assembler output and figure out why?


-noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke]

-Ofast sounds better. ;)
Aug 02 2011
parent simendsjo <simendsjo gmail.com> writes:
On 02.08.2011 22:36, Andrew Wiley wrote:
 On Tue, Aug 2, 2011 at 1:31 PM, Iain Buclaw <ibuclaw ubuntu.com
 <mailto:ibuclaw ubuntu.com>> wrote:

     == Quote from KennyTM~ (kennytm gmail.com
     <mailto:kennytm gmail.com>)'s article
      > On Aug 2, 11 20:00, Jason House wrote:
      > > The post says they did "dmd -O". They did not mention "-inline
     -noboundscheck
     -release". There may be extra flags that are required.
      > >
      > > Walter Bright Wrote:
      > >
      > >>
     http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98
      > >>
      > >> Anyone care to examine the assembler output and figure out why?
      > >
      > Let dmd have an '-O9999' flag to as a synonym of '-O -inline
      > -noboundscheck -release' so people won't miss the extra flags in
      > benchmarks. [/joke]


 -O9001 will make the Redditors happy.


     -Ofast sounds better. ;)

How about replacing -w with -9001? http://en.wikipedia.org/wiki/ISO_9001#Contents_of_ISO_9001
Aug 02 2011
prev sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e6d433ac92417f04a98bb344
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Aug 2, 2011 at 1:31 PM, Iain Buclaw <ibuclaw ubuntu.com> wrote:

 == Quote from KennyTM~ (kennytm gmail.com)'s article
 On Aug 2, 11 20:00, Jason House wrote:
 The post says they did "dmd -O". They did not mention "-inline


-release". There may be extra flags that are required.
 Walter Bright Wrote:




 Anyone care to examine the assembler output and figure out why?


-noboundscheck -release' so people won't miss the extra flags in benchmarks. [/joke]


-O9001 will make the Redditors happy.
 -Ofast sounds better. ;)

--0016e6d433ac92417f04a98bb344 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Tue, Aug 2, 2011 at 1:31 PM, Iain Buclaw <spa= n dir=3D"ltr">&lt;<a href=3D"mailto:ibuclaw ubuntu.com">ibuclaw ubuntu.com<= /a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:= 0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> =3D=3D Quote from KennyTM~ (<a href=3D"mailto:kennytm gmail.com">kennytm gm= ail.com</a>)&#39;s article<br> <div><div></div><div class=3D"h5">&gt; On Aug 2, 11 20:00, Jason House wrot= e:<br> &gt; &gt; The post says they did &quot;dmd -O&quot;. They did not mention &= quot;-inline -noboundscheck<br> -release&quot;. There may be extra flags that are required.<br> &gt; &gt;<br> &gt; &gt; Walter Bright Wrote:<br> &gt; &gt;<br> &gt; &gt;&gt; <a href=3D"http://www.reddit.com/r/programming/comments/j48tf= /how_is_c_better_than_d/c29do98" target=3D"_blank">http://www.reddit.com/r/= programming/comments/j48tf/how_is_c_better_than_d/c29do98</a><br> &gt; &gt;&gt;<br> &gt; &gt;&gt; Anyone care to examine the assembler output and figure out wh= y?<br> &gt; &gt;<br> &gt; Let dmd have an &#39;-O9999&#39; flag to as a synonym of &#39;-O -inli= ne<br> &gt; -noboundscheck -release&#39; so people won&#39;t miss the extra flags = in<br> &gt; benchmarks. [/joke]<br></div></div></blockquote><div><br></div><div>-O= 9001 will make the Redditors happy.=A0</div><blockquote class=3D"gmail_quot= e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=

<div><div class=3D"h5"> <br> </div></div>-Ofast sounds better. ;)<br> </blockquote></div><br> --0016e6d433ac92417f04a98bb344--
Aug 02 2011
prev sibling parent reply Robert Clipsham <robert octarineparrot.com> writes:
On 02/08/2011 00:40, Walter Bright wrote:
 http://www.reddit.com/r/programming/comments/j48tf/how_is_c_better_than_d/c29do98


 Anyone care to examine the assembler output and figure out why?

I was talking to David Nadlinger the other day, and there was some sort of codegen bug causing things to massively outperform dmd and clang with equivalent code - it's possible this is the cause, I don't know without looking though. He may be able to shed some light on it. -- Robert http://octarineparrot.com/
Aug 02 2011
parent David Nadlinger <see klickverbot.at> writes:
On 8/2/11 7:34 PM, Robert Clipsham wrote:
 On 02/08/2011 00:40, Walter Bright wrote:
 Anyone care to examine the assembler output and figure out why?

I was talking to David Nadlinger the other day, and there was some sort of codegen bug causing things to massively outperform dmd and clang with equivalent code - it's possible this is the cause, I don't know without looking though. He may be able to shed some light on it.

Nope, this turned out to be a bug in my program, where some memory chunk used as test input data was prematurely garbage collected (that only surfaced with aggressive compiler optimizations, which is why I suspected a compiler bug). David
Aug 02 2011