D benchmark code review

Manu turkeyman at gmail.com
Fri Dec 13 08:05:52 PST 2013


On 13 December 2013 22:41, logicchains <jonathan.t.barnard at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131214/14f96c96/attachment.html>


More information about the Digitalmars-d mailing list