Date: Thu, 18 Dec 1997 20:35:31 +0000 (GMT) From: Doug Rabson <dfr@nlsystems.com> To: "Russell L. Carter" <rcarter@consys.com> Cc: dyson@freebsd.org, Alex <garbanzo@hooked.net>, current@freebsd.org Subject: Re: Pentium optimizations Message-ID: <Pine.BSF.3.95q.971218203252.755C-100000@herring.nlsystems.com> In-Reply-To: <199712171542.IAA09962@dnstoo.consys.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Dec 1997, Russell L. Carter wrote: > }Alex said: > }> > }> The response(s) I got to my "I'm a newbie, anyone know about this problem" > }> was basically met with "well no FreeBSD developers have contacted us, and > }> if they did we'd accept/commit/whatever some changes..". > }> > }I expected that they would be cooperative (the EGCS group appears to be > }culturally similar to us (modulo-GPL).) John Polstra is really our > }most active ELF/Compiler person, and so he would likely be a better > }"official FreeBSD" interface. He is also less politically likely to > }insert his foot into his eating orifice. I do have some PPro mods, > }and they appear to help performance on average. The PPro is a > }really wierd creature (like the K6.) The darned processor does so > }much optimization, it appears to be insensitive to code mods. There are > ^^^^^^^^^^^^^^^^^^^^^^^^ > Noticed that too, eh? Recently I hacked up some of the SSLeay asm > code and while I could improve P5 performance about 30%, the best > that I could do, with a lot of effort was maybe 4% for PII and PPro. > The out-of-order execution seems to help a lot. Oh, and the P5 > specific asm actually makes the PPro slow down over the C source; > not good tidings for ye merry old tuners. > > }areas of reasonable payoffs, and lots of "obvious" optimizations that > }end up being neutral. > > Yep. I wouldn't worry too much about other people's claims about code > optimized for Pentium Pro. There are some odd things with PPro memory accesses. If you do a write to a location which isn't cached, the write is queued in a write buffer (assuming there is one free, otherwise you stall). If you then try to read any memory location, you stall till the write is completed. This is something to do with enforcing read/write ordering in SMP systems. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 951 1891 Fax: +44 181 381 1039
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.971218203252.755C-100000>