Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 06 Apr 1998 07:42:07 +1000 (EST)
From:      Peter Jeremy <Peter.Jeremy@alcatel.com.au>
To:        hackers@FreeBSD.ORG
Subject:   H/W specific optimisations (was Re: bcopy implementation)
Message-ID:  <199804052142.HAA03666@gsms01.alcatel.com.au>

next in thread | raw e-mail | index | archive | help
On Fri, 3 Apr 1998 16:20:08 +0200 (CEST), Mikael Karpberg <karpen@ocean.campus.luth.se> wrote:
>According to Dave Marquardt:
>> > of not implementing this method in libc? 
>> 
>> Well, you said it yourself.  "On the assumption, that the system has
>> pentium processor...."  Well, we can't assume that, since FreeBSD runs
>> on 386s and up.
>
>Well, if you want everything to go faster, you optimize for the hardware
>you're actually gonna run on.

This is a fairly useful idea, although the suggested implementation:
>ifdefs so that you would add -DOPTIMIZE_FOR_PENTIUM to CFLAGS in make.conf
>and then make world.
is still processor-specific:  You need to do a `make world' for each
different processor type.

I'd like to suggest something along the lines that Sun does in Solaris
2.x: A directory tree /usr/platform contains all platform specific
code, including (optional) platform-specific shared libraries which
override the generic default library code.  At load-time, the
appropriate library is loaded (if it exists) by ld.so.

As an example, on sun4m machines (eg SPARCstation 5,10,20), there's no
platform specific library.  On the sun4u (UltraSPARC) machines, the
library includes __div64(), __mul64(), __rem64(), __udiv64(),
__umul64(), __urem64(), memcmp(), memcpy(), memmove(), memset().

This approach has the advantage that only the platform-specific functions
are in the library, so it's fairly small.

Obviously, this solution only works for shared executables, and isn't
quite as good as a compiling for a specific processor (because you can't
in-line what become trivial functions - like the 64-bit math functions
on the UltraSPARC).

The nicety about this approach is that there's no run-time overhead (at
least no more than for any other shared-library call).

Peter
--
Peter Jeremy (VK2PJ)                    peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St                          Phone: +61 2 9690 5019
ALEXANDRIA  NSW  2015                   Fax:   +61 2 9690 5247

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



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