Skip to content
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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

zigster64
Copy link

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 :

  • single threaded Zig is about 3x faster than go
  • multi threaded Zig is about 9x faster than go

@hanabi1224
Copy link
Owner

Thanks for your contribution! However, neither arena nor parallelization is accepted for this problem

@zigster64
Copy link
Author

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)

@hanabi1224
Copy link
Owner

hanabi1224 commented Jul 14, 2022

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.

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

@skyjur
Copy link

skyjur commented Mar 28, 2023

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. 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants