> > simonmar 2004/02/25 09:35:45 PST
> >
> > Modified files:
> > ghc/rts Schedule.c
> > Log:
> > Feeble performance hack for the threaded RTS: instead of
> > allocating/releasing a new condition variable for each
> new call-in,
> > we
> > just cache one in the RTS and re-use it for the next call.
>
> So now the non-threaded RTS doesn't build because there's an #ifdef
> missing (type Condition isn't defined). That's easy to fix.
> But the threaded RTS breaks on Mac OS X and probably on other
> pthreads
> platforms because the Condition type is _not_ a pointer but a struct
> and therefore can't be initialized to NULL.
Fixed now, it was a bit late in the day when I made that change :-(
> > On a little test I have here which does lots of call-ins
> on Windows,
> > this reduces the slowdown for using the threaded RTS from
> a factor of
> > 7-8 down to a factor of 4-5. I'm aiming for a factor of 2 or
> > better...
>
> I assume that test doesn't work without Visual Studio and therefore
> can't be run on other platforms?
> By the way, on Mac OS X, initCondition a.k.a.
> pthread_cond_init does no
> syscall and takes about fifteen instructions in total :-) .
The test works fine on other platforms (it's just a tight loop in C
calling a foreign exported 'return ()'), but I expect the performance
behaviour differs between platforms (as you mentioned), and Windows is
the platform I care about at the moment. I haven't measured the
overhead on Linux yet, but will do so later...
The test is running without any worker threads in the system. With a
worker thread I expect there to more overhead, because the worker will
be sitting in awaitEvent() with a capability, which it needs to hand
over to the thread doing the call-in. I'm planning to experiment with
releasing the capability before awaitEvent() if EMPTY_RUN_QUEUE.
Also, I'm not sure that the storage manager's mutex is required.
Instead, we could just assume that the storage manager is only available
to a thread with a Capability (or the garbage collector, which
notionally runs with a Capability).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
