Andrei Alexandrescu:

> https://issues.dlang.org/show_bug.cgi?id=13487

If the upload conditions and site are sufficiently good I am willing to offer some implementations in D and to keep them updated. I suggest to add two D versions for some benchmarks, one that shows short high level code, and one that shows longer hairier fast code.

In some cases I'd even like to show a third "safe" version (that tries to be more correct), but most Shootout/ComputerGame benchmarks are not very fit for this (you can see some examples of this on Rosettacode).

Bye,
bearophile

On Wednesday, 17 September 2014 at 06:59:40 UTC, bearophile wrote:
> Andrei Alexandrescu:
>
>> https://issues.dlang.org/show_bug.cgi?id=13487
>
> If the upload conditions and site are sufficiently good I am willing to offer some implementations in D and to keep them updated. I suggest to add two D versions for some benchmarks, one that shows short high level code, and one that shows longer hairier fast code.
>
> In some cases I'd even like to show a third "safe" version (that tries to be more correct), but most Shootout/ComputerGame benchmarks are not very fit for this (you can see some examples of this on Rosettacode).

This is what I intend to do (time permitting)

* Direct translation from the C++ version.
* High-level version using standard library, particularly ranges
(this should be @safe!)
* Low-level hand optimized using core.simd (when applicable).
* CTFE version! (I imagine this will choke on most benchmarks
though...)

Of course, I'll test across dmd, gdc, and ldc2.

Aside from being PR to show the speed of D, hopefully these
benchmarks will serve as test beds for potential optimizations.

If anyone already has translations of the benchmark programs then
please send them to me (or just reply to the bug with an
attachment).

On Wed, 17 Sep 2014 09:57:02 +0000
Peter Alexander via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> * CTFE version! (I imagine this will choke on most benchmarks
> though...)
nope. it's not compile time that measured, it's execution time. so D will tear apart any other language in this benchmarks. what can be faster that just printing the result and exiting, without any calculation?

i'm sure that other languages just can't beat D speed, so they tries to avoid such competition. ;-)

Peter Alexander:

> * Direct translation from the C++ version.
> * High-level version using standard library, particularly ranges
> (this should be @safe!)
> * Low-level hand optimized using core.simd (when applicable).
> * CTFE version! (I imagine this will choke on most benchmarks
> though...)

The safety-conscious version is missing in this list. Just using ranges doesn't suffice.


> If anyone already has translations of the benchmark programs then
> please send them to me (or just reply to the bug with an
> attachment).

I have plenty of D implementations, but keep in mind that D changes, so the various programs will need updates.

Bye,
bearophile

On 9/16/14, 11:59 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> https://issues.dlang.org/show_bug.cgi?id=13487
>
> If the upload conditions and site are sufficiently good I am willing to
> offer some implementations in D and to keep them updated. I suggest to
> add two D versions for some benchmarks, one that shows short high level
> code, and one that shows longer hairier fast code.
>
> In some cases I'd even like to show a third "safe" version (that tries
> to be more correct), but most Shootout/ComputerGame benchmarks are not
> very fit for this (you can see some examples of this on Rosettacode).

I'm glad folks like Alexander, Russel, and yourself are interested in chipping in. Thanks!

Let's do it all on the github repo. Add a directory e.g. tools/benchmarks/ and organize things in there.


Thanks,

Andrei

On 9/17/14, 2:57 AM, Peter Alexander wrote:
> This is what I intend to do (time permitting)
>
> * Direct translation from the C++ version.
> * High-level version using standard library, particularly ranges
> (this should be @safe!)
> * Low-level hand optimized using core.simd (when applicable).
> * CTFE version! (I imagine this will choke on most benchmarks
> though...)
>
> Of course, I'll test across dmd, gdc, and ldc2.
>
> Aside from being PR to show the speed of D, hopefully these
> benchmarks will serve as test beds for potential optimizations.
>
> If anyone already has translations of the benchmark programs then
> please send them to me (or just reply to the bug with an
> attachment).

Awesome. Suggestion in order to leverage crowdsourcing: first focus on setting up the test bed such that adding benchmarks is easy. Then you and others can add a bunch of benchmarks.

Andrei

On Wed, Sep 17, 2014 at 07:46:00AM -0700, Andrei Alexandrescu via Digitalmars-d wrote:
> On 9/16/14, 11:59 PM, bearophile wrote:
> >Andrei Alexandrescu:
> >
> >>https://issues.dlang.org/show_bug.cgi?id=13487
> >
> >If the upload conditions and site are sufficiently good I am willing to offer some implementations in D and to keep them updated. I suggest to add two D versions for some benchmarks, one that shows short high level code, and one that shows longer hairier fast code.
> >
> >In some cases I'd even like to show a third "safe" version (that tries to be more correct), but most Shootout/ComputerGame benchmarks are not very fit for this (you can see some examples of this on Rosettacode).
> 
> I'm glad folks like Alexander, Russel, and yourself are interested in chipping in. Thanks!
> 
> Let's do it all on the github repo. Add a directory e.g. tools/benchmarks/ and organize things in there.
[...]

Excellent move. If it's in github, then more people can contribute. I might contribute as well, if I find the time to do it.


T

-- 
Ignorance is bliss... until you suffer the consequences!

On Wednesday, 17 September 2014 at 14:59:48 UTC, Andrei Alexandrescu wrote:
> Awesome. Suggestion in order to leverage crowdsourcing: first focus on setting up the test bed such that adding benchmarks is easy. Then you and others can add a bunch of benchmarks.

Yep, sounds like a plan.

On Wed, 2014-09-17 at 07:46 -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
> Let's do it all on the github repo. Add a directory e.g. tools/benchmarks/ and organize things in there.

A DVCS repository is clearly the correct infrastructure for this, but perhaps it should be a separate standalone one?

-- 
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 9/17/14, 8:59 AM, Russel Winder via Digitalmars-d wrote:
> On Wed, 2014-09-17 at 07:46 -0700, Andrei Alexandrescu via Digitalmars-d
> wrote:
> […]
>> Let's do it all on the github repo. Add a directory e.g.
>> tools/benchmarks/ and organize things in there.
>
> A DVCS repository is clearly the correct infrastructure for this, but
> perhaps it should be a separate standalone one?

Nothing wrong with starting small and moving later to a larger pond when the need arises. Let's just get this started without worrying too much about minutia. -- Andrei