>Ugh, your 'improvement' makes csum_partial upto ~2% slower...
>You have removed the check for non-32bit aligned buffers [1], and
Here after my patch the csum_partial performances are almost the same. If
something my one it's a bit faster. Maybe you are running a different CPU?
I use a PII Deschutes.
About the non-32bit aligned %esi, it was _not_ needed here. BTW, the
csum-copy wasn't aligning %esi/%edi too.
And btw, I think %esi is going to be aligned.
>added several branches when 'len' isn't a multiple of four.
That's __the__ bugfix for the buffer overflow in csum_partial.
You are avoiding the two branches by adding a plain buffer _overflow_, so
please don't claim to go faster since your code works only by _luck_.
Before ever make comparison with my code and your code, please make sure
that you are comparing my code with good code, and not with buggy code as
the old 686 csum_partial was. Otherwise I can't be interested on your
numbers.
>Have you actually benchmarked the code with your changes?...
Sure seems faster here. Please read the numbers I posted in my emails with
the patch.
>What 'potential buffer overflow'?
andl.
>The tool I used to optimize the ia32 checksum routines should be
>available at
>
>http://www.geocities.com/SiliconValley/Heights/6494/sw/iackk.tgz [14k]
I use DaveM cksum_helper.c hacked heavily by me for my needs. Now I'll
download also your tgz though. Thanks.
>I was going to work on it a bit more, but since people are
>posting patches that either break the routines completely or
>make them slower...
You obviously have _not_ yet seen the buffer overflow I spotted and then
fixed with my patch. When you'll have seen it, then I suggest you to make
sure that your experimental chksums are not buggy, and if they are buggy
then fix it, and make sure to repeat the benchmarks. Thanks.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/