[lkml]   [1999]   [May]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: ia32 ip checksum optimizations
Andrea Arcangeli wrote:
> On Tue, 25 May 1999, Artur Skawina wrote:
> >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.

it's faster for the aligned buffer, multiple-of-four len case, it's
slower when len&3, and it's a lot slower for the unaligned buffer case.

> About the non-32bit aligned %esi, it was _not_ needed here.

see my previous msg, for explanation.

(basically, you get an impressive 0.5% speed increase ;),
but take a significant hit (44%) in case the buffer isn't
properly aligned)

> And btw, I think %esi is going to be aligned.

and you have verified this?

> >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

define 'buffer overflow' :)

i found this amusing, but (a) it's not my code, and (b) just because
you might not know what it does does not make that code 'buggy'.

> Sure seems faster here. Please read the numbers I posted in my emails with
> the patch.

haven't seen any such post yet.

> >What 'potential buffer overflow'?
> andl.

and? :)

> 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.

well, if you really expect anybody to look at this why don't you
show a case where the original code fails... Since it works, as you say,
"only by _luck_" this shouldn't be very hard :^)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.079 / U:2.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site