On Wednesday, August 31, 2016 at 8:44:57 AM UTC-7, Eric Johnson wrote: > > > On 8/31/16 2:04 AM, Harald Weidner wrote: > > The Java counterpart of this benchmark does not use the Java build-in > > maps, but imports a map implementation for fixed data types from the > > fastutil project. > > > > http://fastutil.di.unimi.it/ > I hadn't noticed that. That would seem to violate the spirit of the test: > "The work is to use the built-in or library hash table implementation to > accumulate count values - lookup the count for a key and update the > count in the hash table. Don't optimize away the work." >
The description of k-nucleotide does specify that the use of third-party hash table libraries is allowed. See the http://benchmarksgame.alioth.debian.org/u64q/knucleotide-description.html#knucleotide : Some language implementations have hash tables built-in; some provide a > hash table as part of a collections library; some use a third-party hash > table library. (For example, use either khash > <http://attractivechaos.github.io/klib/> or CK_HT > <http://concurrencykit.org/doc/ck_ht_init.html> for C language > k-nucleotide programs.) The hash table algorithm implemented is likely to > be different in different libraries. > The work: > The work is to use the built-in *or library hash table* [emphasis mine] > implementation to accumulate count values - lookup the count for a key and > update the count in the hash table. I tried substituting my own offheap hashtable, open source/available at https://github.com/glycerine/offheap The version specialized for uint32->uint32 runs about 25% faster on my laptop. I submitted it here: https://alioth.debian.org/tracker/index.php?func=detail&aid=315482&group_id=100815&atid=413122 Jason -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
