www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Are these bencmarks recent and real?

reply rempas <rempas tutanota.com> writes:
Just trying to compile a sample basic gtk-d project (including 
the libraries themselves) using ldc2 and optimization "-Os" and 
seeing how much time this takes, I want to ask if the benchmarks 
found [here](https://github.com/nordlow/compiler-benchmark) about 
ldc2 are real. Again seeing the gtk-d project taking so much 
time, It's hard to believe that ldc2 compiles faster that tcc and 
go. However, this test probably doesn't use optimizations but 
still.... Ayn thoughts?
Aug 30 2021
next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project (including 
 the libraries themselves) using ldc2 and optimization "-Os" and 
 seeing how much time this takes, I want to ask if the 
 benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that tcc 
 and go. However, this test probably doesn't use optimizations 
 but still.... Ayn thoughts?


You can see how recent they are, and yeah they're real, but it's 
a very specific artificial benchmark and there's a lot more to 
say about compilation speeds about the various languages. That D 
can compile amazingly fast can be shown just by building dmd 
itself. But unlike go, D also gives you a bunch of tools that you 
can use to make compile times take a lot longer. Likewise you 
could say that D can make just as careful use of memory as a C 
program, but that D unlike C also gives you a bunch of tools that 
you can put towards much less careful use of memory.
Aug 30 2021
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 31/08/2021 3:34 AM, jfondren wrote:

 That D can compile amazingly fast can be shown just by building dmd itself.


"Oh let me recompile dmd" - Stefan

A little gag from this BeerConf and yeah, it builds fast.
Aug 30 2021
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/30/21 8:46 AM, rikki cattermole wrote:

 
 On 31/08/2021 3:34 AM, jfondren wrote:

 That D can compile amazingly fast can be shown just by building dmd 
 itself.


 
 "Oh let me recompile dmd" - Stefan
 
 A little gag from this BeerConf and yeah, it builds fast.


The following program takes 10 seconds on my computer. How is that fast? :p

import std.range;
import std.algorithm;

int main() {
   enum ret = 4_000_000.iota.sum;
   // pragma(msg, ret);
   return ret ^ ret;
}

(Of course I am joking: Replacing 'enum' with e.g. 'const' makes it fast.)

However, TIL: pragma(msg) works with 'const' variables! (At least with 
that one.) Replace 'enum' with 'const' and pragma(msg) computes it at 
compile time. But... but... 'const' doesn't really mean compile-time... 
Is that intended? There is some semantic confusion there. :/

Ali
Aug 30 2021
next sibling parent rempas <rempas tutanota.com> writes:
On Monday, 30 August 2021 at 17:15:00 UTC, Ali Çehreli wrote:

 On 8/30/21 8:46 AM, rikki cattermole wrote:

 The following program takes 10 seconds on my computer. How is 
 that fast? :p

 import std.range;
 import std.algorithm;

 int main() {
   enum ret = 4_000_000.iota.sum;
   // pragma(msg, ret);
   return ret ^ ret;
 }

 (Of course I am joking: Replacing 'enum' with e.g. 'const' 
 makes it fast.)

 However, TIL: pragma(msg) works with 'const' variables! (At 
 least with that one.) Replace 'enum' with 'const' and 
 pragma(msg) computes it at compile time. But... but... 'const' 
 doesn't really mean compile-time... Is that intended? There is 
 some semantic confusion there. :/

 Ali


Yep! There is and I hope things would be more clear. Your book 
helps tho ;)
Aug 30 2021
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/30/21 1:15 PM, Ali Çehreli wrote:

 On 8/30/21 8:46 AM, rikki cattermole wrote:

 On 31/08/2021 3:34 AM, jfondren wrote:

 That D can compile amazingly fast can be shown just by building dmd 
 itself.


 "Oh let me recompile dmd" - Stefan

 A little gag from this BeerConf and yeah, it builds fast.


 
 The following program takes 10 seconds on my computer. How is that fast? :p
 
 import std.range;
 import std.algorithm;
 
 int main() {
    enum ret = 4_000_000.iota.sum;
    // pragma(msg, ret);
    return ret ^ ret;
 }
 
 (Of course I am joking: Replacing 'enum' with e.g. 'const' makes it fast.)
 
 However, TIL: pragma(msg) works with 'const' variables! (At least with 
 that one.) Replace 'enum' with 'const' and pragma(msg) computes it at 
 compile time. But... but... 'const' doesn't really mean compile-time... 
 Is that intended? There is some semantic confusion there. :/


