4 ms·
It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while
by jon-wood 8y ago
It’s less Go doing something wrong and more just that they do different things. Go has a garbage collector which will naturally slow things down somewhat, while Rust handles memory (de)allocation at compile time.
- _ph_ 8y agoThe problem is, that some of this benchmarks rules prevent the Go solution from using the same efficient code than its competitors, so the numbers are just not valid.
- hellofunk 8y ago> Rust handles memory (de)allocation at compile time You are saying that Rust is doing its runtime memory allocation at compile time? Are you sure you don’t mean compile time management of memory? Two very different different things.
- notheguyouthink 8y agoIsn't one of those impossible? Ie, there's only one reasonable interpretation of that sentence? Not saying being explicit isn't important, just trying to understand you.
- hellofunk 8y agoYes, what poster commented is in fact impossible.
- atilaneves 8y agoI'm still puzzled by the continued belief that a tracing GC will "naturally slow things down somewhat". Why do you think that's the case?
- yoklov 8y agoYou’re forcing the program to rediscover facts about itself at runtime. This is not free. That doesn’t mean a GCed lang is always slower than a lang where memory is managed manually. It means that the theoretically optimal implementation using GC has to do more work than the theoretically optimal implementation that manages its own memory. In the case where the theoretically optimal implementation needs a GC, the unmanaged language could always implement that anyway, but that’s vanishingly rare — typically a GC gets its speedup by using pools, which are also available to unmanaged code.