an optimized memcpy for small, or fixed size data in gcc

Question

I use memcpy to copy both variable sizes of data and fixed sized data. In some cases I copy small amounts of memory (only a handful of bytes). In GCC I recall that memcpy used to be an intrinsic/builtin. Profiling my code however (with valgrind) I see thousands of calls to the actual "memcpy" function in glibc.

What conditions have to be met to use the builtin function? I can roll my own memcpy quickly, but I'm sure the builtin is more efficient than what I can do.

NOTE: In most cases the amount of data to be copied is available as a compile-time constant.

CXXFLAGS: -O3 -DNDEBUG

The code I'm using now, forcing builtins, if you take off the _builtin prefix the builtin is not used. This is called from various other templates/functions using T=sizeof(type). The sizes that get used are 1, 2, multiples of 4, a few 50-100 byte sizes, and some larger structures.

template<int T>
inline void load_binary_fixm(void *address)
{
    if( (at + T) > len )
        stream_error();

    __builtin_memcpy( address, data + at, T );
    at += T;
}

Works fine for me with gcc 4.4.1 as soon as I enable optimization (-O1). That is, memcpy is inlined. Can you provide a small code simple, and tell what compiler switches you use? — davmac
Don't profile your code (for this, I mean). Look at the disassembly for a specific small memcpy, see what it does. Even with the intrinsic, library memcpy might well be called for large or for variable sizes. — Steve Jessop
@Steve, I don't see any reason why valgrind would report "memcpy" being called if it wasn't being called. I know that memcpy can still be called, but for my situation it shouldn't be. — edA-qa mort-ora-y
You said that you copy both variable and fixed sizes, and that "some cases" are small. I would therefore expect a lot of calls to library memcpy, and "some cases" of it being inlined. So your report of thousands of calls to memcpy seems entirely consistent. If there's a specific call site where it's called from, that you think should be inlined, that's another matter, but a raw count of calls to memcpy seems like a pretty useless metric to me. — Steve Jessop
OK, well, I'm looking at disassembly, and so far I can't persuade g++ -O3 to call library memcpy whatever I do. So I'm afraid I can't speculate as to which of your particular uses of std::memcpy are responsible for the thousands of calls you're seeing. — Steve Jessop

janm janm · Accepted Answer · 2010-11-15T00:06:10

For the cases where T is small, I'd specialise and use a native assignment.

For example, where T is 1, just assign a single char.

If you know the addresses are aligned, use and appropriately sized int type for your platform.

If the addresses are not aligned, you might be better off doing the appropriate number of char assignments.

The point of this is to avoid a branch and keeping a counter.

Where T is big, I'd be surprised if you do better than the library memcpy(), and the function call overhead is probably going to be lost in the noise. If you do want to optimise, look around at the memcpy() implementations around. There are variants that use extended instructions, etc.

Update:

Looking at your actual(!) question about inlining memcpy, questions like compiler versions and platform become relevant. Out of curiosity, have you tried using std::copy, something like this:

template<int T>
inline void load_binary_fixm(void *address)
{
    if( (at + T) > len )
        stream_error();

    std::copy(at, at + T, static_cast<char*>(address));
    at += T;
}

an optimized memcpy for small, or fixed size data in gcc

1 Answers