| |||||||||||||
Van Rossum: Python is not too slow (InfoWorld)Van Rossum: Python is not too slow (InfoWorld)Posted Mar 20, 2012 20:10 UTC (Tue) by njs (guest, #40338)In reply to: Van Rossum: Python is not too slow (InfoWorld) by Cyberax Parent article: Van Rossum: Python is not too slow (InfoWorld)
RCU doesn't imply shared-everything, just shared-a-few-things-under-very-carefully-controlled-conditions :-). There's nothing stopping them from adding an experts-only, carefully-bounded escape hatch in the standard library. Or from using RCU under the covers to implement something with those semantics -- Rust doesn't literally use 'fork', language runtimes can be very tricky about how they implement things. OTOH you can't add memory isolation in a library :-).
But yeah, it's possible that in some situations, code in Rust will be slower than the best possible concurrent implementation that exploits details of the CPU's cache coherency model etc. For me this is a totally acceptable trade-off, but again YMMV.
(Anyway, it doesn't look like Go has any primitive memory barrier operations, so your only safe concurrency options there are mutexes and channel sends. No RCU.)
(Log in to post comments)
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 21, 2012 16:36 UTC (Wed) by cmccabe (guest, #60281) [Link]
Golang has atomic operations, which imply memory barriers, and also pointers. See http://golang.org/pkg/sync/atomic/ This is something that actually exists now, not just in theory.
As far as I can see, you should be able to use the CompareAndSwapUintptr operation to get the update-side memory barrier you need for RCU. Then you should be able to have reader threads read the pointer value normally, without a memory barrier, and get whatever they get.
In Go, you have garbage collection, so you can forget all about fooling with grace periods and so forth. Just update the pointer.
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 21, 2012 16:53 UTC (Wed) by khim (subscriber, #9252) [Link] In Go, you have garbage collection, so you can forget all about fooling with grace periods and so forth. Just update the pointer. Not exactly. Quite often things like RCU are used for performance-critical tasks. The fact that language is built around GC means that now you not only need to worry about grace periods but you must convince GC to [roughly] obey them. YMMV: in some cases it may all “just work”, in some other cases you'll spend huge amount of time taming GC (and then everything will break once GC will be changed in your implementation). In fact non-optional GC is my biggest gripe with go.
Van Rossum: Python is not too slow (InfoWorld) Posted Mar 21, 2012 17:05 UTC (Wed) by njs (guest, #40338) [Link]
Ah, thanks! I missed those because they aren't mentioned on the Go memory model page: http://golang.org/doc/go_mem.html
|
|||||||||||||