[Haskell-cafe] First call to putStr takes far more time than subsequent calls

[Alberto G. Corona]

the C allocation functions (malloc etc) spend significantly more time in
the first invocation. That may be related with this behaviour in libgmp, IO
etc

2015-07-10 9:31 GMT+02:00 Roman Cheplyaka <roma at ro-che.info>:

> I considered that, but it doesn't seem to hold up. If you replace
> calling the Fixed functions with some operations on Integers, you won't
> reproduce the effect.
>
> On 10/07/15 10:17, Jonas Scholl wrote:
> > If you look at the Fixed data type, it is implemented using the Integer
> > type, which is again implemented using libgmp on my system. The first
> > call to any function involving an Integer type thus needs to initialize
> > libgmp first. Using ltrace it seems like libgmp first has to determine
> > the processor it is running on and maybe set up other bookkeeping
> > information.
> >
> > It could also be the case that libgmp itself has to be loaded at this
> > point. Using strace it looks like it is mmapped into the memory, maybe
> > linux is lazy and only reads the file on the disk at the moment it is
> > accessed the first time (i.e. at the first call)? At least linux uses a
> > similar approach for requested memory by a program.
> >
> > On 07/10/2015 01:45 AM, Roman Cheplyaka wrote:
> >> This is a nice puzzle. However, I don't think it's related to IO.
> >>
> >> So far I've traced this to Data.Fixed methods. If you add
> >>
> >>   evaluate $ floor (2/1 :: Fixed E12)
> >>
> >> before the loop, you'll find that the delay decreases significantly
> >> (although doesn't vanish entirely).
> >>
> >> How is this related to forcing a time value? Well, UTCTime represents
> >> the time of day as Fixed E12, and when you're evaluating the result of
> >> getCurrentTime, you're calling those methods, (/) and floor.
> >>
> >> Using other methods of Fixed E12 before the loop, or replacing E12 with
> >> E9, kills or at least hurts the effect.
> >>
> >> There might be some thunks referenced directly or indirectly by those
> >> methods, possibly involving specialization, but I don't see it so far.
> >>
> >> I'll let someone else to take it from here.
> >>
> >>
> >> On 10/07/15 00:07, Ben Gunton wrote:
> >>> Here is the same thing with no console usage, just forcing the time
> >>> value. The first-iteration-delay seems to happen at the first IO-ish
> >>> thing being evaluated.
> >>>
> >>> http://lpaste.net/136254
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >>
> >
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> >
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>


-- 
Alberto.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150710/7c3ed8d0/attachment-0001.html>