June 29, 2023
On Thursday, 29 June 2023 at 09:23:53 UTC, Sergey wrote:
> 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)

You are reading behind the lines. I never said that i want to contribute to such benchmarks, but do not know how. Or never asked if author of this becnhmarks accepting PRs (i knew he does).

What I wanted to say is: "do not trust becnhmarks from Sergey user link, because they are not so good". It was the message more to OP, that to you. Benchmarks from you link are lame at least for D language (and not only) and represent in bright light only some big community languages or some hacker individual who polished specific solutions for his language.

Because of that I just provided the link with much better benchmarks (at least for larger part of languages), which actually has benchmarks of ldc and gdc. And which shows that in most cases gdc lags behind (in most cases by not so much, but still does).


June 29, 2023
On Thursday, 29 June 2023 at 10:18:04 UTC, partypooper wrote:
> On Thursday, 29 June 2023 at 09:23:53 UTC, Sergey wrote:
> more to OP, that to you. Benchmarks from you link are lame at least for D language (and not only) and represent in bright light only some big community languages or some hacker individual who polished specific solutions for his language.

The rule of the benchmark is to use the same approach for all languages (sometimes it is not always the case unfortunately), but I definitely can’t see confirmation of your words for this benchmark :) like everyone is free to submit a solution with some restrictions. I haven’t seen any “big community language” superiority there. Moreover it is just the source of some code that can be benchmarked for timing. No matter of different languages.

Kostya’s is good and also much older and mature.

June 29, 2023

On Thursday, 29 June 2023 at 05:23:29 UTC, Cecil Ward wrote:

>

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.

-ffast-math is a good idea until you think about it. This is a good blog post on -ffast-math. There are probably valid use cases for it, but we have high-level languages for a reason.

June 29, 2023

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, have you (or the foundation) ever considered contributing idiomatic DLang solutions to (the more well-known) benchmark sites and linking to them in the DLang intro (= "marketing/funneling") materials?

Using this to showcase DLang might be a boon, particularly if the goal is to market the language to people re. how straightforward it is to write performant code in DLang compared to, say, C/C++/Java/Python/Go/Rust etc.?

I might be overly naïve here, but I honestly see this as an easy way for prospective adopters to check whether DLang actually does what it says on the tin so to speak? Particularly if the the person or set of persons contributing the examples are part of the core dlang set of contributors?

The other bonus is that it will help showcase areas of improvements if said benchmarks are revisited regularly, perhaps even as part of the compiler release test suite(s)?

June 30, 2023

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.

Hey, that's what feenableexcept(FE_ALL_EXCEPT) is for.

#define _GNU_SOURCE

#include <fenv.h>
#include <stdio.h>

void main() {
  printf("infinity = %f\n", 1.0f / 0.0f);
  feenableexcept(FE_ALL_EXCEPT);
  // will crash with a float error.
  printf("infinity = %f\n", 1.0f / 0.0f);
}

(I thought there was a way to make it never generate infinities/nans in the first place, but I can't find it.)

1 2
Next ›   Last »