Dear Community,

I've prepared a valentine for you;)
It's a project I've been working for the last few months in my free time.

DigitalWhip is a performance benchmark of statically typed programming languages that
compile to native code: https://github.com/artemalive/DigitalWhip

D is fast;)

Thanks,
Artem

On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote:
>
> DigitalWhip is a performance benchmark of statically typed programming languages that
> compile to native code: https://github.com/artemalive/DigitalWhip

Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it)

On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote:
> On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote:
>>
>> DigitalWhip is a performance benchmark of statically typed programming languages that
>> compile to native code: https://github.com/artemalive/DigitalWhip
>
> Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it)

These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2.

Hi Artem,

On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote:
> https://github.com/artemalive/DigitalWhip

Your scripts had bounds checking enabled for LDC but not the other two D compilers. I posted a pull request with the fix. LDC isn't unreasonably slow any longer on a random EC2 box I used for a quick test:

---
Compiler relative times:
clang 1.00
gcc   1.02
ldc   1.07
dmd   2.07
---

 — David

On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote:
> Your scripts had bounds checking enabled for LDC but not the other two D compilers.

I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. Specific parts of the code might disable it via `.ptr`, but the command line switch is dangerous and I can't recommend anyone to use it... ever.

We should run benchmarks with bounds checking enabled to better reflect real world results. Yes, it might "lose" to C, but we'll be the ones laughing when the C program crashes with yet another buffer overrun or when it's milliseconds in execution time lead to days of debug time and a multi-million dollar business loss when an unchecked pointer leads to a security breech.

On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote:
> Dear Community,
>
> I've prepared a valentine for you;)
> It's a project I've been working for the last few months in my free time.
>
> DigitalWhip is a performance benchmark of statically typed programming languages that
> compile to native code: https://github.com/artemalive/DigitalWhip
>
> D is fast;)
>
> Thanks,
> Artem

latest LDC beta + -singleobj flag puts LDC back into a competitive spot.


Compiler relative times:
gcc   1.00
ldc   1.10

btw,

LDC beta sped up the ray intersection by 100%+, wonder what commit caused that.

On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote:
> Hi Artem,
>
> On Saturday, 13 February 2016 at 18:48:12 UTC, artemalive wrote:
>> https://github.com/artemalive/DigitalWhip
>
> Your scripts had bounds checking enabled for LDC but not the other two D compilers. I posted a pull request with the fix. LDC isn't unreasonably slow any longer on a random EC2 box I used for a quick test:
>
> ---
> Compiler relative times:
> clang 1.00
> gcc   1.02
> ldc   1.07
> dmd   2.07
> ---
>
>  — David

Hi David,

I use -release option. It seems no need to disable bounds check explicitly.

From ldc output:
"-release - Disables asserts, invariants, contracts and boundscheck".

-singleobj really does the magic. I'll commit only this option. Thanks for the suggestion and for the pull request. It's my first pull request;)

On Saturday, 13 February 2016 at 21:10:11 UTC, Adam D. Ruppe wrote:
> On Saturday, 13 February 2016 at 20:45:41 UTC, David Nadlinger wrote:
>> Your scripts had bounds checking enabled for LDC but not the other two D compilers.
>
> I strongly recommend people to always keep bounds checking enabled in real world programs because it is so useful in keeping programs sane. Specific parts of the code might disable it via `.ptr`, but the command line switch is dangerous and I can't recommend anyone to use it... ever.
>
> We should run benchmarks with bounds checking enabled to better reflect real world results. Yes, it might "lose" to C, but we'll be the ones laughing when the C program crashes with yet another buffer overrun or when it's milliseconds in execution time lead to days of debug time and a multi-million dollar business loss when an unchecked pointer leads to a security breech.

Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before.

Nevertheless, I have to admit I'm still on the dark side. Benchmark has some algorithms related to raytracing techniques and in this area I can't resist temptation to max performance at any cost.

On Sunday, 14 February 2016 at 17:38:54 UTC, artemalive wrote:
> Hi Adam, I'll check the influence of enabled bounds check on benchmark result. Did not try this before.

If you do, then you should use bounds checks in C++ too. (STL container.at(index) )

On Saturday, 13 February 2016 at 19:26:39 UTC, artemalive wrote:
> On Saturday, 13 February 2016 at 19:19:46 UTC, Johan Engelen wrote:
>>
>> Could you add the compiler versions to the outputted .txt file, e.g. `dmd --version`? (the example output files don't have it)
>
> These files are just for demonstration of expected output. The benchmark should work fine with the latest versions of D compilers. No guarantee for older versions;) I tested with dmd v2.069.2.

What I meant to say is that the framework should output the compiler version, instead of "READY". At least for the D compilers, the performance depends so much on which version is used, that the output is unusable without version numbers, I feel.