4 ms·

Let's take a couple of simple examples of when manual memory management is helpful: - implement a complex data structure that requires a lot of memory: you can

Let's take a couple of simple examples of when manual memory management is helpful: - implement a complex data structure that requires a lot of memory: you can request a chunk of memory from the kernel, do an area-allocation and choose to allocate/free on your own terms. - implement a performant concurrency model. You essentially need some sort of scheduler to give various threads access to the shm via cas primitives. Let's take up the second point first: you have implemented tasks that communicate using pipes without sharing memory (rt/rust_task.cpp). You've exposed the lower-level rt/sync via libextra/sync.rs, but it's frankly not a big improvement over using raw pthreads. The scheduler is a toy (rt/rust_scheduler.cpp), and the memory allocator is horribly primitive (rt/memory_region.cpp; did I read correctly? are you using an array to keep track of the allocated regions?). The runtime is completely devoid of any garbage collection, because you started out with the premise that manual memory management is the way to go: did it occur to you that a good gc would have simplified the rest of your runtime greatly? Now for the first point: Rust really has no way of accomplishing it, because you I don't get access to free(). The best you can do at this point is to use some sort of primitive reference counter (not much unlike cpython or shared-pointer in C++), because it's too late to implement a tracing garbage collector. And you just threw performance out the window by guaranteeing that you will call free() everytime something goes out of scope, no matter how tiny the memory. Now, let's compare it to the go runtime: arena-allocator tracked using bitmaps (malloc.goc), decent scheduler (proc.c), decent tracing garbage collector (mgc0.c), and channels (chan.c). For goroutines modifying shared state, they even implemented a nice race-detection tool (race.c). The fact of the matter is that a good runtime implementing "pretty" concurrency primitives requires a garbage collector internally anyway. It's true that go doesn't give me a free() either, but atleast I'm reassured by the decent gc. Now, having read through most of libstd, observe: impl<'self, T> Iterator<&'self [T]> for RSplitIterator<'self, T> What's the big deal here? The lifetime of the variable is named ('self), and the ownership semantics are clear (& implies borrowed pointer; not very different from the C++ counterpart). Whom is all this benefitting? Sure, you get annoying compile-time errors when you don't abide by these rules, but what is the benefit of using them if there's no tooling around it (aka. gc)? Yes, it's trivially memory-safe and I get that. Lastly think about why people use C and C++. Primarily, it boils down to compiler strength. The rust runtime doesn't look like it's getting there; atleast not in its current shape.

pcwalton 13y ago
> Let's take a couple of simple examples of when manual memory management is helpful: > > - implement a complex data structure that requires a lot of memory: you can request a chunk of memory from the kernel, do an area-allocation and choose to allocate/free on your own terms. Rust fully supports this case with arenas. > - implement a performant concurrency model. You essentially need some sort of scheduler to give various threads access to the shm via cas primitives. And that's why the new scheduler is written in Rust. Furthermore, manual memory management is helpful when you are implementing a browser that doesn't want a stop the world GC. > You've exposed the lower-level rt/sync via libextra/sync.rs, but it's frankly not a big improvement over using raw pthreads. It's just a wrapper around pthreads, for use internally by the scheduler and low-level primitives. It is not intended for safe Rust code to use. Of course it's not a big improvement over pthreads. > The scheduler is a toy (rt/rust_scheduler.cpp) That's why it's getting rewritten. You're looking at the old proof of concept/bootstrap scheduler. Please see the new scheduler in libstd/rt. It will probably be turned on in a week or two. > and the memory allocator is horribly primitive (rt/memory_region.cpp; did I read correctly? are you using an array to keep track of the allocated regions) There is a new GC that is basically written, just not turned on by default yet. Furthermore, manually-managed allocations no longer go through that list. > Rust really has no way of accomplishing it, because you I don't get access to free(). Of course you do. `let _ = x;" is an easy way to free any value. > The best you can do at this point is to use some sort of primitive reference counter (not much unlike cpython or shared-pointer in C++), because it's too late to implement a tracing garbage collector. This is just nonsense, sorry. Graydon has a working tracing GC, it's just not turned on by default because of memory issues on 32 bit when bootstrapping. This is not too difficult to fix and is a blocker for 1.0. Furthermore, did you not see the mailing list discussions where we're discussing what needs to happen to get incremental and generational GC? > And you just threw performance out the window by guaranteeing that you will call free() everytime something goes out of scope, no matter how tiny the memory. This is what move semantics are for. If you want to batch deallocations like a GC does (which has bad effects on cache behavior as Linus is fond of pointing out, but anyway), move the object into a list so it doesn't get eagerly freed and drop the list every once in a while. > Lastly think about why people use C and C++. Primarily, it boils down to compiler strength. The rust runtime doesn't look like it's getting there; atleast not in its current shape. The benchmarks of the new runtime are quite promising. TCP sending, for example, is faster than both node.js and Go 1.1 in some of our early benchmarks. And sequential performance is on par with C++ in many cases: http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/ http://pcwalton.github.io/blog/2013/04/18/performance-of-seq...

pcwalton 13y ago

> Let's take a couple of simple examples of when manual memory management is helpful: > > - implement a complex data structure that requires a lot of memory: you can request a chunk of memory from the kernel, do an area-allocation and choose to allocate/free on your own terms. Rust fully supports this case with arenas. > - implement a performant concurrency model. You essentially need some sort of scheduler to give various threads access to the shm via cas primitives. And that's why the new scheduler is written in Rust. Furthermore, manual memory management is helpful when you are implementing a browser that doesn't want a stop the world GC. > You've exposed the lower-level rt/sync via libextra/sync.rs, but it's frankly not a big improvement over using raw pthreads. It's just a wrapper around pthreads, for use internally by the scheduler and low-level primitives. It is not intended for safe Rust code to use. Of course it's not a big improvement over pthreads. > The scheduler is a toy (rt/rust_scheduler.cpp) That's why it's getting rewritten. You're looking at the old proof of concept/bootstrap scheduler. Please see the new scheduler in libstd/rt. It will probably be turned on in a week or two. > and the memory allocator is horribly primitive (rt/memory_region.cpp; did I read correctly? are you using an array to keep track of the allocated regions) There is a new GC that is basically written, just not turned on by default yet. Furthermore, manually-managed allocations no longer go through that list. > Rust really has no way of accomplishing it, because you I don't get access to free(). Of course you do. `let _ = x;" is an easy way to free any value. > The best you can do at this point is to use some sort of primitive reference counter (not much unlike cpython or shared-pointer in C++), because it's too late to implement a tracing garbage collector. This is just nonsense, sorry. Graydon has a working tracing GC, it's just not turned on by default because of memory issues on 32 bit when bootstrapping. This is not too difficult to fix and is a blocker for 1.0. Furthermore, did you not see the mailing list discussions where we're discussing what needs to happen to get incremental and generational GC? > And you just threw performance out the window by guaranteeing that you will call free() everytime something goes out of scope, no matter how tiny the memory. This is what move semantics are for. If you want to batch deallocations like a GC does (which has bad effects on cache behavior as Linus is fond of pointing out, but anyway), move the object into a list so it doesn't get eagerly freed and drop the list every once in a while. > Lastly think about why people use C and C++. Primarily, it boils down to compiler strength. The rust runtime doesn't look like it's getting there; atleast not in its current shape. The benchmarks of the new runtime are quite promising. TCP sending, for example, is faster than both node.js and Go 1.1 in some of our early benchmarks. And sequential performance is on par with C++ in many cases: http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/ http://pcwalton.github.io/blog/2013/04/18/performance-of-seq...