On 2013-10-23 00:42, David Nadlinger wrote:
> LDC 0.12.0, the LLVM-based D compiler, is available for download! It is
> built on the 2.063.2 frontend and standard library and supports LLVM
> 3.1-3.3 (OS X: 3.2 only).

I noticed that Apple's releases of Clang is still at 3.2.

-- 
/Jacob Carlborg

On Friday, 25 October 2013 at 07:50:36 UTC, ilya-stromberg wrote:
> I think it's answer for your question. For example, Clang (LLVM C) is fastest, LDC (LLVM D) has 2-nd place, but LLVM-GHC (LLVM Haskell) ~ 2 times slower.

The explanation is quite simple. LLVM understand C and C++ runtime. It doesn't understand D runtime (LDC is doing some work in that regard, but it is still limited). So you see a difference between C and C++ as some optimization will be done in C/C++ (for instance heap to stack promotion) when it won't be done in D.

Haskell has really different semantic than C and C++, and quite far away from the hardware, so you have to expect a performance drop. The comparison of either C or C++ with haskell is not really meaningful as it is really comparing apple and bananas.

On 10/25/2013 03:50 AM, ilya-stromberg wrote:
>
> It depends.
> Two benchmarks of different languages and compilers:
> http://togototo.wordpress.com/2013/07/23/benchmarking-level-generation-go-rust-haskell-and-d/
>
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
>
>
> I think it's answer for your question. For example, Clang (LLVM C) is
> fastest, LDC (LLVM D) has 2-nd place, but LLVM-GHC (LLVM Haskell) ~ 2
> times slower.

Yes, that answers my question. Thanks for those great links!
It's impressive the LDC is as fast as Clang!!

On Saturday, 26 October 2013 at 02:21:37 UTC, deadalnix wrote:
> The explanation is quite simple. LLVM understand C and C++ runtime. It doesn't understand D runtime (LDC is doing some work in that regard, but it is still limited). So you see a difference between C and C++ as some optimization will be done in C/C++ (for instance heap to stack promotion) when it won't be done in D.

While this is true in general I don't think that it explains the difference in the mentioned benchmark. A PRNG does not use too much of the C runtime.

I believe that the IR generated by LDC could be improved and that the difference in speed is caused by this.

Regards
Kai

On 10/25/2013 03:50 AM, ilya-stromberg wrote:
>
> It depends.
> Two benchmarks of different languages and compilers:
> http://togototo.wordpress.com/2013/07/23/benchmarking-level-generation-go-rust-haskell-and-d/
>
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
>
>
> I think it's answer for your question. For example, Clang (LLVM C) is
> fastest, LDC (LLVM D) has 2-nd place, but LLVM-GHC (LLVM Haskell) ~ 2
> times slower.


They also show non-llvm compilers like D in that chart for compassion.

I wonder where would C# stand if it's added to that list.
I wouldn't like it if it performs any better than LDC though! ;-)

On 10/25/2013 03:50 AM, ilya-stromberg wrote:

> It depends.
> Two benchmarks of different languages and compilers:
> http://togototo.wordpress.com/2013/07/23/benchmarking-level-generation-go-rust-haskell-and-d/
>
> http://togototo.wordpress.com/2013/08/23/benchmarks-round-two-parallel-go-rust-d-scala-and-nimrod/
>
>
> I think it's answer for your question. For example, Clang (LLVM C) is
> fastest, LDC (LLVM D) has 2-nd place, but LLVM-GHC (LLVM Haskell) ~ 2
> times slower.


They also show non-llvm compilers like DMD in that chart, for comparison.

I wonder where would C# stand if it's added to the list.
I wouldn't like it if it performs any better than LDC though! ;-)

Am Sat, 26 Oct 2013 04:21:26 +0200
schrieb "deadalnix" <deadalnix@gmail.com>:

> On Friday, 25 October 2013 at 07:50:36 UTC, ilya-stromberg wrote:
> > I think it's answer for your question. For example, Clang (LLVM C) is fastest, LDC (LLVM D) has 2-nd place, but LLVM-GHC (LLVM Haskell) ~ 2 times slower.
> 
> The explanation is quite simple. LLVM understand C and C++ runtime. It doesn't understand D runtime (LDC is doing some work in that regard, but it is still limited). So you see a difference between C and C++ as some optimization will be done in C/C++ (for instance heap to stack promotion) when it won't be done in D.

Some observations:
The posted level creation benchmark contains no dynamic memory
allocation and no runtime calls in the critical loop. As such
you won't lose performance due to missing compiler intrinsics
or the GC here and the runtime difference between the D and
the C version is minimal (< 0.5% in fact).

Yet I've altered it a bit to gain another 10% for the D version (without changing the algorithm): https://github.com/mleise/levgen-benchmarks/blob/master/D.d

Now D is the fastest again and we are all happy :)

-- 
Marco

Am Sat, 26 Oct 2013 18:34:55 +0200
schrieb "Kai Nacke" <kai@redstar.de>:

> On Saturday, 26 October 2013 at 02:21:37 UTC, deadalnix wrote:
> > The explanation is quite simple. LLVM understand C and C++ runtime. It doesn't understand D runtime (LDC is doing some work in that regard, but it is still limited). So you see a difference between C and C++ as some optimization will be done in C/C++ (for instance heap to stack promotion) when it won't be done in D.
> 
> While this is true in general I don't think that it explains the difference in the mentioned benchmark. A PRNG does not use too much of the C runtime.

And at a closer look, the author replaced calls to the C PRNG with a simple XorShift engine included in the source code to level the field between the languages. 60% of the runtime is spent checking for collisions between rectangles.

> I believe that the IR generated by LDC could be improved and that the difference in speed is caused by this.

If the author had applied correct rounding both Clang and LDC would have had 100%. I assume the 1 ms (< 0.5%) difference stems from the startup time of D or maybe for C he timed the code internally and for D he used "time"; but it is really insignificant in relative numbers.

> Regards
> Kai

-- 
Marco