Date: Mon, 16 Feb 2004 18:33:04 -0000 From: "Steven Hartland" <killing@multiplay.co.uk> To: "Kris Kennaway" <kris@obsecurity.org>, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no> Cc: Juan Tumani <jtumani55@hotmail.com> Subject: Re: FreeBSD 5.2 v/s FreeBSD 4.9 MFLOPS performance (gcc3.3.3 v/s gcc2.9.5) Message-ID: <031a01c3f4bb$50b1d800$b3db87d4@multiplay.co.uk> References: <BAY12-F37zmBUw7MurD00010899@hotmail.com><20040214082420.GB77411@nevermind.kiev.ua><xzpvfm8yssm.fsf@dwp.des.no> <200402160352.16477.wes@softweyr.com><20040216035412.GA70593@xor.obsecurity.org> <xzpn07i28u3.fsf@dwp.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
Some interesting finding there what if any are the impacts for
performance in real life applications?
Steve
----- Original Message -----
From: "Dag-Erling Smørgrav" <des@des.no>
Kris Kennaway <kris@obsecurity.org> writes:
> On Mon, Feb 16, 2004 at 03:52:16AM -0800, Wes Peters wrote:
> > Should I commit this?
> What effect does it have on non-i386 architectures?
It can't possibly hurt. If the stack is already aligned on a "better"
boundary (64 or 128 bytes), it is also aligned on a 32-byte boundary
since 64 and 128 are multiples of 32, and the patch is a no-op. If
only a 16-byte alignment is required, a 32-byte alignment wastes a
small amount of memory but does not hurt performance. I believe that
less-than-16 (and possibly even less-than-32) alignment is pessimal on
all platforms we support.
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137
or return the E.mail to postmaster@multiplay.co.uk.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?031a01c3f4bb$50b1d800$b3db87d4>