/dev/dump

So I've been thinking about naming for my pure Go implementation of nanomsg 's SP protocols. nanomsg is trademarked by the inventor of the protocols.  (He does seem to take a fairly loose stance with enforcement though -- since he advocates using names that are derived from nanomsg, as long as its clear that there is only one "nanomsg".) Right now my implementation is known as "bitbucket.org/gdamore/sp".  While this works for code, it doesn't exactly roll off the tongue.  Its also a problem for folks wanting to write about this.  So the name can actually become a barrier to adoption.  Not good. I suck at names.  After spending a day online with people, we came up with " illumos " for the other open source project I founded.  illumos has traction now, but even that name has problems.  (People want to spell it "illumOS", and they often mispronounce it as "illuminos"  (note there are no "n"'s in illumos).  

I've added a benchmark tool to my Go implementation of nanomsg 's SP protocols, along with the inproc transport, and I'll be pushing those changes rather shortly. In the meantime, here's some interesting results: Latency Comparision (usec/op) transport nanomsg 0.3beta gdamore/sp inproc 6.23 8.47 ipc 15.7 22.6 tcp 24.8 50.5 The numbers aren’t all that surprising.  Using go, I’m using non-native interfaces, and my use of several goroutines to manage concurrency probably creates a higher number of context switches per exchange.  I suspect I might find my stuff does a little better with lots and lots of servers hitting it, where I can make better use of multiple CPUs (though one could write a C program that used threads to achieve the same effect). The story for throughput is a little less heartening though: Throughput Comparision (Mb/s) transport message size nanomsg 0.3beta gdamore/sp inproc 4k 4322 5551 ipc 4k 9470 2379 tcp 4

I'm pleased to announce that this past weekend I released the first version of my implementation of the SP (scalability protocols, sometimes known by their reference implementation, nanomsg ) implemented in pure Go . This allows them to be used even on platforms where cgo is not present.  It may be possible to use them in playground (I've not tried yet!) This is released under an Apache 2.0 license .  (It would be even more liberal BSD or MIT, except I want to offer -- and demand -- patent protection to and from my users.) I've been super excited about Go lately.  And having spent some time with ØMQ in a previous project, I was keen to try doing some things in the successor nanomsg project.   (nanomsg is a single library message queue and communications library.) Martin (creator of ØMQ ) has written rather extensively about how he wishes he had written it in C instead of C++.  And with nanomsg, that is exactly what he is done. And C is a great choice for implement