[Haskell-cafe] Re: Joels Time Leak

Sebastian Sylvan sebastian.sylvan at gmail.com
Tue Jan 3 11:53:09 EST 2006


On 1/3/06, Simon Marlow <simonmar at microsoft.com> wrote:
> On 03 January 2006 15:37, Sebastian Sylvan wrote:
>
> > On 1/3/06, Simon Marlow <simonmar at haskell.org> wrote:
> >> Tomasz Zielonka wrote:
> >>> On Thu, Dec 29, 2005 at 01:20:41PM +0000, Joel Reymont wrote:
> >>>
> >>>> Why does it take a fraction of a second for 1 thread to unpickle
> >>>> and several seconds per thread for several threads to do it at the
> >>>> same time? I think this is where the mistery lies.
> >>>
> >>>
> >>> Have you considered any of this:
> >>>
> >>> - too big memory pressure: more memory means more frequent and more
> >>>   expensive GCs, 1000 threads using so much memory means bad cache
> >>> performance - a deficiency of GHC's thread scheduler - giving too
> >>>   much time one thread steals it from others (Simons, don't get
> >>>   angry at me - I am probably wrong here ;-)
> >>
> >> I don't think there's anything really strange going on here.
> >>
> >> The default context switch interval in GHC is 0.02 seconds, measured
> >> in CPU time by default.  GHC's scheduler is stricly round-robin, so
> >> therefore with 100 threads in the system it can be 2 seconds between
> >> a thread being descheduled and scheduled again.
> >
> > According to this:
> > http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-using-parallel.html#parallel-rts-opts
> >
> > The minimum time between context switches is 20 milliseconds.
> >
> > Is there any good reason why 0.02 seconds is the best that you can get
> > here? Couldn't GHC's internal timer tick at a _much_ faster rate (like
> > 50-100µs or so)?
>
> Sure, there's no reason why we couldn't do this.  Of course, even idle Haskell processes will be ticking away in the background, so there's a reason not to make the interval too short.  What do you think is reasonable?

Not sure. Could it be configurable via a command line flag? If the
profiler could report the % of time spent doing context switches (or
maybe it already does?) the user could fine tune this to his liking.

For the (hypothetical) real-time simulation app I would *guess* that
something along the lines of 500µs would be more than enough to not
introduce any unnecessary lag in rendering (seeing as the target frame
time would be around 15ms, and you'd want to have a good amount of
context switches to allow some of the next frame to be computed in
parallell to all the render-surface optimizations etc. for the current
frame).

But then again, there may be other apps which need it to be even
lower.. So a command line flag sure would be nice.

/S

--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862


More information about the Haskell-Cafe mailing list