From owner-freebsd-hackers  Mon Mar 10 16:25:07 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id QAA11315
          for hackers-outgoing; Mon, 10 Mar 1997 16:25:07 -0800 (PST)
Received: from root.com (implode.root.com [198.145.90.17])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA11308
          for <hackers@freebsd.org>; Mon, 10 Mar 1997 16:25:05 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by root.com (8.8.5/8.6.5) with SMTP id QAA18376; Mon, 10 Mar 1997 16:24:49 -0800 (PST)
Message-Id: <199703110024.QAA18376@root.com>
X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol
To: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
cc: bde@zeta.org.au (Bruce Evans), bag@sinbin.demos.su, hackers@freebsd.org
Subject: Re: performance (was: 100 Mb/s cards) 
In-reply-to: Your message of "Mon, 10 Mar 1997 21:38:32 +0100."
             <199703102038.VAA27659@labinfo.iet.unipi.it> 
From: David Greenman <dg@root.com>
Reply-To: dg@root.com
Date: Mon, 10 Mar 1997 16:24:49 -0800
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>About the following performance issue:
>
>> >> been able to get it to work. The Pro/100B is well supported; it's what I'm
>> >> using in wcarchive and I haven't had any problems. It consumes about half
>> >> the CPU time that the de driver does and has about the same level of
>
>the kernel is generally compiled with -O , I guess because of fear
>of broken compiler optimizations. Would it be safe to compile
>selected parts (e.g. network driver...) of relatively stable code
>(so that an adequate test period could give confidence on its
>performance) in the kernel with a more aggressive optimization so
>as to improve performance of critical parts of the system ?

   I've never been able to measure a performance improvement by doing things
like this. For the kernel, higher optimization levels seem to have the only
effect of increasing compile time and reducing runtime stability. I suspect
this is because most of the time is spent copying things around, so whatever
minor gains that a couple of optimized instructions provide is well into the
noise.
   Regarding the difference in performance between the de and fxp drivers,
all I can say to this is that the code paths in the de driver are long and
complicated. It's entirely likely that they have to be this way for whatever
reason (I've not looked into improving it). The time reduction I measured with
the fxp driver was primarily %interrupt, but there is a reduction in system
time as well (too difficult to measure accuraterly on wcarchive, but perhaps
5-10%).

-DG

David Greenman
Core-team/Principal Architect, The FreeBSD Project