initializers *sometimes* can be computed at compile time. If assigned to 
a const or immutable variable, the compiler is smart enough to know that 
the item hasn't changed, and so it can go back to the static initializer 
for what the value actually is.

what is happening here:

`enum ret = 4_000_000.iota.sum;`

In this case, you are requesting a compile time constant, and so it runs 
CTFE here to generate the result.

`const ret = 4_000_000.iota.sum;`

In this case, since this is inside a function, and not assiged to a 
global or static variable, it is generated at runtime.

`pragma(msg, ret);`

However, here we are requesting the value of `ret` at compile time. The 
compiler knows that since it's const, it should have the value it's 
initialized with. So it runs the *initializer* expression 
`4_000_000.iota.sum` at compile-time, and now it has access to the 
value. So actually, the CTFE engine runs here instead of at `ret`'s 
initialization.

If a const variable depended on an expression that could only be 
computed at runtime (like say with the value of an input parameter), 
then the `pragma(msg)` would NOT work.

-Steve
Aug 31 2021
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 8/31/21 8:09 AM, Steven Schveighoffer wrote:


 `const ret = 4_000_000.iota.sum;`

 In this case, since this is inside a function, and not assiged to a
 global or static variable, it is generated at runtime.

 `pragma(msg, ret);`

 However, here we are requesting the value of `ret` at compile time. The
 compiler knows that since it's const, it should have the value it's
 initialized with.


[I change my understanding at the end of this post.]

But 'const' is not 'static const'. pragma(msg) is being extra helpful by 
hoping for the availability of the value. (To me, 'const' means "I 
promise I will not mutate", which has no relation to compile-time 
availability.)


 So it runs the *initializer* expression
 `4_000_000.iota.sum` at compile-time, and now it has access to the
 value. So actually, the CTFE engine runs here instead of at `ret`'s
 initialization.


It makes sense but there are two minor disturbances:

1) This is an example of "It went better than I expected".

2) Success is determined by trying.

The following program fails compilation when it gets to 'args.length' 
after 10 second of compilation:

import std.range;
import std.algorithm;

void main(string[] args) {
   const ret = 4_000_000.iota.sum + args.length;
   pragma(msg, ret);
}

Well, nothing is *wrong* here but concepts are muddled. But then I even 
more TIL that this is the same for templates:

void foo(int i)() {
}

void main() {
   const i = 42;
   foo!i();    // Compiles
}

You know... Now it feels I knew it all along because CTFE is about 
expressions, not variables. I need not have a "compile-time variable". 
Makes sense now. :)

Ali
Aug 31 2021
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/31/21 11:44 AM, Ali Çehreli wrote:

 On 8/31/21 8:09 AM, Steven Schveighoffer wrote:
 
  > `const ret = 4_000_000.iota.sum;`
  >
  > In this case, since this is inside a function, and not assiged to a
  > global or static variable, it is generated at runtime.
  >
  > `pragma(msg, ret);`
  >
  > However, here we are requesting the value of `ret` at compile time. The
  > compiler knows that since it's const, it should have the value it's
  > initialized with.
 
 [I change my understanding at the end of this post.]
 
 But 'const' is not 'static const'. pragma(msg) is being extra helpful by 
 hoping for the availability of the value. (To me, 'const' means "I 
 promise I will not mutate", which has no relation to compile-time 
 availability.)


What `static const` does is require the execution of the expression at 
compile time. Why? Because it needs to put that value into the data 
segment for the linker to use.

