D has sparked my interested therefore last week I have started to look into the language and have completed D course on pluralsight. One of area where I would like to apply D in  web application/cloud. Golang  is not bad but I think D seems more powerful. Although during my research I have found interesting facts:

1) fib test (https://github.com/drujensen/fib) with D  (compiled with ldc) showed really good performance results.
2) Various Web performance test on  https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query show pretty poor performance of D using vibe.d and hunt framework/libraries.  Regardless of type of test - json, single query, multiple query and so on.

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? I would say few times worse. This is not a troll post by any means. I am researching if D and D web framework whether it can be used as  replacement python/django/flask within our company. Although if D web framework show worse performance than Go then probably it is not right tool for the job.
Any comments and feedback would be appreciated.

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.
Equivalent implementation in C, C++, D, Rust, Nim compiled with same compiler backend should give exact same machine code. What you see in online language comparisons is mostly comparing different implementations and how much time people spent on optimizing.

> why web performance of those 2 web frameworks is so poor compared to rivals?

Difference in implementation. My guess is that people writing those servers didnt had time to spend on optimizations.

On Wednesday, 22 April 2020 at 14:00:10 UTC, serge wrote:

[...]

> 2) Various Web performance test on  https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query show pretty poor performance of D using vibe.d and hunt framework/libraries.  Regardless of type of test - json, single query, multiple query and so on.

[...]

> I am researching if D and D web framework whether it can be used as  replacement python/django/flask within our company. Although if D web framework show worse performance than Go then probably it is not right tool for the job.
> Any comments and feedback would be appreciated.

Vibe.d's performance in benchmarks has been discussed before[1]. From what I remember, the limiting factor is developer time allocation and profiling on specific hardware, which means it can probably be solved with money ;-)

-- Bastiaan.

[1] https://forum.dlang.org/post/qg9dud$hbo$1@digitalmars.com

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.

Yes.

If you have time to optimize: there is preciously little difference speed-wise between native languages.

Every native language using the same backend end up in the same ballbark, with tricks to get the code to the same baseline.

The last percents wille be due to different handling of UB, integer overflow, aliasing... but in general the ethos of native language is to allow you to reach top native speed and in the end they will generate the exact same code.


But, if your application is barely optimized, or more likely you don't have time to optimize properly, it becomes a bit more interesting. Defaults will matter a lot more and things like GC, whether the langage encourages copies, and the "idiomatic" style that is accepted will start to bear consequences (and even more so: libraries). This is what end up in benchmarks, but if the application was worth optimizing for it (in terms of added value) it would be optimized hard to get to that native ceiling.

In short, the less useful an application is, the more it will display large differences between languages with similar low-level capabilities.


It would be much more interesting to compare _backends_, but people keep comparing front-ends because it drives traffic and commentary.

On Wednesday, 22 April 2020 at 15:24:29 UTC, welkam 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.
> Equivalent implementation in C, C++, D, Rust, Nim compiled with same compiler backend should give exact same machine code. What you see in online language comparisons is mostly comparing different implementations and how much time people spent on optimizing.

Not quite. Rust will generate better assembly as it can guarantee that use of an object is unique. Similar to C's "restrict" keyword but you get it for "free" across the entire application.

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.

23.04.2020 01:34, Arine пишет:
> On Wednesday, 22 April 2020 at 15:24:29 UTC, welkam 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.
>> Equivalent implementation in C, C++, D, Rust, Nim compiled with same compiler backend should give exact same machine code. What you see in online language comparisons is mostly comparing different implementations and how much time people spent on optimizing.
> 
> Not quite. Rust will generate better assembly as it can guarantee that use of an object is unique. Similar to C's "restrict" keyword but you get it for "free" across the entire application.

You forget to add "in some cases Rust may generate better assembly than C/C++/D because..." But this is not the answer to the question OP asked. Rust has llvm based backend like ldc so nothing prevents ldc to be as fast as any other llvm based compiler. Nothing. The question is how many efforts you put into it.

On Thursday, 23 April 2020 at 11:05:35 UTC, drug wrote:
> 23.04.2020 01:34, Arine пишет:
>> On Wednesday, 22 April 2020 at 15:24:29 UTC, welkam 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.
>>> Equivalent implementation in C, C++, D, Rust, Nim compiled with same compiler backend should give exact same machine code. What you see in online language comparisons is mostly comparing different implementations and how much time people spent on optimizing.
>> 
>> Not quite. Rust will generate better assembly as it can guarantee that use of an object is unique. Similar to C's "restrict" keyword but you get it for "free" across the entire application.
>
> You forget to add "in some cases Rust may generate better assembly than C/C++/D because..." But this is not the answer to the question OP asked. Rust has llvm based backend like ldc so nothing prevents ldc to be as fast as any other llvm based compiler. Nothing. The question is how many efforts you put into it.

I wasn't replying to the author of the thread. I was replying to a misinformed individual in the thread.

If that's the way you want to think about, you can create your own compiler and language. "It's just about how many efforts you put into it", even if that means making your own language and compiler. How much "efforts" you have to put into something is a factor in that decision. You'd basically have to remake Rust in D to get the same assembly results and guarantee regarding aliasing.

23.04.2020 18:13, Arine пишет:
> I wasn't replying to the author of the thread. I was replying to a misinformed individual in the thread.
> 
> If that's the way you want to think about, you can create your own compiler and language. "It's just about how many efforts you put into it", even if that means making your own language and compiler. How much "efforts" you have to put into something is a factor in that decision. You'd basically have to remake Rust in D to get the same assembly results and guarantee regarding aliasing.

Well, you're right, I used wrong wording to express my thoughts. I meant that C/C++/Rust/D belong to the same performance league. The difference appears in specific cases of course, but in general they are equal. And your statement that Rust assembly output is better is wrong.

On Wednesday, 22 April 2020 at 16:23:58 UTC, Guillaume Piolat 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.
>
> Yes.
>
> If you have time to optimize: there is preciously little difference speed-wise between native languages.
>
> Every native language using the same backend end up in the same ballbark, with tricks to get the code to the same baseline.
>
> The last percents wille be due to different handling of UB, integer overflow, aliasing... but in general the ethos of native language is to allow you to reach top native speed and in the end they will generate the exact same code.
>
>
> But, if your application is barely optimized, or more likely you don't have time to optimize properly, it becomes a bit more interesting. Defaults will matter a lot more and things like GC, whether the langage encourages copies, and the "idiomatic" style that is accepted will start to bear consequences (and even more so: libraries). This is what end up in benchmarks, but if the application was worth optimizing for it (in terms of added value) it would be optimized hard to get to that native ceiling.
>
> In short, the less useful an application is, the more it will display large differences between languages with similar low-level capabilities.
>
>
> It would be much more interesting to compare _backends_, but people keep comparing front-ends because it drives traffic and commentary.

Could you please elaborate on that? what are you referring to as backend?  I am not interested to compare one small single operation - fib test already  did that.
To me techempower stats is pretty good indicator - it shows json processing, single/multiquery requests, database, static. Overall performance across those stats give pretty good idea, how language and web framework is created, its ecosystem.
For example if language is fast on basic operations but two frameworks show less then adequate performance then obviously something wrong with the whole ecosystem - it could be difficult to create  fast and efficient apps for average developer. For example Scala - powerfull but yet very complicated language with tons of problems. Most of Scala projects failed. It is very difficult and slow to create  efficient  applications for  average developer. It kinds requires rocket scientist to write good code in Scala.  Does D exhibit same problem?