Hacker News Reader

Comment by pcwalton | Hacker News Reader

From the article:

> [Go] also has managed memory, so it looks safer and easier to use than C/C++.

But most of the post describes a sophisticated way to work around the garbage collector, totally reliant on a specific implementation detail of the current Go GC (skipping of pointer-free data types), documented in a GitHub issue. It seems easier to not have, or to not use, the GC in the first place for this specific project if most of the engineering effort is going to go into an elaborate workaround for it. In particular, I don't understand the reason for rejecting offheap: the article suggests "a cache which relied on those functions would need to be implemented", but surely this is less complex to implement than the cache that relies on hiding what are effectively pointers behind offsets so the GC won't think to scan them.

(This isn't a suggestion to not use Golang at all, to be clear. Nor do I mean to suggest that GCs are bad things in general.)

View on HN

Maybe this type of program is better suited for a language like Rust.

However, while not having a GC, you have to take care of all memory issues in a way that you convince the compiler that your won't ever blow up.

It would be very interesting to have such a comparison, so we could see whether it's easier to work around the GC, or easier to write bullet-proof code with manual memory management.

I'd expect the Rust to be more robust with regard to performance, but the question is: Would it also pay off in term of code complexity?

I don't want to argue specifically that Rust is the solution here, because I think using Go with offheap is a perfectly fine solution.

But I do think that the code complexity for a trivial hash table with striped locking can't possibly be higher than the complexity of serializing everything into a giant byte array and maintaining offsets into that array into a map which you make sure doesn't have any pointers in it.

if you understand functional paradigms, rust is actual easier to understand in larger programs

I'm not sure how the current implementation of Go handles it, but its spiritual relatives Modula-3/Oberon handled this quite well, with a GC for most occasions and ways to bypass this with "unsafe" modules that allowed for untracked allocations/deallocations and pointer arithmetic. It's not really an either/or situation by (language) definition...

Yes, it is quite sad that the massive industry adoption of Java and .NET forced those languages into extinction.

Although from all mainstream languages, C# is probably the closest in spirit to Modula-3.

I'm puzzled as to why all mature GC doesn't have "permspace."

Go's GC is non-moving and therefore cannot be generational.

http://llvm.cc/t/go-1-4-garbage-collection-plan-and-roadmap-...

Nitpick: you don't need moving GC for generational GC. But you lose most (but not all) of the benefit of generational GC without moving GC.

I confronted a similar caching requirement (in my case the cache needs to be much larger) in Java recently and chose to implement off-heap for some of the reasons you mention. It avoids GC and heap size concerns entirely and makes it easy to tune the rest of the application's GC profile. Systems handles 45k writes/sec and about double that for reads with very low latency minimal CPU. Implementing concurrent writes/eviction without typical Java concurrency controls was a bit tricky though.

Project is here for those interested: https://github.com/Maascamp/fohlc

Wondering what your use case is for such a large cache that is not clustered (unless I misunderstood the code). Both in terms of single process dying = lost 10gb of data and also what single process needs a 10gb cache. I do see ability to read from disk listed.

How would you compare your cache to open source data grids that also provide off heap (infinispan, geode/gemfire, ignite) or just other general cache solutions (redis/memcache)?

The use case in mainly deduplication of a high volume data stream (though it's got a few other uses). The write volume is fairly stable so it's sized in such away that we'll never emit dupes even when the upstream source crashes and needs to be rebuilt from backups (for this case that means > a billion cache entries). Something like the opposite of a bloom filter (https://www.somethingsimilar.com/2012/05/21/the-opposite-of-...) didn't work because we don't want false negatives either. Since the cache is fed by a Kafka log HA is achieved simply by having multiple consumers individually populating their own cache instance. The persistence mechanisms are to allow for code deployments that don't blow away the cache, not HA.

We actually experimented with grid caches (ignite in particular since it offers off-heap in memory storage as well), but the performance simply isn't there. At the volume we're writing even millisecond latency is a non-starter. We did explore both memcached and redis, but we need strict FIFO and both of those solutions provide nondeterministic LRU.

Now that I think about these issues, I'm wondering now how performant AllegroCache is.

I think the problem with using offheap for something like this is that it requires you to specify the exact size of the data you want to put in each "cell" of the hash table. Take a look at the NewHashFileBacked function in https://github.com/glycerine/offheap/blob/master/offheap.go. If you wanted to cache a variety of json data this could lead to a lot of unused space if most of the items are smaller than the cell size. So, their large byte array plus offsets solution seems preferable.

I do agree with you that perhaps Golang was not the right choice for this project since they spent much of the time working around features of the language.

Reply on news.ycombinator.com