I think it's common to avoid the GC in performance critical sections of your code. D's version of BLAS is faster[1] and avoids the GC completely.

[1] http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...

consistently beating OpenBLAS and having performance comparable with MKL is seriously impressive. I'm wondering how that is possible. I assume it's using the same algorithms as other implementations, so the credit goes to the compiler (and to the language to some extent). But the D compiler just uses LLVM for the back end, so is this because LDC produces really good LLVM IR, or is LLVM really good at generating assembly? Either way I'm really impressed they can beat hand-tuned assembly, I'd love to see a comparison between the resulting assembly for Mir GLAS and OpenBLAS.

LDC dev here. All the credit for this goes to Ilya Yaroshenko for the expertly crafted implementation and the LLVM developers for efficient low-level code generation (inlining, register allocation and so on, and in some places auto-vectorization). LDC only needs to make sure not to "mess up" things too much.

D does play a significant role in this achievement, though – D's very powerful yet easy to use features for generics and introspection make it possible to finely tune the code for different parameters (sizes/dimensions/…) while still being easy to understand and modify.

That's helpful, thanks!

I definitely appreciate the power of generics, especially when you can to generics over values instead of just types. But I'm having trouble seeing the value of the compile-time introspection, for the most part it doesn't seem to give you much more power than generics do. Could you give me an example of the "killer feature" introspection gives over generics? Bonus points if you can compare it to Rust-style generics with traits and specialization.

Many things, although introspection works glove in hand with generics. Below os a non-exhaustive list.

You can 'Write once - automate everywhere' all the boilerplate. See https://github.com/kaleidicassociates/excel-d/ , for an example of automating the interaction between D and Excel. I am in the process of doing something similar for OpenCL and CUDA and will be presenting it at Dconf.

You can make at compile time (additional) fast paths by checking to see if a type (or symbol or whatever else) provides a fast primitive to accelerate your algorithm. e.g. if Foo implements fastfoo use that otherwise fallback to a general algorithm.

See also Andrei Alexandrescu's 2016(15?) talk (IIRC the relevant section is about half way through https://www.youtube.com/watch?v=4oDK91E3VKs).

It's much easier to generate code adapted to that cpu and machine in D because of compile time features. Plus it was an excellent team of a few people working for a few years that built mir. Actually I am joking - mostly one guy working for a few months (with a little help) made mir Blas. A pretty nice example of productivity of D. Also an illustration of the high calibre of person found in the D community.

You can get some information from this comment[1] by the author as well as his others on that thread. This is somewhat outside of my area.

[1] https://www.reddit.com/r/programming/comments/54kg6v/numeric...

The performance of D is the same as that for the corresponding C/C++ program in the corresponding compiler.

    dmd and Digital Mars C++
    gdc and gcc
    ldc and clang

I meant the situations when the GC is a bottleneck, and how people deal with it, by fine tuning GC, etc... Any war stories about this...

Weka use D for making systems that store Petabytes of data in production. They don't really like the GC kicking in on that situation. So they write the first draft of code using the GC, and then for production make it not use GC - pre allocating largely. If you really care about latency I guess you can't really afford to use malloc necessarily.

But for the rest of us, D is not really comparable with Java but people tend to think if it the same way. I don't use classes myself (I had one but a guy didn't like it and removed it, though one or two in library code may have crept back recently) but allocate structs on the stack. The latter is more idiomatic generally in D. Depends how you count it, but at 120k sloc, maybe 200k if you include the periphery.

It's easy to allocate without GC using the std.experimental.allocator and emsi containers. Regional heaps, free lists, whatever hybrid model you want.

See excel-d for one example.

If you keep the rest of your heap small, say below 200Meg most people will be fine.

If you don't want to use D, blame the docs and lack of examples - still not as good there, but way better than before and all the unit tests are editable and runnable now. But I think the GC thing is more FUD than a real objection for most people.

People on embedded systems use a custom runtime, and people who want to avoid the GC use the compiler to disallow GC usage in their entire program by using the @nogc annotation.

There are other less extreme solutions, such as the ability to have some threads be registered with the GC and others not. Also, you can just find your bottle-necks and mark those specific functions as @nogc. Some people also turn off automatic collections and manually trigger them only when it's ok to pause.

Weka.io develop a software-defined distributed storage system in D with latencies well below a millisecond (over Ethernet). They use the GC in some parts, but avoid it on the hot path as much as possible as it is a simple pause-the-world mark-and-sweep collector.

All in all, the GC isn't as much of an issue for high-performance applications as is sometimes claimed, but all the recent work towards reducing the dependency on it has of course been done for a reason – in performance-critical code, you often don't want any allocations at all (GC or not), and the large jitter due to collections can be a problem in some situations.

Auburn sounds makes audio plugins in D and share how they avoid using GC in blog posts. Not that bad even for audio. Sociomantic and Weka both do soft real time.