Garbage collection is mostly an issue of latency, not overall CPU usage. malloc and free are not O(1) anymore than garbage collection is.
[edit]
I forgot memory usage as a third resource. The search space of GC algorithms can be considered on a triangle of throughput, latency, and RAM usage. You can make one of these better by making one or both of the other worse.
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.
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
>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
[edit]
I forgot memory usage as a third resource. The search space of GC algorithms can be considered on a triangle of throughput, latency, and RAM usage. You can make one of these better by making one or both of the other worse.