3 ms·

That's a quite small sampling of microbenchmarks, but still interesting. One thing you failed to note is that only Rust and Swift aren't garbage collected. Tha

That's a quite small sampling of microbenchmarks, but still interesting. One thing you failed to note is that only Rust and Swift aren't garbage collected. That means that only Rust and Swift should be considered for applications where deterministic performance is required, in other words soft or hard real time. Many games, for instance, have soft real time requirements.

vardump 11y ago
I believe Swift does reference counting (ARC). Isn't that a form of garbage collection? With reference counting object lifetime management cost is just spread more finely over time. With GC the cost is paid in periodic "time chunks". Other than that, nothing prevents one from writing the performance sensitive part in C/C++/Rust/etc. and then using whatever other language for the non-performance sensitive portion, which typically represents the bulk of code.
- pcwalton 11y ago
  Yes, reference counting is a form of garbage collection.
- Recurecur 11y ago
  Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. (Note that even calling malloc() is non-deterministic and best avoided in real time code.)
  - vardump 11y ago
    > Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. I really don't think Swift is suitable for real time embedded systems, if that's what you suggest. Even C++ is often unsuitable. Rust might have potential one day, if not already. > One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. Any library code can allocate or not allocate regardless of language or memory allocation system. > (Note that even calling malloc() is non-deterministic and best avoided in real time code.) Yeah, malloc is a pretty slow thing.
  - kazinator 11y ago
    You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best. Fact is, that in a reference counting scheme, functions have to call pointer->drop() or whatever (maybe dropping a reference implicitly, thanks to smart pointers or refcounting being built into the language) all over the place, without having any idea whether that action decrements 15 to 14, or whether it decrements 1 to 0, triggering cleanup, and additional decrements on objects behind that object. You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use).
    - Recurecur 11y ago
      "You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best." If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. "You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use)." Wrong across the board.
      - vardump 11y ago
        > If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. Weird you'd say that, exactly same applies to any garbage collected language.
        Recurecur 11y ago
- Recurecur 11y ago
  "Other than that, nothing prevents one from writing the performance sensitive part in C/C++/Rust/etc. and then using whatever other language for the non-performance sensitive portion, which typically represents the bulk of code." Whoops, didn't address this part. This would be a bad idea, since the "low performance" portion could still cause unpredictable GC pauses, affecting the "high performance" part. It also seems a bad idea to split the code base into two languages for no particular reason, when you could write the whole thing in a nice language like Swift. :^)
  - vardump 11y ago
    > This would be a bad idea, since the "low performance" portion could still cause unpredictable GC pauses, affecting the "high performance" part. I don't think that will happen if it runs in a different thread.

vardump 11y ago

I believe Swift does reference counting (ARC). Isn't that a form of garbage collection? With reference counting object lifetime management cost is just spread more finely over time. With GC the cost is paid in periodic "time chunks". Other than that, nothing prevents one from writing the performance sensitive part in C/C++/Rust/etc. and then using whatever other language for the non-performance sensitive portion, which typically represents the bulk of code.

pcwalton 11y ago
Yes, reference counting is a form of garbage collection.
Recurecur 11y ago
Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. (Note that even calling malloc() is non-deterministic and best avoided in real time code.)
- vardump 11y ago
  > Reference counting is a form of GC, the difference being that the programmer has full control over when it runs. Most real time systems preallocate everything and never deallocate. I really don't think Swift is suitable for real time embedded systems, if that's what you suggest. Even C++ is often unsuitable. Rust might have potential one day, if not already. > One typical problem with GC systems is common patterns and library code cause allocations, which cause the GC to run - consuming cycles and causing jitter even if nothing is freed. Any library code can allocate or not allocate regardless of language or memory allocation system. > (Note that even calling malloc() is non-deterministic and best avoided in real time code.) Yeah, malloc is a pretty slow thing.
- kazinator 11y ago
  You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best. Fact is, that in a reference counting scheme, functions have to call pointer->drop() or whatever (maybe dropping a reference implicitly, thanks to smart pointers or refcounting being built into the language) all over the place, without having any idea whether that action decrements 15 to 14, or whether it decrements 1 to 0, triggering cleanup, and additional decrements on objects behind that object. You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use).
  - Recurecur 11y ago
    "You certainly do not have "full control" over when reference counting runs. You have some illusion of control at best." If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. "You only have control in a certain well-defined circumstances, like when you have the entire lifetime of an object (or object aggregate) in the same scope, or a closely related set of scopes. In other words, in situations where you could quite probably do manual memory management (and effectively are doing that, just through the refcounting calls that you are still forced to use)." Wrong across the board.
    - vardump 11y ago
      > If I use the factory pattern with pre-allocated object pools, and keep references to the objects in the factory, I have absolute certainty that ARC will never reclaim the objects. Used properly, ARC will contribute negligible overhead at runtime. Weird you'd say that, exactly same applies to any garbage collected language.
      - Recurecur 11y ago
Recurecur 11y ago
"Other than that, nothing prevents one from writing the performance sensitive part in C/C++/Rust/etc. and then using whatever other language for the non-performance sensitive portion, which typically represents the bulk of code." Whoops, didn't address this part. This would be a bad idea, since the "low performance" portion could still cause unpredictable GC pauses, affecting the "high performance" part. It also seems a bad idea to split the code base into two languages for no particular reason, when you could write the whole thing in a nice language like Swift. :^)
- vardump 11y ago
  > This would be a bad idea, since the "low performance" portion could still cause unpredictable GC pauses, affecting the "high performance" part. I don't think that will happen if it runs in a different thread.