<div dir="ltr"><div>I did not fully compare the implementation, I just focussed on getting as much performance out of the Haskell implementation as was possible. I can say two things that might have allowed it to be better:</div><div><br></div><div>1) I extracted as much as was possible in terms of implementation efficiency of the Haskell code. So I did not lose there. The code could have been much simpler without all the optimizations.</div><div><br></div><div>2) My implementation may be better in terms of algorithms and data structures used. Unicode normalization is complicated, the implementation can differ in many ways making you lose or gain performance.</div><div><br></div><div>Beating the utf8proc implementation was easy. The best (highly optimized) normalization implementation is the ICU C++ implementation and my target was to get close to that. I got pretty close to it (using llvm backend) in most benchmarks and even beat it clearly in one benchmark. There are a couple of enhancements that I filed against GHC, hopefully they will allow it to be completely at par in all benchmarks. Though the difference may not matter other than proving that it can be as good.</div><div><br></div><div>-harendra</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 October 2016 at 22:36, William Yager <span dir="ltr"><<a href="mailto:will.yager@gmail.com" target="_blank">will.yager@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Interesting! What would you say allowed you to get better decompose performance than the C library?<div><br></div><div>Will</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Tue, Oct 25, 2016 at 11:59 AM, Harendra Kumar <span dir="ltr"><<a href="mailto:harendra.kumar@gmail.com" target="_blank">harendra.kumar@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>Hi,</div><div><br></div>I released unicode-transforms sometime back as bindings to a C library (utf8proc). Since then I have rewritten it completely in Haskell. Haskell data structures are automatically generated from unicode database, so it can be kept up-to-date with the standard unlike the C implementation which was stuck at unicode 5. The implementation comes with a test suite providing 100% code coverage.<div><br></div><div>After a number of algorithmic and implementation efficiency optimizations, I was able to get several times better decompose performance compared to the C implementation. I have not yet got a chance to fully optimize the compose operations but they are still as fast as utf8proc.<div><br></div><div>I would like to thank Antonio Nikishaev for the unicode character database parsing code which I borrowed from the prose library.</div><div><br></div><div><a href="https://github.com/harendra-kumar/unicode-transforms" target="_blank">https://github.com/harendra-ku<wbr>mar/unicode-transforms</a><br></div><div><a href="https://hackage.haskell.org/package/unicode-transforms" target="_blank">https://hackage.haskell.org/pa<wbr>ckage/unicode-transforms</a><span class="m_4844648040314069033HOEnZb"><font color="#888888"><br></font></span></div><span class="m_4844648040314069033HOEnZb"><font color="#888888"><div><br></div><div>-harendra</div></font></span></div></div>
<br></div></div>______________________________<wbr>_________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/haskell-caf<wbr>e</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>
</blockquote></div><br></div>