D perfomance

[serge]

On Thursday, 23 April 2020 at 00:00:29 UTC, mipri wrote:
> On Wednesday, 22 April 2020 at 14:00:10 UTC, serge wrote:
>> My understanding that D is the language in similar ballpark 
>> performance league as C, C++, Rust. Hence the question - why 
>> web performance of those 2 web frameworks is so poor compared 
>> to rivals?
>
> Consider this benchmark from the thread next door, "Memory
> issues. GC not giving back memory to OS?":
>
>   import std.stdio;
>
>   void main(string[] args)
>   {
>       int[] v = [1, 2];
>       int n = 1 << 30;
>       for (int i = 0; i < n - 2; ++i)
>       {
>           v ~= i;
>       }
>       writefln("v len: %s cap: %s\n", v.length, v.capacity);
>   }
>
> With an average of four runs, compiled with gdc -O3, this takes
> 40s and has a max RSS of 7.9 GB.
>
> Here's the same benchmark changed to use std.container.array:
>
>   void main() @nogc {
>       import core.stdc.stdio : printf;
>       import std.container.array;
>
>       Array!int v = Array!int(1, 2);
>       foreach (i; 0 .. (1 << 30) - 2)
>           v ~= i;
>       printf("v len: %d cap: %d\n", v.length, v.capacity);
>   }
>
> Same treatment: 3.3s and a max RSS of 4.01 GB.
> More than ten times faster.
>
> If you set out to make a similar benchmark in C++ or Rust
> you'll naturally see performance more like the second example
> than the first. So there's some extra tension here: D has
> high-convenience facilities like this that let it compete with
> scripting languages for ease of development, but after you've
> exercised some ease of development you might want to transition
> away from these facilities.
>
> D has other tensions, like "would you like the GC, or no?" or
> "would you like the the whole language with TypeInfo and AAs,
> or no?", or "would you like speed-of-light compile times, or
> would you like to do a lot of CTFE and static reflection?"
>
> And this is more how I'd characterize the language. Not as "it
> has this such-and-such performance ballpark and I should be
> very surprised if a particular web framework doesn't match
> that", but "it's a bunch of sublanguages in one and therefore
> you have to look closer at a given web framework to even say
> which sublanguage it's written in".
>
> I think the disadvantages of D being like this are obvious. An
> advantage of it being like this, is that if you one day decide
> that you'd prefer a D application have C++-style performance,
> you don't have to laboriously rewrite the application into
> a completely different language. The D-to-D FFI, as it were, is
> really good, so you can make transitions like that as needed,
> even to just the parts of the application that need them.

I did check the library.. My understanding that proposal is to 
use the library with manual memory management without  GC. My 
concern was that D web frameworks performed worse then frameworks 
in Go and Java which are GC only languages.

Does it mean that GC in D is far from great that we need to avoid 
it in order to beat Java/Go? Probably would worth to stress  - I 
didn't mean in fact beat, I would love to see stats on par with 
Go and Java but unfortunately D was few times slower - close to 
Python and Ruby...
Despite the library can speed things up I believe the 
language/runtime should be able to work efficiently for such type 
of operations. We should not need to develop such libraries in 
order to have good performance. To me it is bug or poor 
implementation of GC or deficiency in design of runtime.  The 
need for that type of libraries to solve deficiencies in runtime 
would not allow to focus on writing good code but instead to look 
for gotchas to get adequate solution.