The compiler isn't going to do CTFE unless it *has to*. Because CTFE is 
expensive. This is why the cases where CTFE is done are explicit. But 
whether CTFE will work or not depends on whether the code you are 
executing at compile time can be executed at compile time. And that 
isn't decided until the expression is run.


 
  > So it runs the *initializer* expression
  > `4_000_000.iota.sum` at compile-time, and now it has access to the
  > value. So actually, the CTFE engine runs here instead of at `ret`'s
  > initialization.
 
 It makes sense but there are two minor disturbances:
 
 1) This is an example of "It went better than I expected".
 
 2) Success is determined by trying.
 
 The following program fails compilation when it gets to 'args.length' 
 after 10 second of compilation:
 
 import std.range;
 import std.algorithm;
 
 void main(string[] args) {
    const ret = 4_000_000.iota.sum + args.length;
    pragma(msg, ret);
 }
 


Which actually makes sense :)

CTFE is handed an expression, which is essentially an AST branch that it 
needs to execute. It executes it until it can't, and then gives you the 
error. A CTFE error is like a runtime error, except the "runtime" is 
"compile time".


 Well, nothing is *wrong* here but concepts are muddled. But then I even 
 more TIL that this is the same for templates:
 
 void foo(int i)() {
 }
 
 void main() {
    const i = 42;
    foo!i();    // Compiles
 }
 
 You know... Now it feels I knew it all along because CTFE is about 
 expressions, not variables. I need not have a "compile-time variable". 
 Makes sense now. :)


CTFE to me is taking the parsed tree and executing it. But only when it 
needs to. The only odd magic part here is, it can "See through" the 
variable to how it was calculated.

-Steve
Aug 31 2021
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 31 August 2021 at 15:09:11 UTC, Steven Schveighoffer 
wrote:

 On 8/30/21 1:15 PM, Ali Çehreli wrote:

 [...]


 initializers *sometimes* can be computed at compile time. If 
 assigned to a const or immutable variable, the compiler is 
 smart enough to know that the item hasn't changed, and so it 
 can go back to the static initializer for what the value 
 actually is.

 [...]


"Someone" "should" make a D cheat sheet! Like some best 
practices, tips n tricks to stay healthy in the D universe
Sep 02 2021
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Sep 02, 2021 at 07:42:19PM +0000, Imperatorn via Digitalmars-d wrote:

 On Tuesday, 31 August 2021 at 15:09:11 UTC, Steven Schveighoffer wrote:

 On 8/30/21 1:15 PM, Ali Çehreli wrote:

 [...]


 
 initializers *sometimes* can be computed at compile time. If assigned to
 a const or immutable variable, the compiler is smart enough to know that
 the item hasn't changed, and so it can go back to the static initializer
 for what the value actually is.
 
 [...]


 
 "Someone" "should" make a D cheat sheet! Like some best practices, tips n
 tricks to stay healthy in the D universe


Well, there's this: https://p0nce.github.io/d-idioms/

But it may be somewhat outdated now.


T

-- 
Why did the mathematician reinvent the square wheel?  Because he wanted to
drive smoothly over an inverted catenary road.
Sep 02 2021
prev sibling next sibling parent rempas <rempas tutanota.com> writes:
On Monday, 30 August 2021 at 15:34:13 UTC, jfondren wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project (including 
 the libraries themselves) using ldc2 and optimization "-Os" 
 and seeing how much time this takes, I want to ask if the 
 benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that tcc 
 and go. However, this test probably doesn't use optimizations 
 but still.... Ayn thoughts?


 You can see how recent they are, and yeah they're real, but 
 it's a very specific artificial benchmark and there's a lot 
 more to say about compilation speeds about the various 
 languages. That D can compile amazingly fast can be shown just 
 by building dmd itself. But unlike go, D also gives you a bunch 
 of tools that you can use to make compile times take a lot 
 longer. Likewise you could say that D can make just as careful 
 use of memory as a C program, but that D unlike C also gives 
 you a bunch of tools that you can put towards much less careful 
 use of memory.


