<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Claude,</p>
<p>Building with llvm is an excellent idea. I see the same 4x
performance improvement that you noted. I also tried building the
benchmarks with and without the '-threaded' option and saw no
difference in run times. Perhaps the threaded gc issues are
behind us.</p>
<p>I'll incorporate your changes into the repo on GitHub. Thank
you.</p>
<p>If the obvious deficiencies have been fixed by building with
llvm, then the next place to look for improvement is the matrix
multiplication. I profiled the test last night and have not
digested the results, but matrixMultiply still stands out as
taking a lot of time.</p>
<p>Best Wishes,</p>
<p>Greg<br>
</p>
<br>
<div class="moz-cite-prefix">On 8/2/18 11:29 PM, Claude
Heiland-Allen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:19e48f5b-4e29-79cd-6a0a-4f48f54ca2a2@mathr.co.uk">Hi
Gregory,
<br>
<br>
On 03/08/18 01:16, Gregory Wright wrote:
<br>
<blockquote type="cite">That's an interesting point. Could the
generation of the random matrix be that slow? Something to
check.
<br>
</blockquote>
It's not that it's slow by itself, I think it's that the CAF mVals
::[Double] is retained, taking ~40MB of heap which slows down GC.
<br>
<br>
Using criterion's `env` isn't so hard, and gets a much nicer
looking heap profile graph. See new benchmark code attached.
<br>
<br>
Graphs:
<br>
<a class="moz-txt-link-freetext" href="https://mathr.co.uk/tmp/luSolve-bench.svg">https://mathr.co.uk/tmp/luSolve-bench.svg</a>
<br>
<a class="moz-txt-link-freetext" href="https://mathr.co.uk/tmp/luSolve-bench-env.svg">https://mathr.co.uk/tmp/luSolve-bench-env.svg</a>
<br>
<br>
<blockquote type="cite">
<br>
On 8/2/18 7:47 PM, Vanessa McHale wrote:
<br>
<blockquote type="cite">Looking at your benchmarks you may be
benchmarking the wrong thing. The function you are
benchmarking is runLUFactor, which generates random matrices
in addition to factoring them.
<br>
<br>
On 08/02/2018 05:27 PM, Gregory Wright wrote:
<br>
<blockquote type="cite">benchmarking LUSolve/luFactor 1000 x
1000 matrix
<br>
<br>
time 1.940 s (1.685 s .. 2.139 s)
<br>
0.998 R² (0.993 R² .. 1.000 R²)
<br>
mean 1.826 s (1.696 s .. 1.880 s)
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
I started at mean 1.50s with your code.
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
std dev 93.63 ms (5.802 ms .. 117.8 ms)
<br>
variance introduced by outliers: 19% (moderately inflated)
<br>
<br>
</blockquote>
</blockquote>
</blockquote>
<br>
Making the `env` change and compiling with -fllvm (as suggested in
#haskell on irc.freenode.net, for a 4x speed boost) brought my
time for that benchmark to mean 257ms. +RTS -s tells me
productivity is 99.1%, which is pretty high.
<br>
I compiled the benchmark by hand for best speed, as cabal seems to
add -prof which slows the bench down slightly.
<br>
I also compiled without -threaded, because the code isn't
parallelized afaict, and parallel GC can be a bottleneck (is this
still true?).
<br>
<br>
<br>
Claude
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a>
Only members subscribed via the mailman list are allowed to post.</pre>
</blockquote>
<br>
</body>
</html>