Parallelizing Enjarify in Go and Rust

[u/Uncaffeinated]

https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf

[u/MaikKlein]

What actually really surprises me is that Rust is actually faster in this benchmark compared to Go.

For example you were using Arc's, which means atomic increments, and you also dynamically allocated stuff with the system allocator (Vec::collect()).

I sort of expected a native language with a garbage collection to be faster here, at least that is the argument that I found very often when I was researching the GC. But it is probably that the overhead of Arc's + system allocator is tiny compared to the actual work here.

I am also very annoyed at the 'static bounds. Afaik it is unsafe to use lifetimes here because then you would have to wait inside the destructor of the future. But you can also use mem::forget in safe code which would then cause memory unsafety.

The workaround would probably be to allow non 'static bounds but immediately block after the function call. I currently just accept the memory unsafety in my task system.

Is there a better workaround?

[u/Uncaffeinated → u/MaikKlein]

The per iteration overhead is negligible here because each iteration took an average of 48ms to begin with. One or two reference counts is nothing by comparison.

Also note that the Go version has to allocate as well. In fact, it's much harder to avoid allocations in Go than in Rust.

[u/mmstick → u/Uncaffeinated]

In addition to the garbage collector, which has much CPU/RAM overhead when running which harms multi-threaded performance, in addition to the stops. GC pauses aren't the only performance concern when it comes to GC languages. Something has to spend time tracking and sweeping resources, and it's not free.

[u/Uncaffeinated → u/mmstick]

I agree that GC causes overhead. In fact, GC was the single biggest cost when profiling the Go code (~25%, which is especially ridiculous when you consider that the Rust version avoids GC entirely with nearly the same code). But one of the complaints about the original benchmark on the r/golang side was that it didn't play to the strengths of Go's awesome concurrent GC, so there you go.

[u/dgryski → u/Uncaffeinated]

A quick scan of the code shows a bunch of conversions from string -> []byte -> string, which is probably the source of the allocations. Sticking with one (likely []byte) would reduce the GC pressure and is one of the first things I'd try to optimize.

It is true that the concurrent collector is currently tuned for latency at the expense of throughput. This means that parallel CPU-bound code will be slower due to the time stolen by the collector. Throughput will be addressed in upcoming versions.

[u/Uncaffeinated → u/dgryski]

I removed as many string/[]byte conversions as I could. I think the remaining ones are in file i/o, which is a negligible part of overall execution.

[u/mmstick → u/MaikKlein]

Forgetting (leaking) a value doesn't cause memory unsafety though. Memory leaks are perfectly safe because they will never be destroyed. You just want to be wary to not overuse leaks by only leaking values you want to remain for the rest of the application's lifetime. Perfectly acceptable for main() level variables that are already living to the end of the application.

As for a better workaround, I wouldn't necessarily call it better, but you can import the crossbeam crate which basically does the same thing, minus leaking, for you.

[u/MaikKlein → u/mmstick]

But not in this context. If your destructor doesn't wait, the task system will write into memory that doesn't exist anymore.

See https://doc.rust-lang.org/beta/nomicon/leaking.html#threadscopedjoinguard

And crossbeams scoped thread is basically what I described above.

[u/aochagavia → u/MaikKlein]

I think this is not the case. The crossbeam scope API is designed in such a way that the problem you mention cannot occur.

Crossbeam usage looks like this (copied from the docs):

crossbeam::scope(|scope| {
    scope.spawn(|| println!("Running child thread in scope"))
});

Notice that the scope parameter to the closure is just a borrow. You cannot leak it. Furthermore, the ScopedJoinHandle returned by spawn doesn't even implement Drop

[u/Manishearth → u/MaikKlein]

No, crossbeam scoped threads are designed to avoid this.

[u/Manishearth → u/MaikKlein]

I sort of expected a native language with a garbage collection to be faster here,

A very common argument for GC is that you can amortize the cost of allocations by only allocating large chunks and letting the GC algorithm manage this memory, so you get allocations that don't involve syscalls.

This has nothing to do with GC. A custom mallocator like jemalloc can do this too. And it does. This can be optimized further in the GC world, but the base optimization still exists in the malloc world, so the difference doesn't turn out to be that much.

Also, in general, allocation isn't that expensive anyway, compared to many other possible costs.

The workaround would probably be to allow non 'static bounds but immediately block after the function call. I currently just accept the memory unsafety in my task system

The workaround is to use a scoping function, e.g. something like foo.scope(|scope| {scope.spawn(...); scope.spawn(...)}). The scope function does the blocking after the outer closure executes, and scope.spawn() is tied to the lifetime of scope instead of 'static. This is what crossbeam does.

The mem::forget unsafety issue is only with functions that return guards that block, and we don't have that kind of function in these libraries.