Yeah I checked the last commit which was 11 July so yeah they are 
very resent. My only complain about D's memory management is that 
the Garbage collector is used in the Phobos so I cannot mark my 
whole project with ` nogc`. I think the library is a specific 
thing and probably we could get away doing manual memory 
management and also being bug-free but I don't take it on me. I 
may be wrong
Aug 30 2021
prev sibling parent reply Chris Katko <ckatko gmail.com> writes:
On Monday, 30 August 2021 at 15:34:13 UTC, jfondren wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project (including 
 the libraries themselves) using ldc2 and optimization "-Os" 
 and seeing how much time this takes, I want to ask if the 
 benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that tcc 
 and go. However, this test probably doesn't use optimizations 
 but still.... Ayn thoughts?


 You can see how recent they are, and yeah they're real, but 
 it's a very specific artificial benchmark and there's a lot 
 more to say about compilation speeds about the various 
 languages. That D can compile amazingly fast can be shown just 
 by building dmd itself. But unlike go, D also gives you a bunch 
 of tools that you can use to make compile times take a lot 
 longer. Likewise you could say that D can make just as careful 
 use of memory as a C program, but that D unlike C also gives 
 you a bunch of tools that you can put towards much less careful 
 use of memory.


One definite flaw I've had with D's ecosystem, is these issues 
aren't made CLEAR. Like if you dare import regex and use a single 
regex match, your compile time explodes by 10-15 seconds on my i3 
chromebook (from ~3 seconds to over 15!).

There are a lot of gotchas in D. Anything that "can" explode your 
program in terms of memory leaks, or run / compile-time 
performance should be clearly documented.

And the barrier-to-entry is annoying even to fix documentation. I 
went to a D page, clicked "improve this page" and I have to... 
fork the repo, and then submit a pull request. Even if if's just 
to correct a typo. Is that kind of lock-and-key audited security 
over edits to documentation... really necessary? If it takes more 
than 10 seconds, most people aren't even going to bother.
Aug 31 2021
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 31 August 2021 at 08:27:30 UTC, Chris Katko wrote:


 And the barrier-to-entry is annoying even to fix documentation. 
 I went to a D page, clicked "improve this page" and I have 
 to... fork the repo, and then submit a pull request. Even if 
 if's just to correct a typo. Is that kind of lock-and-key 
 audited security over edits to documentation... really 
 necessary? If it takes more than 10 seconds, most people aren't 
 even going to bother.


That all happens on github. Even the editing. You never have to 
leave the browser. The whole point of that is that you don't have 
to fork manually from the command line. I'm not sure how it could 
be easier. Care to elaborate?

Anyway, if that's too much, then you can always submit an issue 
on Bugzilla.
Aug 31 2021
prev sibling next sibling parent drug <drug2004 bk.ru> writes:
31.08.2021 11:27, Chris Katko пишет:
[snip]

 
 And the barrier-to-entry is annoying even to fix documentation. I went 
 to a D page, clicked "improve this page" and I have to... fork the repo, 
 and then submit a pull request. Even if if's just to correct a typo. Is 
 that kind of lock-and-key audited security over edits to 
 documentation... really necessary? If it takes more than 10 seconds, 
 most people aren't even going to bother.
 


What's wrong with? Just now I submit a couple of PRs to fix typo in 
documentation. It's really trivial thing to do, especially if you 
contribute to open source projects. In fact it is a standard how to work.
Aug 31 2021
prev sibling parent bauss <jj_1337 live.dk> writes:
On Tuesday, 31 August 2021 at 08:27:30 UTC, Chris Katko wrote:

 And the barrier-to-entry is annoying even to fix documentation. 
 I went to a D page, clicked "improve this page" and I have 
 to... fork the repo, and then submit a pull request. Even if 
 if's just to correct a typo. Is that kind of lock-and-key 
 audited security over edits to documentation... really 
 necessary? If it takes more than 10 seconds, most people aren't 
 even going to bother.


That's standard for pretty much all open-source documentations.

See examples below:

MDN Uses Github for their documentation: 
https://github.com/mdn/content/blob/main/files/en-us/web/html/element/input/index.html

Rust: https://prev.rust-lang.org/en-US/contribute-docs.html

Visual C++: 
https://github.com/MicrosoftDocs/cpp-docs/blob/master/CONTRIBUTING.md

And the list goes on.

