spscq perf - disable GC
spscq perf - disable GC

Fixes github issue #2

During perf test runs, under Golang 1.7, we are seeing

    runtime: nelems=73 nfree=0 nalloc=73 previous allocCount=1
nfreed=65464
    fatal error: sweep increased allocation count

    runtime stack:
    runtime.throw(0xd750a, 0x20)
            /Users/fmstephe/golang/go/src/runtime/panic.go:566 +0x95
    runtime.(*mspan).sweep(0x18cbe0, 0x1100000000, 0xc400000001)
            /Users/fmstephe/golang/go/src/runtime/mgcsweep.go:287 +0x7ab
    runtime.sweepone(0x35386)
            /Users/fmstephe/golang/go/src/runtime/mgcsweep.go:112 +0xfe
    runtime.gosweepone.func1()
            /Users/fmstephe/golang/go/src/runtime/mgcsweep.go:124 +0x2b
    runtime.systemstack(0x147a00)
            /Users/fmstephe/golang/go/src/runtime/asm_amd64.s:298 +0x79
    runtime.mstart()
            /Users/fmstephe/golang/go/src/runtime/proc.go:1079

It is clear that as of 1.7 Golang performs much more detailed checking,
closing the scope of tricks you can play with unsafe.

By creating `unsafe.Pointer` values which point to memory which almost
certainly hasn't been allocated

    func getValidPointer() uintptr {
            intVal := 0
            return uintptr(unsafe.Pointer(&intVal))
    }

combined with

    unsafe.Pointer(uintptr(t) + ptr)

we get `unsafe.Pointer` values pointing into 'thin air'. This confuses
the GC when it finds values which were never allocated.

The solution chosen here is to simply turn off the garbage collector.

This does not feel like a very good solution in the long term. The next
step is to find an approach to performance testing which does not lean
on the unsafe package.

fmstephe/flib