4 ms·

A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you. In practice, no one has ever demonstrated a

A Hummer isn’t any more O(n) than a Prius in terms of fuel used per n miles but that constant will still kill you. In practice, no one has ever demonstrated a garbage collected language that was more efficient than Rust/C/C++ other than in very specific cases. https://thenewstack.io/which-programming-languages-use-the-least-electricity/ https://thenewstack.io/which-programming-languages-use-the-l...

aidenn0 7y ago
The programming language benchmarks game is not great for finding idiomatic code, since it tends to be highly hand-tuned code. Dynamic allocation is slow, so both the C and non-C code will avoid it in the benchmarks game (the problems are usually sufficiently fixed-size that it will boil down to a single malloc() at the beginning, which is idiomatic in a lot of embedded C, but not for non-embedded C). Highly dynamic languages are slower not because the GC is slower, but because the GC encourages (fails to discourage) a lot of allocations. If you were to write Haskell or Ocaml like-code in C you would put a lot of stress on the malloc/free implementations. Those have gotten a lot better in the past 20 years or so (web browsers in particular tend to stress malloc/free a lot as well), but it's still more of a question as to "which malloc best fits my workload" rather than a "one true malloc" which is a factor seen with garbage collectors as well.
- flukus 7y ago
  You can argue over implementation details, it's what programmers do best, but at least it's data and you haven't presented any to support your claims. Shouldn't it be relatively simple to implement malloc/free as a wrapper around a garbage collector and compare like with like? Maybe we'd need some more annotations to cover copying, referencing, etc. For that matter if GC was faster I'm sure we'd have seen this in a number of large C/C++/rust programs already
- ernst_klim 7y ago
  >but because the GC encourages (fails to discourage) a lot of allocations. Yeah, but allocations in OCaml and Haskell are super cheap, nearly as cheap as on stack. Typical OCaml small allocation is: * add the number of words you wanna allocate to the heap pointer (%r15 on amd64) * check if it surpassed the limit + if it's fine — just write your data in -8(%r15) + if there is no space left — run GC

aidenn0 7y ago

The programming language benchmarks game is not great for finding idiomatic code, since it tends to be highly hand-tuned code. Dynamic allocation is slow, so both the C and non-C code will avoid it in the benchmarks game (the problems are usually sufficiently fixed-size that it will boil down to a single malloc() at the beginning, which is idiomatic in a lot of embedded C, but not for non-embedded C). Highly dynamic languages are slower not because the GC is slower, but because the GC encourages (fails to discourage) a lot of allocations. If you were to write Haskell or Ocaml like-code in C you would put a lot of stress on the malloc/free implementations. Those have gotten a lot better in the past 20 years or so (web browsers in particular tend to stress malloc/free a lot as well), but it's still more of a question as to "which malloc best fits my workload" rather than a "one true malloc" which is a factor seen with garbage collectors as well.

flukus 7y ago
You can argue over implementation details, it's what programmers do best, but at least it's data and you haven't presented any to support your claims. Shouldn't it be relatively simple to implement malloc/free as a wrapper around a garbage collector and compare like with like? Maybe we'd need some more annotations to cover copying, referencing, etc. For that matter if GC was faster I'm sure we'd have seen this in a number of large C/C++/rust programs already
ernst_klim 7y ago
>but because the GC encourages (fails to discourage) a lot of allocations. Yeah, but allocations in OCaml and Haskell are super cheap, nearly as cheap as on stack. Typical OCaml small allocation is: * add the number of words you wanna allocate to the heap pointer (%r15 on amd64) * check if it surpassed the limit + if it's fine — just write your data in -8(%r15) + if there is no space left — run GC