On 13 December 2013 22:41, logicchains <jonathan.t.barnard@gmail.com> wrote:

I've posted a couple of benchmarks involving D previously and received complaints that the D implementation was ugly and un-idiomatic, so I thought I'd seek code review before posting the next one. The code is at https://github.com/logicchains/ParticleBench/blob/master/D.d; it's an OpenGL particle animation, and my D code is essentially just a direct port of the C implementation. Note however that, as the animation is gpu-bound, there's not much scope for optimisation of the code (in hindsight, it was a pretty poor topic for a benchmark, but hindsight always sees farthest and whatnot).

Is it idiomatic to use egyptian braces in D? I've never seen D code written this way... looks like Java.

You have a lot of globals, and they're all TLS. That seems inefficient, and potentially incorrect if there were threads.

Why do you build the vertex array from literal data at runtime? Why not just initialise the array?

It's a static array, so it's not allocated at runtime, so it shouldn't be any different. You'd probably save a lot of LOC to initialise the array, perhaps better for clarity. It should probably also be immutable?

Those integer for loops might be nicer as: foreach(i; 0 .. n)

I'm not personally in the camp that agrees:

double

x = 0,

y = 10,

z = 15;

is a good thing... but each to their own :)

Why are you using 'double' in realtime software? That's weird isn't it? Granted, it will make no difference on x86, but I'd never personally do this for portability reasons.

But generally looks fine. Any opengl code is naturally going to look C-ish by nature. And yes, as you said, it's not really a very good benchmark, since you're really benchmarking the GPU (and the legacy fallback non-shader pipeline at that) ;) .. The mainloop barely does anything, and has very few iterations.

Nitpick: I think properness would have you update the velocity before the position, or you'll always run 1 frame behind.

There are a lot more really minor performance hazards that I'd never let slip if they were invoked in hot loops, but they won't make any difference here.