4 ms·

It sounds like a lot of the allocations in the Rust compiler follow the generational hypothesis, even though Rust isn't GCd. If the Rust compiler was using a pa

It sounds like a lot of the allocations in the Rust compiler follow the generational hypothesis, even though Rust isn't GCd. If the Rust compiler was using a parallel generational GC then it's possible it'd be a lot faster, as the hard work of the allocation would be done on separate cores and all those tiny unused TypedArenas would die young which makes them rather cheap.

lucozade 10y ago
I'm not sure that this follows from the analysis. Why would a GC remove allocations from the hot path? I could see that it may take deallocations off and may be faster if it's a very good GC. But you'll also get into the territory of what you're GCing. I take it from the fact that there are a lot of arenas that there are an awful lot of small allocations. Unless your GC lets you choose the level of allocation i.e. it doesn't necessarily allocate at the object level, your GC'd language is likely to be much, much slower. There may be GCs like this but I think they are relatively unusual (I'm not aware of them but I'm no expert). It seems to me that the issue here is actually the same as you get when you try to improve performance of GC'd languages i.e. you want to try to avoid any allocation wherever possible. I must say I was a little surprised by how much allocation is going on. Does it imply that idiomatic rust may lend itself to somewhat excessive memory use? Or maybe the rust code in the compiler is sufficiently old to not be considered idiomatic. Would be interested in the views of those more knowledgeable than me.
- Manishearth 10y ago
  rustc is far from idiomatic. Rust used to be GCd, so the compiler uses a lot of things designed in a GC-esque way but tweaked so that they no longer need a GC. In general the language has changed a lot, and the compiler source takes some time to catch up completely.
- pjmlp 10y ago
  > There may be GCs like this but I think they are relatively unusual (I'm not aware of them but I'm no expert). Yes, there are. GC enabled system programming languages like Mesa/Cedar, Modula-3, Active Oberon, D, Sing#, System C#... All of them allow you to control what goes into the GC heap, stack, global memory or is eventually managed manually in unsafe code sections/modules. In any case my remark still goes, it doesn't matter how one acquires OS resources, there is always a performance penalty when it happens too often.
- zigzigzag 10y ago
  Allocation with a modern GC is just a single subtraction in most cases: it's very fast. Deallocation is obviously a lot more involved, but it can be done in parallel on cores that may sit around not always fully utilised. Compilers can normally max out all the cores you've got during a full build, so perhaps in this case it doesn't matter: enhancing the parallelism doesn't help you. On the other hand if you're rebuilding a single file due to incremental compilation, it's probably hard to parallelise that entirely by hand, so shoving some of the memory management work onto your spare cores can help.
- naasking 10y ago
  > Why would a GC remove allocations from the hot path? It wouldn't reduce allocation count, it would reduce allocation cost to a simple pointer bump which is virtually guaranteed to already be in cache (unlike malloc tables). The added cost is only tracing, but if, like the OP said, allocations conform to the generational hypothesis, then frequent minor collections are quite fast.
Manishearth 10y ago
Rust used to be GCd and the compiler made extensive use of this. It was slowly migrated off this, but I suspect the code is still structured that way.

lucozade 10y ago

I'm not sure that this follows from the analysis. Why would a GC remove allocations from the hot path? I could see that it may take deallocations off and may be faster if it's a very good GC. But you'll also get into the territory of what you're GCing. I take it from the fact that there are a lot of arenas that there are an awful lot of small allocations. Unless your GC lets you choose the level of allocation i.e. it doesn't necessarily allocate at the object level, your GC'd language is likely to be much, much slower. There may be GCs like this but I think they are relatively unusual (I'm not aware of them but I'm no expert). It seems to me that the issue here is actually the same as you get when you try to improve performance of GC'd languages i.e. you want to try to avoid any allocation wherever possible. I must say I was a little surprised by how much allocation is going on. Does it imply that idiomatic rust may lend itself to somewhat excessive memory use? Or maybe the rust code in the compiler is sufficiently old to not be considered idiomatic. Would be interested in the views of those more knowledgeable than me.

Manishearth 10y ago
rustc is far from idiomatic. Rust used to be GCd, so the compiler uses a lot of things designed in a GC-esque way but tweaked so that they no longer need a GC. In general the language has changed a lot, and the compiler source takes some time to catch up completely.
pjmlp 10y ago
> There may be GCs like this but I think they are relatively unusual (I'm not aware of them but I'm no expert). Yes, there are. GC enabled system programming languages like Mesa/Cedar, Modula-3, Active Oberon, D, Sing#, System C#... All of them allow you to control what goes into the GC heap, stack, global memory or is eventually managed manually in unsafe code sections/modules. In any case my remark still goes, it doesn't matter how one acquires OS resources, there is always a performance penalty when it happens too often.
zigzigzag 10y ago
Allocation with a modern GC is just a single subtraction in most cases: it's very fast. Deallocation is obviously a lot more involved, but it can be done in parallel on cores that may sit around not always fully utilised. Compilers can normally max out all the cores you've got during a full build, so perhaps in this case it doesn't matter: enhancing the parallelism doesn't help you. On the other hand if you're rebuilding a single file due to incremental compilation, it's probably hard to parallelise that entirely by hand, so shoving some of the memory management work onto your spare cores can help.
naasking 10y ago
> Why would a GC remove allocations from the hot path? It wouldn't reduce allocation count, it would reduce allocation cost to a simple pointer bump which is virtually guaranteed to already be in cache (unlike malloc tables). The added cost is only tracing, but if, like the OP said, allocations conform to the generational hypothesis, then frequent minor collections are quite fast.

Manishearth 10y ago

Rust used to be GCd and the compiler made extensive use of this. It was slowly migrated off this, but I suspect the code is still structured that way.