investigate SmpAllocator performance with respect to other popular allocators
With #22808 set to auto-merge, I am editing this issue to clarify the issue closure requirements, without changing them. `std.heap.SmpAllocator` fills the niche of `-OReleaseFast -fno-single-threaded`. ## Issue Close Requirements: * [x] faster than glibc malloc * [x] faster than musl malloc * [ ] (not yet investigated) faster than mingw-w64 malloc * [ ] (not yet investigated) faster than jemalloc * [ ] (not yet investigated) faster than mimalloc * [ ] implement a general purpose correctness test harness for allocators that includes profile-guided fuzzing (see the [fuzzing label](https://github.com/ziglang/zig/issues?q=is%3Aissue%20state%3Aopen%20label%3Afuzzing)) * [ ] introduce an API for default allocator selection "faster" is vague, and allocators are typically not strictly better or strictly worse than each other. For the purposes of this issue it means the allocator has been tested in various different real world programs and had performance and peak RSS measured, and found to be in the same, or better "sweet spot". If `std.heap.SmpAllocator` cannot be adapted to be the winner, or should remain in its own sweet spot while another sweet spot is found to exist, then a new allocator implementation should be created. A box can still be ticked if due diligence has been done and neither allocator is strictly better than the other, and the set of tradeoffs are judged to be desirable. Originally, this issue specified that `std.heap.GeneralPurposeAllocator` should ch
Posted by andrewrk on Aug 19, 2022, 6:05 AM
Tags
Related issues
- [Meta] Feedback on granular control over Copilot changes
- unexpected status 401 Unauthorized issue
- [MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
- [CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
- Video stops playing after some minutes
- [MODEL] Claude verbose code comments by default — ignores instructions to stop.
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
github (Software)
[Meta] Feedback on granular control over Copilot changes
unexpected status 401 Unauthorized issue
[MODEL] Measurable quality regression in Claude generation 5 (Fable 5 / Opus 5 / Sonnet 5): worse nonsense detection, ~2x verbosity, under-disclosed model fallb
[CRITICAL] Subagent spawning and subagent pattern bugs trigger infinite recursion, infinite token usage, grossly inefficient token usage, and lost accumulated s
Video stops playing after some minutes
[MODEL] Claude verbose code comments by default — ignores instructions to stop.
Scope Codex VS Code chats to the current workspace/project
Update on "Co-authored-by: Copilot" in commit messages
investigate SmpAllocator performance with respect to other popular allocators
With #22808 set to auto-merge, I am editing this issue to clarify the issue closure requirements, without changing them. `std.heap.SmpAllocator` fills the niche of `-OReleaseFast -fno-single-threaded`. ## Issue Close Requirements: * [x] faster than glibc malloc * [x] faster than musl malloc * [ ] (not yet investigated) faster than mingw-w64 malloc * [ ] (not yet investigated) faster than jemalloc * [ ] (not yet investigated) faster than mimalloc * [ ] implement a general purpose correctness test harness for allocators that includes profile-guided fuzzing (see the [fuzzing label](https://github.com/ziglang/zig/issues?q=is%3Aissue%20state%3Aopen%20label%3Afuzzing)) * [ ] introduce an API for default allocator selection "faster" is vague, and allocators are typically not strictly better or strictly worse than each other. For the purposes of this issue it means the allocator has been tested in various different real world programs and had performance and peak RSS measured, and found to be in the same, or better "sweet spot". If `std.heap.SmpAllocator` cannot be adapted to be the winner, or should remain in its own sweet spot while another sweet spot is found to exist, then a new allocator implementation should be created. A box can still be ticked if due diligence has been done and neither allocator is strictly better than the other, and the set of tradeoffs are judged to be desirable. Originally, this issue specified that `std.heap.GeneralPurposeAllocator` should ch
Comments (0)
No comments yet. Start the discussion.