Read the discussion on k-nucleotide benchmark in debian shootout (http://groups.google.com/group/comp.lang.lisp/msg/d50c86053c9000b7) and decided to play with it a little: to use as hash-table keys numbers in base 4 instead of gene strings. That gave a speed gain of around 30%: http://shootout.alioth.debian.org/u32q/benchmark.php?test=knucleotide&lang=sbcl&id=3.
But still 12 times slower, than the C++ variant. Perhaps native strings (instead of full unicode) would have given 2-2.5 times additional speedup. But what else can be improved?
The only things that needs improvements are the benchmark rules. How about they state the problems and don't impose the constraints on the solutions?
ReplyDeleteThis goes in, that goes out. We'll measure the speec of execution and memory usage.
So when someone uses a better algorithm the other languages will need to reimplement it or make up something else to match it. Now the only ones with chance to win are judges pets.
That was discussed thoroughly in the thread, I've linked to. There's also a good post on the same topic (but about the mandlebrot benchmark): http://skas-blog.blogspot.com/2009/06/lies-damn-lies-and-benchmarks.html
ReplyDeleteStill I was interested in what can be done to improve SBCL's performance, if you play by the rules, no matter how skewed they were. :) It's interesting to actually try to use SBCL without Unicode and see, how big an improvement it can get you (and maybe I'll get to it eventually).