From owner-freebsd-smp Tue Nov 10 01:09:17 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id BAA29410 for freebsd-smp-outgoing; Tue, 10 Nov 1998 01:09:17 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.15.68.22]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id BAA29401; Tue, 10 Nov 1998 01:09:13 -0800 (PST) (envelope-from bde@godzilla.zeta.org.au) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.7/8.8.7) id UAA23868; Tue, 10 Nov 1998 20:08:50 +1100 Date: Tue, 10 Nov 1998 20:08:50 +1100 From: Bruce Evans Message-Id: <199811100908.UAA23868@godzilla.zeta.org.au> To: bde@zeta.org.au, peter@netplex.com.au Subject: Re: Dog Sloooow SMP Cc: current@FreeBSD.ORG, jc@irbs.com, mike@smith.net.au, narvi@haldjas.folklore.ee, smp@FreeBSD.ORG Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> >How about 64 for the odd case that K7 actually materialises as promised >> >and people start putting them in dual motherboards? >> >> That would be almost twice as slow for CC=gcc. CC=egcs handles 64-bit >> bit tests better, especially for the low 32 bits. > >32 vs. 64 is almost irrelevant.. There's no limit to the number of 32 bit >variables that we can use with flags in them, so there's no reason why >we'd use a 64 bit variable in the first place. It's easier and potentially faster to keep all the flags in a single (scalar) variable. >However.. One thing that bugs me is that we presently can optimize out >code and tests for a runtime boost when compiled for a specific cpu. eg: >if we support 386 cpus, we test for whether we have an invlpg instruction >or not - but if we are not compiling with a 386 option then this code and >the test for >= 486 goes away. Attempt to keep compile-time options and tests when they make a difference. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message