It's the most liable method of having documentation that can be 
contributed to by others.

What would your alternative be? There HAS to be someway of 
audited security, otherwise people WILL insert whatever into the 
documentation such as malicious content and the malicious content 
may not even be discoverable because it could be hidden to a 
page's user.
Aug 31 2021
prev sibling parent reply russhy <russhy gmail.com> writes:
On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project (including 
 the libraries themselves) using ldc2 and optimization "-Os" and 
 seeing how much time this takes, I want to ask if the 
 benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that tcc 
 and go. However, this test probably doesn't use optimizations 
 but still.... Ayn thoughts?


LDC is based on LLVM, just like rust/zig, so it's gonna be slow

DMD is the reference compiler, it is what you should use to get 
fast iteration time, in fast my game with 20+k lines of code 
compiles in just 0.7 seconds

![screenshot](https://i.imgur.com/z7vyRtX.png "screenshot")

https://i.imgur.com/z7vyRtX.png


I only use, and i recommand you use LDC for your release builds 
as LLVM has best optimizations


On windows it is a little bit slower but not that much

No matter the language, as long as you factor in templates, if 
you abuse them, it's gonna slow down your compile times since 
they need to be computer at compilation time
Sep 01 2021
next sibling parent russhy <russhy gmail.com> writes:
On Wednesday, 1 September 2021 at 22:49:59 UTC, russhy wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:



Just to be precise, 0.7 seconds for a FULL REBUILD :)

Just don't abuse templates
Sep 01 2021
prev sibling parent reply user1234 <user1234 12.de> writes:
On Wednesday, 1 September 2021 at 22:49:59 UTC, russhy wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project (including 
 the libraries themselves) using ldc2 and optimization "-Os" 
 and seeing how much time this takes, I want to ask if the 
 benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that tcc 
 and go. However, this test probably doesn't use optimizations 
 but still.... Ayn thoughts?


 LDC is based on LLVM, just like rust/zig, so it's gonna be slow

 DMD is the reference compiler, it is what you should use to get 
 fast iteration time, in fast my game with 20+k lines of code 
 compiles in just 0.7 seconds


same with the `--force` dub argument ?
Sep 01 2021
parent reply russhy <russhy gmail.com> writes:
On Wednesday, 1 September 2021 at 23:23:16 UTC, user1234 wrote:

 On Wednesday, 1 September 2021 at 22:49:59 UTC, russhy wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project 
 (including the libraries themselves) using ldc2 and 
 optimization "-Os" and seeing how much time this takes, I 
 want to ask if the benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that tcc 
 and go. However, this test probably doesn't use optimizations 
 but still.... Ayn thoughts?


 LDC is based on LLVM, just like rust/zig, so it's gonna be slow

 DMD is the reference compiler, it is what you should use to 
 get fast iteration time, in fast my game with 20+k lines of 
 code compiles in just 0.7 seconds


 same with the `--force` dub argument ?


it is, i used ``-f``
Sep 01 2021
parent reply russhy <russhy gmail.com> writes:
On Wednesday, 1 September 2021 at 23:37:41 UTC, russhy wrote:

 On Wednesday, 1 September 2021 at 23:23:16 UTC, user1234 wrote:

 On Wednesday, 1 September 2021 at 22:49:59 UTC, russhy wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project 
 (including the libraries themselves) using ldc2 and 
 optimization "-Os" and seeing how much time this takes, I 
 want to ask if the benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so much 
 time, It's hard to believe that ldc2 compiles faster that 
 tcc and go. However, this test probably doesn't use 
 optimizations but still.... Ayn thoughts?


 LDC is based on LLVM, just like rust/zig, so it's gonna be 
 slow

 DMD is the reference compiler, it is what you should use to 
 get fast iteration time, in fast my game with 20+k lines of 
 code compiles in just 0.7 seconds


 same with the `--force` dub argument ?


 it is, i used ``-f``


