From owner-freebsd-hackers Tue Apr 14 11:52:41 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA13182 for freebsd-hackers-outgoing; Tue, 14 Apr 1998 11:52:41 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from att.com (cagw2.att.com [192.128.52.90]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id SAA13069 for ; Tue, 14 Apr 1998 18:52:20 GMT (envelope-from sbabkin@dcn.att.com) From: sbabkin@dcn.att.com Received: by cagw2.att.com; Tue Apr 14 14:47 EDT 1998 Received: from dcn71.dcn.att.com ([135.44.192.112]) by caig2.att.att.com (AT&T/GW-1.0) with ESMTP id OAA19694 for ; Tue, 14 Apr 1998 14:51:26 -0400 (EDT) Received: by dcn71.dcn.att.com with Internet Mail Service (5.0.1458.49) id <26DMMFQ8>; Tue, 14 Apr 1998 14:51:19 -0400 Message-ID: To: frank@our.domaintje.com, tarkhil@asteroid.svib.ru Cc: hackers@FreeBSD.ORG Subject: RE: SMP performance decrease? Date: Tue, 14 Apr 1998 14:51:15 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > ---------- > From: Alex Povolotsky[SMTP:tarkhil@asteroid.svib.ru] > > >> Execl thoughput 90.8 46.8 <- ??? > >> Pipe-based context switching 20.4 9.0 <- ??? > >> Shell scripts (8 concurrent) 12.8 12.2 <- ??? > > >> I don't understand why execl throughput and context switching is > TWICE > >> slower in SMP mode, and I doesn't understand AT ALL why shell > script > >> benchmark isn't twice faster. > > >I don't know Benchbyte, but maybe these are times in seconds and > >lower is better? Also, unless you have an automatic multi threading > No :-( > >compiler like Convex has the second cpu doesn't do you much good > These tests are trying to spawn more than one process, so compiler has nothing to do with it. > >if you only run one process in your benchmark. > Well, I can beleive if performance won't increase. But why can it > DECREASE? > Probably, synchronization overhead ? May be, not only in software, but also in hardware level. Also, if the processes are scheduled to the first available processor without trying to keep "processor locality", it may lead to lots of memory cache flushes. Serge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message