| > How true is this? I hear this claim a lot but haven't seen any real benchmarks ... I think you're trying to read into the statement something other than Arthur meant; The last part of the quote is just as important as the first. Allow me to try and explain. It's pretty easy for an experienced C programmer to beat K at some things, for example: int i,n;for(i=n=0;i<1000000;++i)n+=i;
is faster (with gcc -O2) than the "equivalent": +/!1000000
which is more literally: int N=1000000;*a=malloc(N*sizeof(int)),i;
for(i=0;i<N;++i)a[i]=i;
int n=a[0];for(i=1;i<N;++i)n+=a[i];
free(a);
but even an experienced C programmer will experience some fatigue trying to convert a K program to C in this way, and the K implementation is certainly faster than a literal translation (largely because it doesn't use malloc, but yes also because of careful vectorisation and parallelising of many of the operators).It's my experience this difference adds up faster than anything else, and that's why a 20kloc C++ implementation of a HIBP checker was beat 10x by a 5-line k/q solution: https://news.ycombinator.com/item?id=22467866 But make no mistake, I don't use k because it's fast, but because it makes me fast: five lines of code ain't squat to get right over 20k lines, so I'd prefer the k solution even if it were "only" just as fast as someone's C++ solution. It does help tremendously though, that it's usually much much faster. |