Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 26 Apr 1998 08:29:09 +1000 (EST)
From:      John Birrell <jb@cimlogic.com.au>
To:        toshok@Hungry.COM (Christoph Toshok)
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: threads performance
Message-ID:  <199804252229.IAA01976@cimlogic.com.au>
In-Reply-To: <m23ef2vzca.fsf@terror.hungry.com> from Christoph Toshok at "Apr 25, 98 05:51:33 am"

next in thread | previous in thread | raw e-mail | index | archive | help
Christoph Toshok wrote:
> On freebsd the performance is just abysmal.  Really, it's *awful*.
> Just for kicks, I ported the thread api to NSPR (Netscape's Portable
> Runtime) and the runtime for javac compiling a trivial .java file
> drops from 39 seconds to 18 seconds.

Implementing user-threads with a pre-emptive scheduler over a BSD
kernel with no special support requires the use of signals to cause
context switches. The thread library has to perform atomic operations
that require signals to be blocked. It is this blocking and unblocking
that affects performance in certain benchmarks.

The second area where performance takes a hit is with FILE locking
the way that POSIX specifies it. The worst case is that a fgetc()
will lock and unlock the FILE with each call. If you want performance
with FILE operations and you know that only one thread will be accessing
the file, then the unlocked versions of the stdio functions will restore
the lost performance. If the java VM implementation does it's own
locking at object level (like Sun's implementation does), then the
use of the unlocked stdio functions is a porting issue.

This is where the use of the FreeBSD mozilla CVS repository will
come in handy. Can you provide patches that will allow us to build the
same executables in which you see the performance hit?

Xig finally sold me Motif at the US domestic price so I can build now.

-- 
John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/
CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137

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?199804252229.IAA01976>