Marco, talking about strlcpy: > And now if the userspace people in linux would also adopt it > the world would be a better place. Can anyone say glibc?
Ulrich Drepper at the least appears busy elsewhere: http://people.redhat.com/drepper/cpumemory.pdf "What Every Programmer Should Know About Memory" (Nov. 21, 2007) He is telling people they should manually partially unwrap for loops written C in in order to optimize level 1 data cache access: Ulrich Drepper wrote: > #define SM (CLS / sizeof (double)) > for (i = 0; i < N; i += SM) > for (j = 0; j < N; j += SM) > for (k = 0; k < N; k += SM) > for (i2 = 0, rres = &res[i][j], > rmul1 = &mul1[i][k]; i2 < SM; > ++i2, rres += N, rmul1 += N) > for (k2 = 0, rmul2 = &mul2[k][j]; > k2 < SM; ++k2, rmul2 += N) > for (j2 = 0; j2 < SM; ++j2) > rres[j2] += rmul1[k2] * rmul2[j2]; That's giving him an 83% speed improvement on 1000x1000 by 1000x1000 double precision matrix multiplication - on his particular hardware, linux and gcc version, that is (as an aside, i failed to find a single word concerning numerical stability in that context). In that respect, he is not cheating, he clearly states in the introduction that the paper is "limited to commodity hardware and further limited to a subset of that hardware" and that "the text exclusively describes Linux". Besides, he is advertising posix_memalign, __attribute((aligned(64)), -mpreferred-stack-boundary, __builtin_expect, -freorder-blocks and -falign-jumps. Sure, the title of that 114 page paper reads What Every Programmer Should Know About Memory. Did you? $ wc /tmp/cpumemory.* 4879 23252 934051 /tmp/cpumemory.pdf 2375 91431 516772 /tmp/cpumemory.txt $ perl -ne '/(strl\w+)/i && print "$1\n";' < /tmp/cpumemory.txt strlen strlen Well, probably strlcpy is simply just unrelated to anything we ought to know about memory access.
