musl memset() implementation

Hello,

I was reading the musl source code, and I was surprised by the implementation of memset() (https://git.etalabs.net/cgit/musl/tr...tring/memset.c)

Reminder: The prototype of the function is

Code:

---

void *memset(void *dest, int c, size_t n)

---

and the s variable represents

Code:

---

unsigned char *s = dest;

---

The last line of the function is

Code:

---

for (; n; n--, s++) *s = c;

---

which should be enough for the complete implementation of memset, since it sets the whole array with the value c.

But instead of that, the function first manually sets the beginning and the end of the array, if 1 < n <= 8; then, only if __GNUC__ is defined, will continue to do the same for 9 < n <= 28 with an offset of 4.

As you can read, my understanding for what this function does, and, most importantly, why it is like that, is limited, and I would gladly like to read an explanation about it, other than the source code comments.

Best regards.

As you may know, this is the optimisation technique known as loop unrolling. As the comments imply, the idea is to minimise branching. Instead of assigning byte by byte, they want to assign many (in this case, 32) bytes per iteration. This also reduces the number of increments needed to get the job done.

The head and tail fills seem to serve two purposes: if the number of bytes to fill is small enough, it avoids the loop entirely. If not, it looks like they calculated it to maximise the rate of filling while avoiding out of bounds access.

Thank you for your reply. It's a bit more clear now.

I'm still surprised by the choice of unrolling loops by hand, as it is normally handled by compilers. Both Clang and GCC have a -funroll-loops flag.

I've read other implementations, and OpenBSD have chosen a much simpler path, with only a simple loop (src/memset.c at master * openbsd/src * GitHub). So now I'm wondering if premature optimization can be harmful.

A quick check shows that musl has a mailing list and IRC channel. Those would be appropriate places to ask concerning specific implementation considerations.

Premature optimisation is always harmful: you either made things worse, or you just wasted your time. But with respect to this code, you don't know if it is premature. Maybe they have measured for the platforms they are targeting and found that this beats the compiler optimised version, and since memset is a foundational function that is likely to be used in many places, optimising it is not premature.

Or maybe someone was just trying to show off and this is just bad code. You'll have to ask on the mailing list, measure for yourself, or both.