Date: 25 Apr 1998 15:51:48 -0700 From: Christoph Toshok <toshok@Hungry.COM> To: freebsd-hackers@FreeBSD.ORG Subject: Re: threads performance Message-ID: <m290otv7jv.fsf@terror.hungry.com> In-Reply-To: jb@cimlogic.com.au's message of 25 Apr 1998 15:35:07 -0700 References: <m23ef2vzca.fsf@terror.hungry.com> <199804252229.IAA01976@cimlogic.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
jb@cimlogic.com.au (John Birrell) writes: > > 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. but the JDK port for freebsd and netscape's NSPR also implement pre-emptive user-threads (well, I don't really know if the JDK does, but NSPR does.) and they are much faster than the freebsd version. time to gprof japhar again, so I can give some actual numbers and see what seems to be bogging things down. > 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 a possibility, but the majority of writing being done by japhar is not a character at a time. still, the locking is obviously slowing it down *someplace*. > 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? actually, the performance problem I'm seeing isn't in mozilla at all. All you need to do is download japhar (ftp.hungry.com/pub/hungry/japhar/current) and configure it like this (replace /usr/local/jdk1.1.5 with wherever you've got the 1.1.5 JDK installed) LDFLAGS='-L<path to libnspr21.so.1.0>' CFLAGS='-g -I<path to nspr includes>' configure --with-sun-jdk=/usr/local/jdk1.1.5 --enable-nspr and compile it. this will give you the fast one. if you want the slow one, just rm your config.cache and run configure --with-sun-jdk=/usr/local/jdk1.1.5 go to ../testsuite/java.io and run javac -verbose IsAbsoluteTest.java. I see ~39 seconds with libc_r and ~18 with NSPR. christoph 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?m290otv7jv.fsf>