Date: Sat, 27 May 2006 00:28:40 +0200 From: Alexander Leidinger <Alexander@Leidinger.net> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: Gordon Bergling <gbergling@0xfce3.net>, freebsd-current@freebsd.org, Andrew Gallatin <gallatin@cs.duke.edu>, Max Laier <max@love2party.net> Subject: Re: Take 2: new IP Checksum Code from DragonFlyBSD Message-ID: <20060527002840.35ebf26e@Magellan.Leidinger.net> In-Reply-To: <20060526201452.GF744@turion.vk2pj.dyndns.org> References: <20060524180802.GA59176@central.0xfce3.net> <200605250517.12054.max@love2party.net> <20060525104000.GA4962@central.0xfce3.net> <20060525115447.GB724@turion.vk2pj.dyndns.org> <17525.55617.272397.806798@grasshopper.cs.duke.edu> <20060526133017.224cff08@Magellan.Leidinger.net> <20060526201452.GF744@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Peter Jeremy <peterjeremy@optushome.com.au> (Sat, 27 May 2006 06:14:52 +1000): > On Thu, 2006-May-25 12:40:00 +0200, Gordon Bergling wrote: > >patch doesn't touch any arch !i386 and derivates, so I don't see any reason > >why it shouldn't be included. > > On Fri, 2006-May-26 13:30:17 +0200, Alexander Leidinger wrote: > >The current code is a maze of assembly and macros, the new one is > >straight forward C and a little bit of assembly. And the new one is > >also known to work in DragonFlyBSD. Do you expect *this* code to act > >differently between FreeBSD and DragonFlyBSD? > > I don't expect the code itself to act differently. But I don't know > if FreeBSD and DragonFlyBSD have different expectations of the code - > probably they don't but someone (the proponent of the change) needs to > confirm this. They feed the same input to the code and expect the same output as we do. > >What's the technical backing of your preference to stick with the > >current code? How does the technical backing of your preference compare > >to the technical arguments I presented in this thread regarding the > >priority of the arguments? > > I was responding to Gordon's comments above. If the code is better and > there _are_ technical arguments for FreeBSD to use it, then we should. It contains less buggy assembly code which may break with newer gcc optimizations and already breaks with existing optimizations in the Intel C compiler. The folks at Intel investigated it and told me it's not because of a bug in icc, but because of the assembly code. It doesn't tell the compiler the right things, so the compiler is using wrong invariants for some optimizations (the gcc version we use either doesn't do those optimizations (yet), or does not make full use of those invariants (yet)). Bye, Alexander. -- Selling GoodYear Eagle F1 235/40ZR18, 2x 4mm + 2x 5mm, ~150 EUR you have to pick it up between Germany/Saarland and Luxembourg/Capellen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060527002840.35ebf26e>