Date: Fri, 25 Jan 2008 12:06:09 -0700 (MST) From: "M. Warner Losh" <imp@bsdimp.com> To: grehan@FreeBSD.ORG Cc: yanegomi@gmail.com, perforce@FreeBSD.ORG, marcel@FreeBSD.ORG Subject: Re: PERFORCE change 133911 for review Message-ID: <20080125.120609.87794284.imp@bsdimp.com> In-Reply-To: <479A17AC.4070004@freebsd.org> References: <4798C436.6090904@gmail.com> <20080125.100006.-262784007.imp@bsdimp.com> <479A17AC.4070004@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <479A17AC.4070004@freebsd.org>
Peter Grehan <grehan@freebsd.org> writes:
: > I'd rather hoped to run the Cisco stuff using EABI, which doesn't need
: > fp emulation in the kernel...
:
: EABI to my mind only helps in ultra-tight embedded environments, which
: I don't think exist anymore. 8-byte vs 16-byte stack alignment isn't
: going to help anyone.
:
: And if embedded environments are using a lot of soft-float, they are
: running on the wrong type of CPU. Trapping to the kernel should be
: infrequent, and it does allow a single ABI for all processor types.
I've deployed arm binaries that did to a lot of floating point from
time to time, and trapping to the kernel for all of it would have made
things a lot slower. These are floating point intensive applications,
but in some crude tests that I did I found that the CPU usage jumped
from approx 10% for the base system to 25% when I tried go get the
floating point emulator in place. The numbers it produced were wrong
(I tried to hack the NetBSD binary-only arm one and was only
marginally successful), but thought they would be typical of a working
implementation. Of course, since I tossed all this work, I can't be
sure that I wasn't doing something stupid in the kernel to account for
it.
So while in theory it shouldn't be a big cost, the application I was
just working on it made a huge difference. The applications that are
being pushed into these parts are also growing in sophistication.
Ours did on the order of 500 floating point operations per second, so
it was high enough that the overhead of traps was very noticeable.
Anyway, different processor, so the trade offs may be different here.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080125.120609.87794284.imp>