Completely Ripping the Runtime out of D

Published 18 December 2016, Updated 06 March 2018

Update: a lot of this information is already outdated (good news!). See my latest update, and my second update.

Most high level languages are built as a layer on top of C. That includes out-of-the-box D, but it doesn’t have to be that way: D is a plausible candidate for a “better C”. I think this is a pretty cool idea, so I’ve been experimenting with it to see what’s possible. The dmd compiler (and very soon the ldc2 compiler) has a -betterC command line flag that’s intended to remove dependencies on the D runtime. Unfortunately, it’s still extremely rudimentary — the docs only promise it “omit[s] generating some runtime information and helper functions” — so in practice it’s hard to write non-trivial D code without getting runtime dependencies, even if you don’t need them in theory.

With a little linker hacking, it’s possible to rip these unnecessary dependencies out of compiled D code. As an example, I’ll completely remove all references to the D runtime out of some compiled D code so that it can link directly to some C, as if it were C code to begin with.

On Not Optimising for Last Century's Hardware

Published 20 November 2016

Once upon a time I wrote a super-optimised algorithm for rotating data in an array. At least, it was meant to be super-optimised, but its real-world performance turned out to be terrible. That’s because my intuition about performance was stuck in the 20th century:

Break a program down into basic operations like multiplication and assignment
Give each operation a cost (or just slap on an O(1) if you’re lazy)
Add up all the numbers
Try to make the total in step #3 small

A lot of textbooks still teach this “classic” thinking, but except for some highly constrained embedded systems, it just doesn’t work that well on modern hardware.

Function Attributes and the D ABI

Published 05 October 2016

Tags: dlang , Software Engineering and Low Level

The D programming language has a bunch of built-in attributes like pure and nothrow. I was wondering how things like libraries might break if function attributes changed between versions, so I gave it a try.

DConf 2016 Talks

Published 24 July 2016

Tags: dlang and Software Engineering

The DConf 2016 talk videos have been released.

Here’s my (very short) list of special recommendations. They’re worth watching even if you don’t use D.

How Dirtying Pure Functions a Little Can Be Useful

Published 28 March 2016, Updated 30 March 2016

Tags: Software Engineering , Programming Languages , dlang and Haskell

Functional purity is a valuable concept for writing maintainable code, though outside of functional programming languages like Haskell, it’s often treated like a nice-but-expensive luxury. But it turns out that pure functions that aren’t quite so pure can be cheap while still having concrete benefits for code in non-functional languages like C++, Java and Python. For D code, this is supported by the language itself, but there’s nothing D-specific about the overall idea.

What Difference Can Order Make When Hashing?

Published 03 January 2016

Tags: Security and dlang

I saw this thread about password hashing on the D language forums. The original post had a good question that didn’t get answered at the time: if you’re hashing a bunch of things, can it make any difference (for security) what order you do it?

The answer turns out to be yes, and it’s a neat example of the difference between theoretical ideals and real-world systems. Because I think this stuff is worth knowing if you’re using cryptographic hash functions for, you know, actual crypto, I thought I’d write up a blog post about why it can matter.