3 ms·
All valid points, but typically even the best case gc perf will still be far more expensive than avoiding heap allocations entirely. When I was writing numeric
by ska 9y ago
All valid points, but typically even the best case gc perf will still be far more expensive than avoiding heap allocations entirely.
When I was writing numeric stuff in common lisp, the performance critical stuff all ended up looking pretty c-like, and as far as I can see it's similar in OCaml (for really high performance stuff).
It's not a bad trade off, especially for anything following the 80:20 heuristic. That way 80% of your code can be written more expressively and less error prone.
- rbehrends 9y ago> All valid points, but typically even the best case gc perf will still be far more expensive than avoiding heap allocations entirely. Agreed. If you want a high-performance systems programming language, then you generally want one that allows you to transparently write code for GCed references, untraced references, and pass-by-reference parameters. Nim and Modula-3 come to mind as languages that support this, to some degree or another. > and as far as I can see it's similar in OCaml (for really high performance stuff). The big problem that OCaml has with numerics is that it boxes floats by default. The compiler does a lot of work to avoid that boxing where possible, but it's not always possible, even in common use cases. (The JVM shouldn't have that particular issue, though.) In this case, a fast allocator can at most mitigate the overhead associated with boxing.
- ska 9y agoI'd forgotten about that boxing issue, it was one of the things that discouraged my exploring it more (for numerical work) years ago.