On windows the same project takes 1.8 sec to fully rebuild, 
windows likes to make things slow.. i wonder if that's because of 
the linker, i don't know how to check that
Sep 01 2021
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Wednesday, 1 September 2021 at 23:56:59 UTC, russhy wrote:

 On windows the same project takes 1.8 sec to fully rebuild, 
 windows likes to make things slow.. i wonder if that's because 
 of the linker, i don't know how to check that


I could be wrong but Windows has antivirus hooks on file access 
which slow down things, additionally programs might suffer from 
malware checks, thus such timings.

Extra thing is dub, it invokes compiler on each build to probe 
the environment, spawning new process on Windows is slower than 
on Linux, roughly like 100ms vs 10ms on Linux.
Sep 01 2021
prev sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Wednesday, 1 September 2021 at 23:56:59 UTC, russhy wrote:

 On Wednesday, 1 September 2021 at 23:37:41 UTC, russhy wrote:

 On Wednesday, 1 September 2021 at 23:23:16 UTC, user1234 wrote:

 On Wednesday, 1 September 2021 at 22:49:59 UTC, russhy wrote:

 On Monday, 30 August 2021 at 13:12:09 UTC, rempas wrote:

 Just trying to compile a sample basic gtk-d project 
 (including the libraries themselves) using ldc2 and 
 optimization "-Os" and seeing how much time this takes, I 
 want to ask if the benchmarks found 
 [here](https://github.com/nordlow/compiler-benchmark) about 
 ldc2 are real. Again seeing the gtk-d project taking so 
 much time, It's hard to believe that ldc2 compiles faster 
 that tcc and go. However, this test probably doesn't use 
 optimizations but still.... Ayn thoughts?


 LDC is based on LLVM, just like rust/zig, so it's gonna be 
 slow

 DMD is the reference compiler, it is what you should use to 
 get fast iteration time, in fast my game with 20+k lines of 
 code compiles in just 0.7 seconds


 same with the `--force` dub argument ?


 it is, i used ``-f``


 On windows the same project takes 1.8 sec to fully rebuild, 
 windows likes to make things slow.. i wonder if that's because 
 of the linker, i don't know how to check that


File system access is significantly slower on Windows because of 
case insensitivity, Unicode and more metadata accesses per file. 
This overhead is far from being negligible when accessing a lot 
of small files (on NTFS afaicr files < than cluster size are 
stored inside the special directory structure requiring special 
operation to extract and other such oddities).
Sep 02 2021
next sibling parent jfondren <julian.fondren gmail.com> writes:
On Thursday, 2 September 2021 at 11:05:44 UTC, Patrick Schluter 
wrote:

 File system access is significantly slower on Windows because 
 of case insensitivity, Unicode and more metadata accesses per 
 file. This overhead is far from being negligible when accessing 
 a lot of small files (on NTFS afaicr files < than cluster size 
 are stored inside the special directory structure requiring 
 special operation to extract and other such oddities).


It's definitely more than case insensitivity. Try it on Linux:

dd if=/dev/zero of=casei.img bs=1G count=50
mkfs -t ext4 -O casefold casei.img
mkdir casei
mount -o loop casei.img casei

That creates a 50G case-insensitive ext4 filesystem and then 
mounts it into a directory that you can build dmd in, etc.
Sep 02 2021
prev sibling parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 2 September 2021 at 11:05:44 UTC, Patrick Schluter 
wrote:

 On windows the same project takes 1.8 sec to fully rebuild, 
 windows likes to make things slow.. i wonder if that's because 
 of the linker, i don't know how to check that


 File system access is significantly slower on Windows because 
 of case insensitivity, Unicode and more metadata accesses per 
 file. This overhead is far from being negligible when accessing 
 a lot of small files (on NTFS afaicr files < than cluster size 
 are stored inside the special directory structure requiring 
 special operation to extract and other such oddities).


While true, this doesn't even remotely explain the difference.

Windows filesystem performance are a disaster. Don't take it from 
me, take it from the windows team itself, for instance: 
https://www.youtube.com/watch?v=yQEgeoabHNo

In that presentation, the engineer explain the challenge of using 
a git monorepo at microsoft, and process creation performance as 
well as file system performance where both major issue vs linux, 
and to a lesser extent OSX.
Sep 02 2021