Thread overview | |||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 13, 2016 DigitalWhip | ||||
---|---|---|---|---|
| ||||
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 |
February 13, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to artemalive | 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)
|
February 13, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johan Engelen | 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.
|
February 13, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to artemalive | 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
|
February 13, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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.
|
February 13, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to artemalive | 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.
|
February 14, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to David Nadlinger | 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;)
|
February 14, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to Adam D. Ruppe | 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.
|
February 14, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to artemalive | 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) )
|
February 14, 2016 Re: DigitalWhip | ||||
---|---|---|---|---|
| ||||
Posted in reply to artemalive | 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.
|
Copyright © 1999-2021 by the D Language Foundation