4 ms·

Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to l

by lmkg 7y ago

Well, if you're gonna nitpick... A garbage-collected language wouldn't let you allocate such items on the stack in the first place. GC languages tend not to let you choose where to allocate in the first place, and have obligatory heap semantics for reference types. Some compilers (including Go and Java, to my knowledge) will attempt to optimize the implementation to stack allocation when possible using escape analysis, but this is less precise, and more opaque, then Rust's allocation. And you won't get feedback if it stops working. So, by GP's comment of "unheard of (or just plain dangerous)", the "unheard-of" applies to GC languages and "plain dangerous" would apply non-GC languages.

pjmlp 7y ago
Here goes a list from GC enabled languages that let you chose where to allocate. Modula-3, Oberon, Oberon-2, Active Oberon, Mesa/Cedar, Component Pascal, Eiffel, Sing#, System C#, C#, Swift, D, Nim
- ncmncm 7y ago
  I prefer the term "obligate-GC languages": you don't get to choose whether GC runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are vacuous. Reference-counting, a form of GC very commonly used in Rust and C++, is inefficient compared to more intrusive schemes, particularly where there may be contention for the count, but may be applied selectively, e.g. never on critical paths, so that the inefficiency has zero impact on overall system performance. Obligate-GC advocates like to point at custom benchmarks showing overhead at a small percentage. They are invariably lying, by reporting only the time that the profiler says the program counter is pointing to GC code, and hiding the much-larger results of loss of cache locality on the system as a whole. Typically they don't even know they are lying, which should not give one much confidence in their engineering judgment.
  - pjmlp 7y ago
    You mean custom benchmarks like Midori powering Bing for Asian requests, the ixy paper, Android GPGPU debugger, Fuchsia TCP/IP stack, ChromeOS and Google Cloud sandboxes. Yep, really lying.
    - nickpsecurity 7y ago
      The pre-Cortana version of the speech service ran on Midori, too, with safer code: https://www.reddit.com/r/programming/comments/3t50xg/more_information_about_microsofts_oncesecret/ https://www.reddit.com/r/programming/comments/3t50xg/more_in... They admit it wasn't quite full-GC stuff. It was close to the C++. It did use the language safety and parallelism to its advantage on top of the Midori OS. They ended up improving performance over the original. Still worth mentioning even if not fully-GC. I mean, they could've always used a real-time GC if that was important. There's already commercial and academic ones. For some reason, these projects never try to do that. I think even those developing GC'd systems might not know about RT designs.
zeroxfe 7y ago
> Well, if you're gonna nitpick... :-) > A garbage-collected language wouldn't let you allocate such items on the stack in the first place. I get your point, but I don't think this is entirely true. When people think of call stacks in the general sense, there's a major distinction between CPU stacks and managed stacks. For example in both Java and Go, stack allocations are determined at compile time, and heap allocations at runtime. (Obv, stacks here are not actual CPU stacks, just managed memory stacks depending on the implementation.)

by lmkg 7y ago

pjmlp 7y ago

Here goes a list from GC enabled languages that let you chose where to allocate. Modula-3, Oberon, Oberon-2, Active Oberon, Mesa/Cedar, Component Pascal, Eiffel, Sing#, System C#, C#, Swift, D, Nim

ncmncm 7y ago
I prefer the term "obligate-GC languages": you don't get to choose whether GC runs. Otherwise, Rust and C++ count as "GC-enabled", and comparisons are vacuous. Reference-counting, a form of GC very commonly used in Rust and C++, is inefficient compared to more intrusive schemes, particularly where there may be contention for the count, but may be applied selectively, e.g. never on critical paths, so that the inefficiency has zero impact on overall system performance. Obligate-GC advocates like to point at custom benchmarks showing overhead at a small percentage. They are invariably lying, by reporting only the time that the profiler says the program counter is pointing to GC code, and hiding the much-larger results of loss of cache locality on the system as a whole. Typically they don't even know they are lying, which should not give one much confidence in their engineering judgment.
- pjmlp 7y ago
  You mean custom benchmarks like Midori powering Bing for Asian requests, the ixy paper, Android GPGPU debugger, Fuchsia TCP/IP stack, ChromeOS and Google Cloud sandboxes. Yep, really lying.
  - nickpsecurity 7y ago
    The pre-Cortana version of the speech service ran on Midori, too, with safer code: https://www.reddit.com/r/programming/comments/3t50xg/more_information_about_microsofts_oncesecret/ https://www.reddit.com/r/programming/comments/3t50xg/more_in... They admit it wasn't quite full-GC stuff. It was close to the C++. It did use the language safety and parallelism to its advantage on top of the Midori OS. They ended up improving performance over the original. Still worth mentioning even if not fully-GC. I mean, they could've always used a real-time GC if that was important. There's already commercial and academic ones. For some reason, these projects never try to do that. I think even those developing GC'd systems might not know about RT designs.

zeroxfe 7y ago

> Well, if you're gonna nitpick... :-) > A garbage-collected language wouldn't let you allocate such items on the stack in the first place. I get your point, but I don't think this is entirely true. When people think of call stacks in the general sense, there's a major distinction between CPU stacks and managed stacks. For example in both Java and Go, stack allocations are determined at compile time, and heap allocations at runtime. (Obv, stacks here are not actual CPU stacks, just managed memory stacks depending on the implementation.)