Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Sep 2009 04:33:08 -0700 (PDT)
From:      Barney Cordoba <barney_cordoba@yahoo.com>
To:        peterjeremy@acm.org
Cc:        freebsd-net@freebsd.org
Subject:   Re: [POLLING] strange interrupt/system load
Message-ID:  <518979.77721.qm@web63907.mail.re1.yahoo.com>
In-Reply-To: <20090915073830.GC48679@server.vk2pj.dyndns.org>

next in thread | previous in thread | raw e-mail | index | archive | help
=0A=0A--- On Tue, 9/15/09, peterjeremy@acm.org <peterjeremy@acm.org> wrote:=
=0A=0A> From: peterjeremy@acm.org <peterjeremy@acm.org>=0A> Subject: Re: [P=
OLLING] strange interrupt/system load=0A> To: "Barney Cordoba" <barney_cord=
oba@yahoo.com>=0A> Cc: freebsd-net@freebsd.org=0A> Date: Tuesday, September=
 15, 2009, 3:38 AM=0A> On 2009-Sep-13 07:19:24 -0700, Barney=0A> Cordoba <b=
arney_cordoba@yahoo.com>=0A> wrote:=0A> >64bits must be faster than 32bits =
is patently=0A> misguided. My rule of =0A> >thumb is that if I don't need 6=
4bits for something, I=0A> avoid it.=0A> =0A> It's not quite that cut-and-d=
ry.=A0 The 64-bit ISA is=0A> significantly=0A> different to the 32-bit ISA =
and has different subroutine=0A> calling=0A> conventions.=A0 Yes, you do ne=
ed to lug 64-bit pointers=0A> around but the=0A> overall codesize is compar=
able (looking at /usr/bin and=0A> /lib suggests=0A> about a 5% increase in =
size going from i386 to amd64) - a=0A> lot of this=0A> is probably because =
amd64 has a 16-bit offset mode so=0A> there's much=0A> less need for 32-bit=
 offsets.=A0 Having twice as many=0A> registers is a=0A> win in some areas =
(less spilling to memory) and a loss in=0A> others (more=0A> state to save/=
restore on a context switch).=0A> =0A> If performance is critical, it's pro=
bably worthwhile=0A> benchmarking=0A> both i386 and amd64 variants and seei=
ng which works best=0A> for you.=0A> =0A"Rules of Thumb" are generally for =
those times when you don't have=0Aa pressing preference and you don't want =
to spend your life endlessly=0Abenchmarking.=0A=0AI don't think its the cod=
e, necessarity, but rather the significant=0Aincrease in the size of data s=
tructures, and the memory that has to=0Abe moved around.=0A=0AI haven't tri=
ed with the latest compiler but I can't see why it would=0Ahave any benefit=
 for systems used for high capacity networking other than=0Aincrementing co=
unters. =0A=0ABarney=0A=0A=0A      




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?518979.77721.qm>