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/qkonnwtxxtjmjtryr...@forum.dlang.org
