On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
> After changing the benchmark to more carefully measure the integration function (ldc was unfairly taking advantage of knowing a and b at compile-time), scala does indeed win by a small margin.
>
> I wonder what it's managing to achieve here? AFAICT there really isn't much scope for optimisation in that while loop without breaking IEEE-754 guarantees.

Maybe scala takes the same advantage?

On Monday, 8 December 2014 at 12:09:20 UTC, Kagamin wrote:
> On Monday, 8 December 2014 at 10:31:46 UTC, John Colvin wrote:
>> After changing the benchmark to more carefully measure the integration function (ldc was unfairly taking advantage of knowing a and b at compile-time), scala does indeed win by a small margin.
>>
>> I wonder what it's managing to achieve here? AFAICT there really isn't much scope for optimisation in that while loop without breaking IEEE-754 guarantees.
>
> Maybe scala takes the same advantage?

Perhaps it did, but the technique used to force ldc not to (randomly generating `a` on entry to timeIt) should also apply to scala.

On Mon, Dec 08, 2014 at 08:33:16AM +0000, Russel Winder via Digitalmars-d wrote: [...]
> As with any of these situation the convoluted hardcoded for a specific processor code, especially assembly language will always win. I don't care about that, I care about the fastest comprehensible code that is portable simply by compilation or execution. Based on this, Java does well, so does some Groovy perhaps surprisingly, also Scala.  C++ does well especially with TBB (though as an API it leaves a lot to be desired). D is OK but only using ldc2 or gdc, dmd sucks.
[...]

Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available.


T

-- 
INTEL = Only half of "intelligence".

On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote: […]
> Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available.

GDC is tied to the GCC release program I guess, so gdc can only be updated when there is a new GCC release.

I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, so I tend to use that by default to get something fast that is more or less up-to-date with DMD.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 09 Dec 2014 11:09:44 +0000
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote: […]
> > Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available.
> 
> GDC is tied to the GCC release program I guess
nope. it's just lack of developers.

> I am not up to compiling gdc from source, but compiling ldc2 is very straightforward,
to the extent that i can't build git head. ;-)

On Tue, 2014-12-09 at 13:22 +0200, ketmar via Digitalmars-d wrote:
> On Tue, 09 Dec 2014 11:09:44 +0000
> Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
[…]
> > GDC is tied to the GCC release program I guess
> nope. it's just lack of developers.

Too much effort expended on DMD I guess ;-)

> > I am not up to compiling gdc from source, but compiling ldc2 is very straightforward,
> to the extent that i can't build git head. ;-)

Works fine for me, I just built it 15 mins ago.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On Tue, 09 Dec 2014 11:34:34 +0000
Russel Winder via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> > > I am not up to compiling gdc from source, but compiling ldc2 is very straightforward,
> > to the extent that i can't build git head. ;-)
> 
> Works fine for me, I just built it 15 mins ago.

to be honest i tried that month or two ago. it failed somewhere in the middle with some error message and i deleted it.

On Tue, Dec 09, 2014 at 11:09:44AM +0000, Russel Winder via Digitalmars-d wrote:
> On Mon, 2014-12-08 at 07:18 -0800, H. S. Teoh via Digitalmars-d wrote: […]
> > Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code. The downside is that gdc usually lags behind dmd by one release, which, given the current rate of development in D, can be quite a big difference in feature set available.
> 
> GDC is tied to the GCC release program I guess, so gdc can only be updated when there is a new GCC release.
> 
> I am not up to compiling gdc from source, but compiling ldc2 is very straightforward, so I tend to use that by default to get something fast that is more or less up-to-date with DMD.
[...]

I used to compile gdc from source, but unfortunately, the gcc build scripts are so very temperamental and sensitive... the slightest environment variable set wrong in your system, and you're up for unending hours of hair-pulling frustration trying to figure out what went wrong given only an error message that almost always has nothing whatsoever to do with the real problem, which has already happened half an hour earlier. This is especially so if you attempt to build with a gcc version that isn't the latest development version, which is inevitably incompatible with my current system's gcc version, which means I have to install it in a custom path, which is often a source of trouble because anytime you change the default settings, you've to be prepared for lots of things exploding in your face unless you know exactly what you're doing (and I don't).


T

-- 
You have to expect the unexpected. -- RL

08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
> On Mon, Dec 08, 2014 at 08:33:16AM +0000, Russel Winder via Digitalmars-d wrote:
> [...]
>> As with any of these situation the convoluted hardcoded for a specific
>> processor code, especially assembly language will always win. I don't
>> care about that, I care about the fastest comprehensible code that is
>> portable simply by compilation or execution. Based on this, Java does
>> well, so does some Groovy perhaps surprisingly, also Scala.  C++ does
>> well especially with TBB (though as an API it leaves a lot to be
>> desired). D is OK but only using ldc2 or gdc, dmd sucks.
> [...]
>
> Yeah, I find in my own experience that gdc -O3 tends to produce code
> that's consistently ~20% faster than dmd -O, especially in
> compute-intensive code.

And that's not nearly enough. Also both LDC & GDC often can't inline many functions from phobos due to separate compilation.

> The downside is that gdc usually lags behind dmd
> by one release, which, given the current rate of development in D, can
> be quite a big difference in feature set available.
>


-- 
Dmitry Olshansky

On Tue, Dec 09, 2014 at 07:16:56PM +0300, Dmitry Olshansky via Digitalmars-d wrote:
> 08-Dec-2014 18:18, H. S. Teoh via Digitalmars-d пишет:
> >On Mon, Dec 08, 2014 at 08:33:16AM +0000, Russel Winder via Digitalmars-d wrote: [...]
> >>As with any of these situation the convoluted hardcoded for a specific processor code, especially assembly language will always win. I don't care about that, I care about the fastest comprehensible code that is portable simply by compilation or execution. Based on this, Java does well, so does some Groovy perhaps surprisingly, also Scala.  C++ does well especially with TBB (though as an API it leaves a lot to be desired). D is OK but only using ldc2 or gdc, dmd sucks.
> >[...]
> >
> >Yeah, I find in my own experience that gdc -O3 tends to produce code that's consistently ~20% faster than dmd -O, especially in compute-intensive code.
> 
> And that's not nearly enough. Also both LDC & GDC often can't inline many functions from phobos due to separate compilation.
[...]

Really? Most of the Phobos function I use are templates, so inlining shouldn't be a problem, should it? Besides, gdc is far better at inlining that dmd ever was, though of course there are some constructs that the front-end doesn't inline, and the backend doesn't have enough info to do so. This is an area that should be improved.


T

-- 
Fact is stranger than fiction.