dabroz.scythe.pl

When I was coding optimization stuff in QDT I was quite sure that I'm re-inventing the (low level virtual) wheel. So it was quite natural to plug it in and test-drive LLVM-ed QDT. Results were somehow unexpected and somewhat sad.

LLVM is a wonderful tool -- without a question. However as they say, from performance, versatility and readibilty you may choose *at most* two. LLVM is actually trying to choose e.

I was curious how GCC would handle expression from previous post.

float fun(float x)
{
  return 2+min(x+x+x,1.0f/5.0f)*(2.0f+x*3.0f);
}

void test_gcc(float *in, float *out, size_t count)
{
  for (size_t i = 0; i < count; i++)
  {
    out[i] = fun(in[i]);
  }
}

I was coding a particle system for my home engine. I wanted it to be quite flexible and after few iterations I had literally a dozens of parameters and transform modes. And this was not only a problem about design, it was a major performance issue.

I gave a thought about using expression parser. In some other project I've been involved, I've seen muParser library. But this was a no-go, as I had thousands of particles every frame and muParser was just too slow. And no, I couldn't offload particle computations onto GPU as GPU is heavily loaded with rendering.