D perfomance

[Paulo Pinto]

On Friday, 24 April 2020 at 13:58:53 UTC, serge wrote:
> 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.

Yes, that does mean that D's GC still needs some improvements, 
although much have been done during the last year.

Also note that while Java and Go are heavy GC languages, there 
are ways to do value based coding, and although Project Valhala 
is taking its time due to the engineering issues it addresses, it 
will eventually be done.

Just like in all GC enabled languages that offer multiple 
allocation mechanisms alongside the GC you should approach it in 
stages.

Use the GC for you initial solution and only in cases where it is 
obvious from the start that it might be a problem, or when proven 
that some issues might have to be adressed then look for value 
allocation, @nogc, referenced counted collections and other low 
level style tricks.

That is the nice thing about systems languages like D, you don't 
need to code like C from the start, and when you need to actually 
do it, the tools are available.