Re: Inline Assembly / Inline C

Bartosz Dziewo=C5=84ski wrote in post #1076335:
> Not really. Compilers are smarter than us these days; they can
> interchange loops and vectorize the instructions to speed them up (on
> platforms which support it). Writing such code by hand would be
> painful, platform-dependent and error-prone.
> -- Matma Rex

Compilers can optimise better, but only if the code is written in such a =

way as to let them know it's safe. For example:

void add_numbers(int* a, int* b, int* results, unsigned count) {
  unsigned i;
  for (i =3D 0; i < count; ++i) {
    results[i] =3D a[i] + b[i];
  }
}

The compiler can unroll that loop a bit, but it will never be able to =

vectorise the arithmetic. Why? Because the pointers a, b and results =

could overlap. Vectorising can change the result, so the compiler will =

never do it.

You could use restrict to tell the compiler to assume these don't =

overlap:

void add_numbers(int restrict* a, int restrict* b, int restrict* =

results, unsigned count) {

That can lead to unexpected results if you pass overlapping ranges =

though - restrict is quite dangerous. A lot of high performance code =

works by explicitly unrolling:

void add_numbers(int* a, int* b, int* results, unsigned count) {
  unsigned i;

  /* Process in blocks of 4 */
  int r1, r2, r3, r4;
  for (i =3D 0; i + 3 < count; i +=3D 4) {
    /* Compute first */
    r1 =3D a[i] + b[i];
    r2 =3D a[i + 1] + b[i + 1];
    r3 =3D a[i + 2] + b[i + 2];
    r4 =3D a[i + 3] + b[i + 3];

    /* Save second */
    results[i] =3D r1;
    results[i + 1] =3D r2;
    results[i + 2] =3D r3;
    results[i + 3] =3D r4;
  }

  /* Finish portion not divisible by 4 */
  for (; i < count; ++i) {
    results[i] =3D a[i] + b[i];
  }
}

The second is logically equivalent to a vectorised loop, even if the =

ranges overlap, so the compiler is entitled to vectorise if it's =

worthwhile. Of course it now can't not unroll the loop. Actually testing =

this case shows the unrolled version as being slower for me :D

Compilers are pretty smart, but they can't change the behaviour of your =

code. Nobody should be writing in assembly any more, but to squeeze =

performance out of those really tight loops you still have to understand =

what's going on down there.

Cheers,

Tim

-- =

Posted via http://www.ruby-forum.com/.=