Hi @JakeChampion, thanks for this.

It's been a few years since I last looked at this, but a small loop used to be faster than memcpy() for fewer than about 20 bytes when built with -O3.

Is memcpy() always faster now? We should probably test at least current clang and gcc, and x64 and arm64.

I made a tiny benchmark:

#!/bin/bash

for b in {1..50}; do
  vips black x.v 1 1 --bands $b
  echo -n $b,
  VIPS_CONCURRENCY=1 /usr/bin/time -f %U \
    vips embed x.v x2.v 0 0 10000 10000 --extend copy
done

For a release build of git master libvips vs. this PR on an AMD threaripper pro I see:

So very similar speed. The for loop is quicker for small (<10?) bytes per pixel.

It's not a very sophisticated test, of course!

This is really interesting, thanks @JakeChampion, were you able to do any benchmarking/profiling?

I've created https://godbolt.org/z/daq8nGqhM to help explore the assembly generated by each approach under various compilers/architectures, but remember less code != faster.

If this is a particularly "hot" function for your scenario, a possible (and more verbose) alternative might be fixed-size loops for common values of bs as these could allow the compiler to optimise the unroll vs memcpy decision itself.

What I ended up with which looked to perform well on my machine was this:

https://godbolt.org/z/zP8KxjxTr

static void
vips_embed_base_copy_pixel(VipsEmbedBase *base,
	VipsPel *q, VipsPel *p, int n)
{
	const int bs = VIPS_IMAGE_SIZEOF_PEL(base->in);

	int x;

	switch (bs) {
	case 1:
		memset(q, p[0], n);
		break;
	case 2:
		for (x = 0; x < n; x++)
			((guint16 *)q)[x] = *(guint16 *)p;
		break;
	case 3:
		for (x = 0; x < n; x++) {
			q[0] = p[0];
			q[1] = p[1];
			q[2] = p[2];
			q += 3;
		}
		break;
	case 4:
		for (x = 0; x < n; x++)
			((guint32 *)q)[x] = *(guint32 *)p;
		break;
	case 8:
		for (x = 0; x < n; x++)
			((guint64 *)q)[x] = *(guint64 *)p;
		break;
	default:
		for (x = 0; x < n; x++) {
			memcpy(q, p, bs);
			q += bs;
		}
		break;
	}
}

I made a tiny benchmark:

#!/bin/bash

for b in {1..50}; do
  vips black x.v 1 1 --bands $b
  echo -n $b,
  VIPS_CONCURRENCY=1 /usr/bin/time -f %U \
    vips embed x.v x2.v 0 0 10000 10000 --extend copy
done

If I use this same approach, my results are:

Oh, nice!

How about making this into a macro, perhaps VIPS_MEMCPY()? If we do this, it'll mostly be compiled away for values of N known at compile time.

I guess it could also be tagged as inline in a header, though I'm uncertain if all the C compilers we need to support do the right thing for that.

There are quite a few places in libvips where a fast(er) memcpy would be useful.

@jcupitt shall we wait for https://github.com/libvips/libvips/pull/4969/files#diff-2d3fc3425516d0b30885586f344f3902e9541a56b5de4871eb328ef461a3d7e8 and then bring that into this branch?

Oh, sure, let's do that.