-
Notifications
You must be signed in to change notification settings - Fork 135
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zig binary tree search with optimizations #274
base: main
Are you sure you want to change the base?
Conversation
Thanks for your contribution! However, neither arena nor parallelization is accepted for this problem |
No probs - I should read the contributor guidelines :) With the arena allocator - I think some runtimes (such as the memory allocation in the Go runtime, or JVM, or Erlang) ... use an arena strategy instead of raw OS allocations. They allocate from the OS once up front, and then manage application level allocations themselves. May bias the results towards languages that have fat runtimes. (maybe) |
I believe this is true for JVM, but not Go. And the downside of this strategy has been reflected in JVM's huge memory usage |
d24e6bc
to
f81118a
Compare
From what I understand GO approach ("mark and sweep") is also somewhat similar to "Arena-like" as in they allocate in large chunks and deallocate in chunks. I believe majority of runtimes that employ GC do that for more efficient memory management. It's a little bit hard to understand why not to allow it as ability to fine-tune memory management per problem is really one of the main reasons why anyone would chose low level languages such as C/C++ etc and when working with large collections of objects this sort of memory optimization techniques are very common. For instance in Programming Language Benchmark Game c++ solution employs "arena" strategy with monotonic_buffer_resource I've added solution that borrows some ideas from here, and from C++ implementation in bechmarksgame: #381. Let me know what you think. 🙏 |
3fc55d3
to
d70acc7
Compare
This patch fixes the binarytree results for zig
It also tweaks the binarytree search by using multiple threads to process the trees in parallel
Compared to Go :