Programming languages and performance
H. S. Teoh via Digitalmars-d
digitalmars-d at puremagic.com
Mon Apr 13 16:50:17 PDT 2015
On Mon, Apr 13, 2015 at 04:28:45PM -0700, Walter Bright via Digitalmars-d wrote:
> https://www.reddit.com/r/programming/comments/32f4as/why_most_high_level_languages_are_slow/
>
> Good article, discussion is a bit lame.
While Phobos is making good progress at being allocation-free, it still
has a ways to go. And it doesn't help that the current D GC isn't that
great, when you do have to allocate -- I've managed to get 30-40%
performance improvements just by turning off the default collection
schedule and triggering collections myself at more strategic intervals.
Not having to box things is a big win IMO, though. Boxing of POD types
in Java/C# just screams "inefficient" to me... can you imagine all that
extra, needless indirection wreaking havoc on the CPU cache and cache
predictions? Having first-class support for value types is also a big
win. I rarely use classes in D except when I actually need polymorphism,
which requires heap allocation. With alias this, you can even have a
limited amount of inheritance in structs, which is totally cool.
But at the end of the day, the programmer has to know how to write
cache-efficient code. No matter how the language/compiler tries to be
smart and do the Right Thing(tm), poorly-laid out data is poorly-laid
out data, and you're gonna incur cache misses all over the place.
Cache-unfriendly algorithms are cache-unfriendly algorithms, and no
smart language design / smart optimizer is gonna fix that for you. You
have to know how to work with the modern cache hierarchies, how to lay
out data for efficient access, and how to write cache-friendly
algorithms. To this end, I found the following series of articles
extremely enlightening:
http://lwn.net/Articles/250967/
T
--
Music critic: "That's an imitation fugue!"
More information about the Digitalmars-d
mailing list