This is the homepage of Peter Alexander.

I write code.

I make games.

Recent Posts

Links

Scoped Imports in D

One of the nice things about the D programming language is that it has very convenient syntax for conditional compilation. For example, suppose you want to print out some useful info in debug builds. You just use:

debug writeln("Value of x is ", x);

One problem that I constantly run into in cases like this is that I haven’t imported std.stdio, so I have to go right up to the top of the file, add debug import std.stdio;, back down again, and continue. Sigh.

Not so fast! D has scoped imports, so you can put the import std.stdio; right where you need it.

void main(string[] args)
{
  debug import std.stdio;
  debug writeln(args);
  // ...
}

It’s the little things like this that make D so pleasant to use.

API Performance

One thing that I’ve never given much thought about until recently is the performance of APIs. I don’t mean things like avoiding virtual function calls in your interfaces. I mean designing an API so that it promotes usage that is optimal for the hardware you are running on.

A good example of this was explored in Noel Llopis’ post Data-Oriented Design Now And In The Future. Imagine you are designing the API for a physics system. One key operation of a physics system is to perform ray casts. The obvious API for this would be:

RayHitInfo rayCast(PhysicsWorld, Ray);

Many physics systems use an API like this. For example, it’s very similar to the API provided by Unity3D.

Most game engines also have some sort of game object system, whose main task usually involves looping through each game object, calling an update function. Many of those update functions will need to perform ray casts; perhaps something like this:

void update()
{
  // ...
  if (rayCast(world, forwardRay))
    doSomething();
  // ...
}

If you have many objects doing this then you are going to run into performance problems. The ray cast is going to touch lots of data (and code) to perform the query, causing multiple cache misses as it traverses through space partitioning data structures, mesh data, etc. Then, once the ray cast is complete, you will continue processing update functions, likely pushing most or all that ray cast data and code out of the cache. When the next ray cast comes up, you have to pull it all back in again.

In addition to the poor memory performance, you also can’t parallelize the ray casts. The call is blocking, so no other object updates can happen until the ray cast completes, meaning that no other ray casts are available for parallelization.

From a performance point of view, the ideal use case would be to

1. Gather all the queries up front from each game object.
2. Batch process those queries.
3. Feed the results back to game objects to continue updating.

The key thing to note here is that this ideal is impossible to achieve with the current API. In order to make this change, you will have to go through and re-shuffle the logic for each raycasting update function.

If you want a performant API then it is something that should be considered beforehand, as it may not be easy to fix later on. In general, APIs that encourage asynchronicity and batched execution tend to have higher potential for good performance than synchronous, one-at-a-time functions.

Simplicity in Everything

This website is now created using Jekyll. Originally, I had used Joomla, a big, industrial-strength content management system.

Joomla worked well for a while, but I quickly reached a point where I found myself unable to do, what should have been, simple things. For example, I couldn’t see any obvious way of extracting all the text from my posts – it was stored in a database somewhere. There was no simple way to test changes to my site locally because I couldn’t see how everything pieced together. It was just too complex for something that should have been very simple.

So I got thinking about what would be the simplest way to generate my website.

Well, what is my website? It’s just a collection of pages with the same layout, but with different blobs of text inserted in the middle for each post. I’d also like to generate some lists: recent posts, related posts, that kind of thing.

Ideally, what I want is something that transforms this

<body>
<h1>{{ page.title }}</h1>
{{ page.content }}
</body>

into this

<body>
<h1>Simplicity in Everything</h1>
<p>This website is now created using Jekyll...</p>
...
</body>

That’s exactly what Jekyll does. It just goes through all your pages and uses Liquid to transform them into a static site. Don’t believe me? The entire source for this site is on GitHub.

To test my website locally, I just run jekyll --server and head on over to http://0.0.0.0:4000. To deploy, I just run jekyll && rsync ..., which generates the site and copies it over to my remote server. That’s it.

Why can’t everything be this simple?

Homepage 2.0

Well, I’ve done it again. New website from scratch.

This time, I’ve gone for simplicity. I got sick of the incredible bloat of Joomla and all its features that were unnecessary for what I wanted to achieve: an essentially static website that I can easily configure.

This time, I’ve gone with Tom Preston-Werner’s excellent Jekyll static site generator. I just write my posts in Markdown, run jekyll, and it generates all the HTML for me. I have full control over the layout of the site, and everything is there in plain text.

The source for this site is hosted on GitHub.