I just read an interesting article about a benchmark comparison between GDC and LDC. The code being tested did a lot of (32-bit?) integer divisions and unfirtunately LDC rather bent the comparison by using an algorithmic replacement for the x86 idiv instruction which may or may not be preferable depending on the vintage of CPU. It also biases the comparison in favour of the detailed handing if that one single topic.

I wonder if anyone else is interested in doing some more LDC vs GDC comparisons ? With a common benchmark driver if possible.

GDC: -O3 -frelease -mtune=native -march=native
LDC: -O3 -release -boundscheck=off -mcpu=native

If using floating point, then we should add in the fast-math switches - can’t remember the exact details, so perhaps someone would append them?

I would especially like a meat-and-potatoes one that does not depend on maths in tight loops and on the power of loop-specific optimisations. By meat and potatoes I mean: integer arithmetic, lots of test and branches, some memory accesses. Something like parsing or string processing. The maths-oriented ones and floating point are welcome too, and I’d really like to see D 80-bit real tested in a compiler benchmark. Complex numbers in D too.

But most of all, a real-world piece of code, run n times and turned into a benchmark. Run time ought to be > 1 min so as to make sure that timing inaccuracies do not drown the results in noise.

Anyone up for it?

On Monday, 26 June 2023 at 20:22:24 UTC, Cecil Ward wrote:
>
> Anyone up for it?

Hi. Every problem from this set of benchmarks has D solution https://programming-language-benchmarks.vercel.app/
It is open-sourced on GitHub. Currently the benchmark run it with DMD and LDC (it is lacking GDC because some problems with GitHub Actions).

But you can run it locally with very little effort.
For time measurement I can recommend to use hyperfine tool.

Also GDC and LDC have their special things for vectorizations. And maybe Bruce Carneal could share some examples/benchmarks of them.

Be leery of using fastmath switches unless you are very knowledgeable about fp math and how fastmath changes it.

DMD doesn't have a fastmath switch for good reason.

On Tuesday, 27 June 2023 at 19:58:57 UTC, Walter Bright wrote:
> Be leery of using fastmath switches unless you are very knowledgeable about fp math and how fastmath changes it.
>
> DMD doesn't have a fastmath switch for good reason.

Walter, your warning is appreciated. I read some of the GCC documentation, but I’ve no intention of going near the fast math thing in a production program as indeed I haven’t thought it through enough.

Since DMD doesn’t have such a thing, then fast-math needs to be banned in benchmarks that include DMD otherwise it’s not a level playing field.

Isn’t the main thing ignoring infinities and NaNs? I don’t think that’s all there is to it though. I would say, in my extremely limited exposure to floating point, that if you have debugged your code then infinities and NaNs should not be encountered anyway unless you have possible special cases to deal with relating to input that you’re not in control of.

On 6/28/2023 4:29 PM, Cecil Ward wrote:
> Isn’t the main thing ignoring infinities and NaNs? I don’t think that’s all there is to it though. I would say, in my extremely limited exposure to floating point, that 
I forgot precisely what it did, but it takes shortcuts. I just concluded "nope" to that.

> if you have debugged your code then infinities and NaNs should not
> be encountered anyway

Famous last words.

On Thursday, 29 June 2023 at 04:41:54 UTC, Walter Bright wrote:
> On 6/28/2023 4:29 PM, Cecil Ward wrote:
>> Isn’t the main thing ignoring infinities and NaNs? I don’t think that’s all there is to it though. I would say, in my extremely limited exposure to floating point, that
> I forgot precisely what it did, but it takes shortcuts. I just concluded "nope" to that.
>
> > if you have debugged your code then infinities and NaNs
> should not
> > be encountered anyway
>
> Famous last words.

I truly hear you. :-) It rather depends on the particular situation, but then what do I know, seeing as floating point is not my thing at all. I will educate myself if I ever go down that particular road and take on board what you have said.

On Tuesday, 27 June 2023 at 09:31:50 UTC, Sergey wrote:
> On Monday, 26 June 2023 at 20:22:24 UTC, Cecil Ward wrote:
>>
>> Anyone up for it?
>
> Hi. Every problem from this set of benchmarks has D solution https://programming-language-benchmarks.vercel.app/
> It is open-sourced on GitHub. Currently the benchmark run it with DMD and LDC (it is lacking GDC because some problems with GitHub Actions).
>
> But you can run it locally with very little effort.
> For time measurement I can recommend to use hyperfine tool.
>
> Also GDC and LDC have their special things for vectorizations. And maybe Bruce Carneal could share some examples/benchmarks of them.

This benchmarks are not trustworthy. A lot of languages modified by contributors, dlang on the other case are just some meh translations from other languages by the repository author.

There is https://github.com/kostya/benchmarks which has ldc, gdc and dmd results and are more or less provided by the community at least languages like d, rust, zig, c, c++.

On Thursday, 29 June 2023 at 07:47:17 UTC, partypooper wrote:
> On Tuesday, 27 June 2023 at 09:31:50 UTC, Sergey wrote:
> This benchmarks are not trustworthy. A lot of languages modified by contributors, dlang on the other case are just some meh translations from other languages by the repository author.
>
> There is https://github.com/kostya/benchmarks which has ldc, gdc and dmd results and are more or less provided by the community at least languages like d, rust, zig, c, c++.

If you can provide some improvements to solutions - you are welcome :)
Author of the repo is accepting PRs (at least he did it in the past, but recently it seems he doesn't have time to support it)