Is D slow?

[Honey via Digitalmars-d-learn]

On Friday, 9 June 2017 at 18:32:06 UTC, Steven Schveighoffer 
wrote:
> Wow, so that's how D code would look like if it were C++ :)

Well, I cannot (and did not try to) hide where I am coming from. 
;-)


>> The results are quite disappointing. What seems particularly 
>> strange to
>> me is that -boundscheck=off leads to a performance decrease.
>
> That doesn't make much sense, but I'm not an ldc2 user. 
> However, it does note in the help that -release disables bounds 
> checks already.

Sounds like a bug, then.


> I did replicate that issue on my box, and mucking around with 
> the implementation didn't help.
>
> In answer to the subject, no D is not slow. However, it's quite 
> possible that std.algorithm.bringToFront is slower than 
> std::rotate, or SortedRange.upperBound is slower than 
> std::upper_bound, or both. I don't think it's a design issue 
> per se, probably more of an implementation issue.

Thank you for confirming the results and your factual explanation 
notwithstanding my pointed question. ;-)

Maybe I was expecting too much given Andrei's performance 
oriented talks. I realize that the conceptual groundwork is more 
important than a concrete implementation that can be easily 
improved. However, I think that real world out-of-the-box 
performance - particularly with respect to toy examples (since 
those are small enough to be literally translated) - is important 
for prospects to gain confidence in buying into D.

At the current state, at least for such benchmarks, I think, I 
should not rely on standard library facilities. Unfortunately, 
that does not increase my confidence.