top | item 46629746

Nature vs Golang: Performance Benchmarking

3 points| weiwenhao | 1 month ago |nature-lang.org

5 comments

order

AlanLan|1 month ago

Impressive benchmarks. As a developer focused on high-performance C++ systems, I’m always on the hunt for languages that can match C++'s predictability without the manual overhead.

I noticed Nature's performance is quite competitive with Golang. I'm curious about the 'long-tail' stability. In my current project (a high-frequency engine built with Modern C++), I've managed to achieve a state where memory footprint actually stabilizes and shrinks—from 13.6MB down to 11MB after a week of uptime on Win10, thanks to strict RAII and zero-leak idioms.

How does Nature's runtime/GC handle memory fragmentation and predictability over extended periods (e.g., 100+ hours of uptime) compared to Go's scavenger? That's usually where the 'real' performance gap shows up in production.

weiwenhao|1 month ago

Nature's runtime architecture draws heavily from Go, with its GC similarly referencing Go's allocator and collector approaches. However, the use of mark-and-sweep GC inevitably leads to memory fragmentation issues. Virtual memory usage tends to advance progressively. In contrast, the span-based memory allocator avoids significant fragmentation problems during frequent memory releases and allocations.

---

I also believe predictable memory management is crucial. An arena-based supplementary memory allocator could be the next key feature.

_rlh|1 month ago

Go's allocator draws from the Hoard work as do most modern alloc/free implementations. Similar C/C++/Rust flavor implementations do not seem to "inevitably leads to memory fragmentation issues". Perhaps this fragmentation concern is a myth carried over from earlier malloc/free or gc algorithms.

weiwenhao|1 month ago

I am a core developer of the nature programming language, welcome to talk to me!