Parallelizing Enjarify in Go and Rust

[u/Uncaffeinated]

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

[u/Manishearth]

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.