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@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@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>
>
>
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>



_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe




--
Alberto.