

Gnatsd: a high performance NATS messaging server written in Go - krobertson
https://github.com/apcera/gnatsd

======
DrJosiah
This is probably a bit off topic, but I notice that they implemented their own
hashmap with pluggable hash functions. Awesome in theory (and practice),
though I notice that the performance of their custom hash table is poorer than
Go's built-in hash map (Go's hashmap takes 1/2, 3/4, and 9/10th the time of
their hashmap for small, medium, and large keys, respectively - though this
could be related to the updated aes hash in Go, and that my processor supports
it).

While looking through the implementations, the Gnatsd hashmap implementation
is a simple table with buckets, where as the Go hashmap also uses a table with
buckets, though each "bucket" has 8 slots by default (and does subsequent
chaining). Go's chunking of buckets helps caches work better, reduces random
reads, and helps to minimize overhead (fewer pointers if you have fixed-size
data). Read the first 83 lines of
[http://golang.org/src/pkg/runtime/hashmap.c](http://golang.org/src/pkg/runtime/hashmap.c)
to see what good structure design and experimentation gets you.

Does someone have an example where a 'go test --bench="." -gcflags="-B"' call
in the gnatsd/hashmap path actually comes out ahead for the Gnatsd hashmap
using a recent Go?

~~~
krobertson
Derek's hashmap was faster than than Go 1.0's built in hashmap. With Go 1.1 or
1.1.1 (don't remember which one exactly), the standard one did become faster,
though Derek had decided to stick with it as is. I can ask him what the reason
was... I don't recall right now.

~~~
DrJosiah
I think I may know why they are sticking with the self-built version: random
key selection. The built-in hash map doesn't include a method to discover a
random key, but the gnatsd hashmap does.

------
clumsysmurf
At first glance, NATS looks similar in goal to MQTT. Can anyone describe the
differences?

~~~
jvoorhis
NATS is the pub-sub messaging protocol and implementation created by Derek
Collision, who architected the first iteration of Cloud Foundry. It is a
simple pub-sub service at its core, but the Ruby and NodeJS clients implement
various messaging patterns similar to what is supported by ZeroMQ. It is used
extensively within Cloud Foundry.

------
orenmazor
at first I definitely thought this was related to the old gnu bug tracker.

