Hubert Feyrer wrote:

>
> On Mon, 11 Apr 2005, Dmitri Nikulin wrote:
>
>> I think he invalidated himself when he said:
>> "The other kernel only included the i686 definition, making it specific
>> to Pentium III processors or higher."
>>
>> I can only assume that this is the kind of thing Hubert was talking
>> about when his blog mentioned "Aaah, the joy of people who have no idea
>> of what they're writing about still being bold enough to write about
>> things they have no idea about."
>
>
> I'd appreciate it if you would not cite me completely out of context
> to support your flames. I recommend you go back and read the article
> about which I wrote what you cite.
>
Well sorry, and I actually did re-read the article just in case, but
figured if you could say that about someone making a 'hearing error'
(only thing I can call it: converting 'cryptographic' to 'cryptic
graphic' isn't really a typo), me saying the same thing about someone
not knowing processor base instructions isn't a far stretch.

> FWIW, I think Tony definitely knows a fair bit about what he's
> writing, and maybe you should start think about how NetBSD could make
> things easier to do what he really wanted (add cpu-specific compiler
> flags).

makeoptions COPTS is pretty easy, if he wants to do it just for a
specific kernel compile. But evidently that kind of micro-optimization
didn't make a big enough difference for him. The only x86 processor that
has impressed me with how much it benefits from optimisation is the
Pentium M, and I doubt that's what he was using. That's just my personal
experience so I'm not making a big sweeping claim...

>
> Indeed. If you want to start changing things for the better
> -> http://www.netbsd.org/contrib/howto.html (patches preferred :)

I wouldn't know the first (useful) thing about kernel performance,
definitely nothing that hasn't been implemented before better than I
could. I'm dominantly a user-land programmer. The only kernel patch I
have ever submitted was a compile error fix for FreeBSD 5-current
shortly before 5.3. The best thing I could think of myself doing for
NetBSD right now is writing an alternative ftp-proxy built directly on
kqueue and independent of inetd, for those who want a maximally
efficient ftp-proxy for a dedicated gateway. Most would say the small
benefits aren't worth the cvs import, though, even if it's a feature
addition to the existing ftp-proxy. But if you think otherwise I could
take a look at it anyway.

But what can I say? Maybe it's time to start looking at how Linux does
things. It appears to be an industry leader in micro performance. It's
not like Linux hasn't copied the BSDs earlier in history. And if it can
be done without sacrificing cleanliness, correctness and stability (and
of course portability), it won't interfere with NetBSD's goals. But we
might not get far just poking through everything in the kernel and
sysctl until we find something that only might be part of the problem
(but then crashes when someone else tries it?).

>  - Hubert
>
-Dmitri