<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">I do not understand what the purpose of this benchmark is.</div><div class="gmail_default" style="font-family:monospace,monospace">For example, I get the following times with data generated</div><div class="gmail_default" style="font-family:monospace,monospace">by generate.m:</div><div class="gmail_default" style="font-family:monospace,monospace">Python3  : 122 seconds</div><div class="gmail_default" style="font-family:monospace,monospace">C        : 226 seconds (topsender.c, gcc cranked up high)</div><div class="gmail_default" style="font-family:monospace,monospace">C        : 218 seconds (topsender.c, PGI cc cranked up high)</div><div class="gmail_default" style="font-family:monospace,monospace">AWK      :  46 seconds (mawk 1.4, NOT using a regexp for parsing)</div><div class="gmail_default" style="font-family:monospace,monospace">Smalltalk: 113 seconds (astc -O2, hash tables implemented in Smalltalk)</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Picking the top k by sorting n items is not a terribly efficient method.</div><div class="gmail_default" style="font-family:monospace,monospace">The Smalltalk version uses a heap of k items and the AWK version does</div><div class="gmail_default" style="font-family:monospace,monospace">something similar.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 20 Jun 2019 at 20:18, Julian Fondren <<a href="mailto:jfondren@hostgator.com">jfondren@hostgator.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Howdy,</div><div><br></div><div>I've added Mercury to a benchmark at <a href="https://github.com/jrfondren/topsender-bench" target="_blank">https://github.com/jrfondren/topsender-bench</a> , the task: run a regex over a 400 MB logfile, count email senders (as matched by the regex) and report the top 5 senders with their counts. I don't have a good sanitized logfile to use so this test isn't reproducible at the moment unless you have your own exim logs, sorry.</div><div><br></div><div>The Mercury code I've written is using PCRE for the actual regex matching (by linking pcre_d_shim.o, the same code I wrote to speed up the D candidates for this benchmark, earlier), the io module to read lines from the log, and the hash_table module to count senders.</div><div><br></div><div>On this benchmark, Mercury's about 5x slower than the reference C version, or only 1.4x as slow as the Python3 version. Mercury's memory usage is pretty disappointing; I experimented with adding some manual calls to the GC on every Nth match, and that could shave off dozens of MB, but at a significant runtime cost.</div><div><br></div><div>The need for `with_type` in the following code really surprised me, but... as of writing this email, I finally get it: ordering() is so generic that it could be asked to compare two curried predicate snd()s, rather than two ints that the func snd() returns.</div><div><pre style="color:rgb(0,0,0);white-space:pre-wrap">  :- func cmp(pair(string, int), pair(string, int)) = comparison_result.
  cmp(A, B) = ordering(snd(B) `with_type` int, snd(A) `with_type` int).</pre></div><div>This is all with asm_fast.gc. I get a segfault when I compile with hlc.gc. ltrace (library trace, not strace) shows that the SIGSEGV happens at</div><div><br></div><div>mercury__hash_table_search_3_p_0(0x608ce0, 0x608b40, 0x440000002d, 0x7f638d2c1fe0 <no return ....></div><div>--- SIGSEGV (Segmentation fault)</div><div><br></div><div>*** Mercury runtime: caught segmentation violation ***</div><div>cause: address not mapped to object</div><div>address involved: 0x4400000045</div><div><br></div><div>which is the very first call to hash_table.search in the program. I'd like to troubleshoot this further, but I don't have any debugging hlc grades. Right now I only have the default libgrades installed, but I still have the compilation environment from the install hanging around. Is there an easy way to go back there and say "compile and install this one additional libgrade" without rebuilding everything?</div><div><br></div><div><br></div><div>If I were to iterate further on the Mercury candidate, I'd start with a more optimal file handling, say with a "Applies the given closure to each regex match against lines from the input file" routine, that could delay allocating memory for strings until the regex succeeds.</div><div><br></div><div>Cheers.</div></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@lists.mercurylang.org" target="_blank">users@lists.mercurylang.org</a><br>
<a href="https://lists.mercurylang.org/listinfo/users" rel="noreferrer" target="_blank">https://lists.mercurylang.org/listinfo/users</a><br>
</blockquote></div>