Try two: Python and C

From here on, no more pure python.

How long had it been since I last typed some C :blush:
Probably too long, but it was worth it!

The porting

Was a little bit painful at first.
But once header files and signatures started coming together, everything started to go much more smoothly.

• The "classical" approach I liked so much in the Python version was turned into a hybrid of itself and C structs.
• 100% of the number crunching was ported to C
• 100% of the seeded random generation was ported to C
• the two latter items started in C and stayed in C. I.e, no more coming back and forth between the "fast world" and the "slow world".

In summary, the C code was turned into one of those "black boxes" you & I regularly use in python.

A note on compiling and packaging

distutils works well, even though its syntax/logic is at times a little obscure.
That being said, running:

pip wheel --no-deps -w dist .

After setting up the setup.py file, is all it takes! Compilation is quick (not that the module was ever that big anyway…) and wheel generation is as well.

However, I have and still do find the exposition of C variables/constants and methods to the outside Python world clunky and frankly not very friendly to use. A question of taste, I suppose…

Lightspeed

After coding, compiling and packaging, comes the next part: running it. And ho boy I was not disappointed!
The code was running, at an equivalent level of detail, from 30 to 100 times faster than the very initial pure python version!

• Random and reproducible? check
• Much faster? check
• No memory leaks? check
• Reasonable "object-oriented" and/or classical feel to it? check.
• A little bit of pride for building such a nice little toy? check

Why the f*** hadn't I thought of porting to a compiled language sooner?

After a period of relative worry ("how on earth am I going to be able to stream all that??"), things started to brighten up a little.

A client-side tangeant

The performance gains were such that, for a long while, I switched to the Javascript 3D client, where optimisations of a different nature were needed. A potential upcoming post will cover this.

The C version did insure the client's performance needs for long time, and then some:

• Streaming was smooth
• Faster server-side generation times meant more freedom and flexibiliby client-side and that was extremely welcome
• Aggressive load tests against websockets serving generated data resulted in very encouraging figures

…up to the point where the client was able to handle the simultaneous display and streaming and "garbaging out" of several thousand stars. But again, let's wait for a future post about that.

The great nagging

In spite of all the positive consequences brought about by the C version, I was still not feeling comfortable with it. Even at this stage, it is difficult to remember or know why:

• Messy code structure
• C->py bindings I found cumbersome, especially to expose simple constants to the outside world
• Overall "I've got a meh feeling about this"

So the nagging went on until I decided to have a go at Rust.