[MLton-user] Performances: mlton 20030716p1 V.S. 20051202
Alexandre Langenieux
Alexandre.Langenieux@polyspace.com
Thu, 27 Jul 2006 18:09:12 +0200
--------------000901010206050001070908
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Stephen Weeks wrote:
>>We are currently running mlton-20030716p1 and we want to migrate to
>>the last version mlton-20051202.
>>
>>Unfortunately, we are facing some high performances regression using
>>this new release (something around 60%) compare to our current
>>version.
>>
>>We are compiling with the following options for mlton-20051202:
>>mlton -codegen native -const "Exn.keepHistory true" -verbose 2 \
>>
>>
>...
>
>
>>And for the version mlton-20030716p1:
>>mlton -cc-opt -D_UNIX -verbose 1 -text-io-buf-size 65536 \
>> -safe true -exn-history true -detect-overflow false -basis 1997 \
>>
>>
>...
>
>The one thing that jumps out at me is your use of exception history.
>The implementation of that has changed significantly since 20030716.
>It is now much more accurate, but causes a potentialy large slowdown
>(I could believe even 60%). It used to simply piggyback on exceptions
>as they got raised and handled and so gave a very incomplete view of
>the call stack. Now, it brings in the entire profiling infrastructure
>to keep track of every frame in the call stack. This inhibits
>optimizations, and even worse, walks the entire call stack at every
>raise (to collect the information for accurate history information).
>
>At this point and going forward, exception history should really only
>be used for debugging.
>
First thanks for your reactivity,
Ok, disabling the exception history management reduce the performances
loss,
but we do not return to our previous performances level.
For 2 significant tests, we run between 15% and 30% slower than before.
After quick analysis of binary parts that are slower, it seems (but not
yet sure
that parts that need more memory are slower (Are we swapping ? we do
not know yet, we need to track this).
Look for this times for an important part of our binary that may help:
mlton-2005 : took 15731real, 11800.4u + 258.6s (231.5gc)
mlton-2003 : took 13481.9real, 10301.8u + 277.7s (1890.1gc)
As you will notice, the time spent in GC for new mlton is quiet less than
2003 release, is it important ?
May you can need more informations, please ask us.
Thank you.
>
>
>
>>Does the fact to compile a big defunct sml file can change things on
>>performances instead of compiling files with mlb ?
>>
>>
>
>No, that shouldn't matter at all.
>
>
>Let us know if disabling exception history returns performance to the
>level you expect.
>
>_______________________________________________
>MLton-user mailing list
>MLton-user@mlton.org
>http://mlton.org/mailman/listinfo/mlton-user
>
>
--------------000901010206050001070908
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title></title>
</head>
<body>
<br>
<br>
Stephen Weeks wrote:<br>
<blockquote type="cite"
cite="mid17607.61012.329476.625443@eponym.sweeks">
<blockquote type="cite">
<pre wrap="">We are currently running mlton-20030716p1 and we want to migrate to
the last version mlton-20051202.
Unfortunately, we are facing some high performances regression using
this new release (something around 60%) compare to our current
version.
We are compiling with the following options for mlton-20051202:
mlton -codegen native -const "Exn.keepHistory true" -verbose 2 \
</pre>
</blockquote>
<pre wrap=""><!---->...
</pre>
<blockquote type="cite">
<pre wrap="">And for the version mlton-20030716p1:
mlton -cc-opt -D_UNIX -verbose 1 -text-io-buf-size 65536 \
-safe true -exn-history true -detect-overflow false -basis 1997 \
</pre>
</blockquote>
<pre wrap=""><!---->...
The one thing that jumps out at me is your use of exception history.
The implementation of that has changed significantly since 20030716.
It is now much more accurate, but causes a potentialy large slowdown
(I could believe even 60%). It used to simply piggyback on exceptions
as they got raised and handled and so gave a very incomplete view of
the call stack. Now, it brings in the entire profiling infrastructure
to keep track of every frame in the call stack. This inhibits
optimizations, and even worse, walks the entire call stack at every
raise (to collect the information for accurate history information).
At this point and going forward, exception history should really only
be used for debugging.</pre>
</blockquote>
First thanks for your reactivity,<br>
<br>
Ok, disabling the exception history management reduce the performances loss,
<br>
but we do not return to our previous performances level.<br>
For 2 significant tests, we run between 15% and 30% slower than before.<br>
<br>
After quick analysis of binary parts that are slower, it seems (but not yet
sure<br>
that parts that need more memory are slower (Are we swapping ? we do <br>
not know yet, we need to track this).<br>
<br>
Look for this times for an important part of our binary that may help:<br>
mlton-2005 : took 15731real, 11800.4u + 258.6s (231.5gc)<br>
mlton-2003 : took 13481.9real, 10301.8u + 277.7s (1890.1gc)<br>
As you will notice, the time spent in GC for new mlton is quiet less than<br>
2003 release, is it important ?<br>
<br>
May you can need more informations, please ask us.<br>
<br>
Thank you.<br>
<blockquote type="cite"
cite="mid17607.61012.329476.625443@eponym.sweeks">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Does the fact to compile a big defunct sml file can change things on
performances instead of compiling files with mlb ?
</pre>
</blockquote>
<pre wrap=""><!---->
No, that shouldn't matter at all.
Let us know if disabling exception history returns performance to the
level you expect.
_______________________________________________
MLton-user mailing list
<a class="moz-txt-link-abbreviated" href="mailto:MLton-user@mlton.org">MLton-user@mlton.org</a>
<a class="moz-txt-link-freetext" href="http://mlton.org/mailman/listinfo/mlton-user">http://mlton.org/mailman/listinfo/mlton-user</a>
</pre>
</blockquote>
<br>
</body>
</html>
--------------000901010206050001070908--