Optimizations and performance

[Chris via Digitalmars-d]

On Thursday, 9 June 2016 at 08:31:37 UTC, qznc wrote:
> On Wednesday, 8 June 2016 at 22:19:47 UTC, Bauss wrote:
>> D definitely needs some optimizations, I mean look at its 
>> benchmarks compared to other languages: 
>> https://github.com/kostya/benchmarks
>>
>> I believe the first step towards better performance would be 
>> identifying the specific areas that are slow.
>>
>> I definitely believe D could do much better than what's shown.
>>
>> Let's find D's performance weaknesses and crack them down.
>
> The previous step is to find a good benchmark. This one isn't.
>
> For example, you should clarify what kind of code you want: 
> Short idiomatic elegant code? Or rather optimized to max using 
> every trick you can no matter the length?
>
> Carefully check what the benchmark actually measures. It should 
> not measure IO or pthread context switching for example, 
> because that is not really a distinguishing factor between 
> languages.
>
> Also make sure the benchmarks are fair. For example, 
> "threadring" in the shootout measures pthread context 
> switching, except languages like Erlang and Haskell, which use 
> user-level scheduling. This an apples to oranges comparison.
>
> Sometimes the decision is not clear. Do you want a benchmark of 
> regular expressions? It makes sense to compare D's and Rust's 
> standard library to others, but many (Python, Ruby, etc) will 
> use nearly the same C code underneath.
>
> Another aspect is the statistical stuff. At least measure the 
> deviations. Better, do some hypothesis tests.

As this thread [1] shows, a lot depends on the library. Common 
wisdom has it that one should always use library functions, 
because they're already optimized for speed. This is not 
necessarily the case in D (see [1]). So it is a good idea in 
general to compare libraries, say C/C++ standard libs and Phobos. 
First we have to find the suboptimal spots in Phobos, because 
most of the time, people will use library methods like 
`std.algorithm.find`, `countUntil`, `splitter` etc.

Then of course the language/compiler can help with common idioms 
like Ranges. We should check, if using common idioms slows a 
program down, e.g.

- iterating in range style vs. tight for-loops
- for-loops vs. foreach-loops
- how does D's handling of lambdas affect performance?
- [etc.]

These should be as fast as possible, because what's the point of 
having them, if you have to roll your own C-like for-loops to get 
good performance. It's not about how much performance you can 
squeeze out of D in the extremest of extreme cases, it's about 
making the language as fast as possible for normal use cases.

[1] 
http://forum.dlang.org/post/qkonnwtxxtjmjtryrfax@forum.dlang.org