<div dir="ltr"><p>On Oct 29, 2013 7:36 AM, "Iain Buclaw" <<a href="mailto:ibuclaw@ubuntu.com" target="_blank">ibuclaw@ubuntu.com</a>> wrote:<br>
><br>
><br>
> On Oct 29, 2013 7:16 AM, "Joseph Rushton Wakeling" <<a href="mailto:joseph.wakeling@webdrake.net" target="_blank">joseph.wakeling@webdrake.net</a>> wrote:<br>
> ><br>
> > On 28/10/13 20:02, Iain Buclaw wrote:<br>
> >><br>
> >> I don't see it that way.  Up until now at least I haven't seen<br>
> >> anything they do that wasn't already do-able in GCC.<br>
> ><br>
> ><br>
> > I confess I may be biased here because recently I've been finding that D code compiled with LDC seems to typically run faster than stuff compiled with GDC -- particularly code which makes any kind of serious use of stuff from std.algorithm or any other strongly generic parts of the language.<br>


> ><br>
> > I can't imagine there are any fundamental frontend glue-code differences that are responsible for that, so I was assuming LLVM had a few areas where its optimizations worked better than the GCC middle/backend for various language constructs.<br>


> ><br>
> > I did test just now making sure that I used GDC with -march=native just in case that was the issue, but there's still a performance gap.  The only other guess I have -- and it's a complete guess -- could it be inline-assembly related, that LDC gains a little here?<br>


><br>
> Inline assembler for dynamic array vector operations does improve speed by 20% over the generic loop that GDC uses (for small arrays at least).<br>
></p>
<p>Speaking of arrays, GDC up until recently allocated memory for every single [array, literal] in D code. This would give a noticeable slowdown in such code too.</p>
<p>Regards<br>
-- <br>
Iain Buclaw</p>
<p>*(p < e ? p++ : p) = (c & 0x0f) + '0';<br>
</p>
</div>