DEV Community: CharmPic

I rebuilt the "Simple Web Server" from 20 years ago.

CharmPic — Thu, 20 Aug 2026 04:14:59 +0000

20 Years Ago, I Built a Simple Web Server by Reading HTTP Specs. Today, I Rebuilt It with Modern .NET and AI.
Back in 2005, I read through HTTP protocol books and painstakingly hand-crafted a lightweight Windows utility called "Easy Web Server" (簡単WEBサーバー).

Fast-forward about 20 years: instead of wrestling with low-level socket boilerplate, we now have powerful standard libraries—and AI collaborators to bounce ideas off of. So, I decided to completely rewrite the tool from scratch as EasyHTTPServer 2.

Rather than patching 20-year-old legacy code, this is a clean-slate implementation powered by C# / .NET 10, ASP.NET Core Kestrel, and WPF.

Key Features

One-Click File Sharing: Select a folder and start a read-only HTTP file server instantly.

Static Site Hosting: Host simple static websites with index.html support.

Flexible Binding: Works on localhost, Home LAN, and VPN environments.

Zero-Config LAN HTTPS & Pairing: Built-in HTTPS with a quick-pairing mechanism for secure local network sharing.

Large File & Resume Support: Handles large downloads with HTTP range requests (resume capability).

Classic 2005 Theme: A nostalgic UI skin that pays homage to the original 2005 release.

The original tool holds a special place in my heart, having been used in school classrooms for introductory HTML lessons back in the day. While preserving its signature "just works" simplicity, the architecture has been thoroughly modernized to eliminate old risks—such as path traversal vulnerabilities and unsafe CGI execution.

Getting Started (Windows x64)
Simply extract the ZIP package and launch EasyHTTPServer.exe—no complicated setup required.

GitHub Repository:

https://github.com/moe-charm/EasyHTTPServer

Windows Download (Alpha Release):

https://github.com/moe-charm/EasyHTTPServer/releases/tag/v2.0.0-alpha.1

It is currently in alpha, but I plan to iteratively refine it—striking the right balance between 2000s nostalgia and modern security standards. Feedback and contributions are warmly welcome!

Building a Binaural VST and Why I Couldn't Get 'Elevation' Right

CharmPic — Sun, 02 Aug 2026 17:21:39 +0000

Since my beloved dearVR was end-of-lifed, I built this in collaboration with GPT-5.6-Sol, with Opus 5 writing the main draft of this article.

I built NekoSpace Binaural, a spatialization VST plugin designed for audio dramas and ASMR, and recently released the first alpha.

Repository: https://github.com/moe-charm/nekospace-audio
Release: https://github.com/moe-charm/nekospace-audio/releases/tag/v0.1.0-alpha
Tech Stack: C++17 / JUCE 9.0.0 / CMake, AGPLv3, Windows VST3 + Standalone

This article isn't a celebratory "look what I built" post. Instead, its purpose is to document what worked and what didn't, backed by real numbers.

In particular, my four attempts at handling "elevation" (vertical localization) failed to yield a decisive result. I believe documenting that failure is where the real value lies, so I’ve dedicated most of this post to it.

Why Build It?

Normally, I record using a Neumann KU100 dummy head microphone. While the KU100 captures the actual acoustic space beautifully, there are always cases where you need to place a mono source at an arbitrary position during post-production—such as sound effects, added dialogue, or whisperings right next to the listener's ear. Existing plugins are mostly built for games/VR, and they lack convincing proximity expressions for placing a voice "right by the ear." That was the starting point.

Note: Naturally, you should never run materials already recorded with a KU100 through this plugin, as that would apply head-related transfer functions twice. The target input is strictly dry mono/stereo material.

What Worked

1. Computing ITD from Exact Ray Paths on a Rigid Sphere

Instead of deriving Interaural Time Difference (ITD) from the measurement delays embedded in HRIRs, I designed the system to calculate ITD geometrically on every frame.

Since the ears lie on the surface of a sphere, there are two ray paths from the sound source to the ear: a straight line when the ear is visible, and a tangent + a great-circle arc when the ear falls into the acoustic shadow.

// The ear is "on" the sphere. Line-of-sight exists when the sound source 
// is outside the ear's tangent plane: r * cos(theta) >= a <=> theta <= acos(a/r)
const float thetaVis = std::acos (clampf (a / r, 0.0f, 1.0f));

if (theta <= thetaVis)
    return (sourcePos - earPos).length();           // Straight line

const float tangent = std::sqrt (std::max (r * r - a * a, 0.0f));
return tangent + a * (theta - thetaVis);           // Tangent + arc

The main benefit of this approach is that proximity exaggeration emerges naturally from the geometry, without artificial tuning. At a distance of 12 cm directly to the side, the Interaural Level Difference (ILD) widens up to 24.2 dB. In contrast, standard far-field approximations (like Woodworth's formula) yield only 5.6 dB. The plugin’s NEAR FIELD knob continuously blends between these two models: 0% acts as a standard panner, while 100% applies full per-ear geometry.

A Bug I Ran Into

Initially, I wrote the visibility boundary condition as π/2 + acos(a/r). A code review pointed out the mistake.

The correct boundary is simply acos(a/r). At this boundary, |S - E| == sqrt(r² - a²) (matching the tangent length), making the two conditional branches connect continuously. With the incorrect boundary, the transition into the acoustic shadow occurred at the wrong angle, causing the ITD to jump discontinuously near 90° azimuth. This manifested as audible clicks/pops when panning.

Lesson learned: Whenever geometry can be written in closed form, always write unit tests to verify boundary continuity.

2. Late-Only Voice Ducking

A common requirement in audio drama production is: "I want to add reverb, but I can't let it mud up the vocal clarity." The typical workaround is manually writing reverb send automations, which is tedious and often sounds unnatural.

I implemented a ducking feature that attenuates only the late reverberation while the voice is actively playing. Three specific design decisions made this effective:

(a) Duck the FDN output, NOT the input.

This is key. If you attenuate at the input, the reverb energy never builds up inside the network, causing the reverb to "start growing" the moment the voice stops. By suppressing at the output, the reverb energy accumulated inside naturally emerges at the end of a phrase. The room reflection rises exactly at the end of the spoken line as intended.

(b) Do not touch direct sound or early reflections.

Early reflections carry the spatial "shape" of the room. Furthermore, as described later, they are rendered through HRTFs for each image direction, serving as part of the height cues. Only the late reverb muddies the voice, so that's all we duck.

(c) Make it threshold-less.

env = x > env ? envAtt * (x - env) + env : envRel * (x - env) + env;
ref = x > ref ? x : refRel * (x - ref) + ref;   // Reference level decaying over seconds

// Relative to "recent input level", independent of input gain or speaking style
const float activity = clampf (env / (kActivityFraction * ref), 0.0f, 1.0f);
const float target   = 1.0f - depth * activity;

const float k = target < gain ? duckAtt : duckRel;  // Fast duck, slow recovery
gain += k * (target - gain);

ref is a slowly decaying baseline level. By evaluating activity relative to this baseline, the ducking behaves consistently whether the input is a soft whisper or a loud shout. This eliminated the need for a dB threshold knob on the UI.

Measurement: Isolating the room bus (subtracting the dry rendering), the reverb level dropped to −13.1 dB during speech and returned to −0.07 dB post-speech.

(Note: Initially, I measured the total output and panicked because it only showed a −1.6 dB drop. Since the direct sound dominates the output, that was expected—I had simply measured at the wrong tap point! Always isolate the target bus when measuring DSP effects.)

What Didn't Work: Elevation

Here is the core of the problem. Across four iterations, vertical localization never reached a level where a listener could confidently say, "That sound is coming from above."

Round 1: Rebuilding the Analytical Pinna Model

I modeled pinna notch filters by sweeping the notch frequency from 4.2 kHz to 11.5 kHz based on elevation, adding companion peaks and a high-frequency shelf.

Spectral difference (4–14 kHz, top vs. bottom): Expanded from 2.0 dB → 5.8 dB.
Perceptual outcome: Tonal timber clearly changed. Vertical positioning remained completely unperceivable.

Round 2: Empirical HRTF (Neumann KU100)

Hypothesizing that the analytical model was too crude, I integrated measured KU100 HRTF data from TH Köln (Bernschütz 2013, Lebedev 2702 grid points, CC BY-SA).

Key steps during dataset conversion:

Removed dataset ITD: Since the engine calculates ITD geometrically, leaving measurement delays in the HRIRs caused double delay. I minimum-phased the response via real-cepsrum unwrapping to strip group delay while preserving magnitude responses. Truncating to 256 taps remained clean because energy was concentrated at the head.
Verified coordinate system & symmetry: SOFA SimpleFreeFieldHRIR uses counter-clockwise positive angles (left is positive), whereas my engine uses right-positive. I verified with tests that an az +90° source produced higher levels in the right ear.
Normalized frontal level: Vital to ensure listening tests compared spectral shape rather than sheer volume differences.

Spectral difference (4–14 kHz): 6.4 dB (wider than Analytical Model B's 5.8 dB).
Perceptual outcome: Indistinguishable from Analytical B. Vertical position was still imperceptible.

Despite the dataset showing larger numerical spectral differences, perceived spatialization didn't change. This ruled out the hypothesis that "just swapping the dataset will fix it."

Round 3: Pinna-Independent Elevation Cues

If fine spectral pinna notches depend heavily on the listener's own pinna shape, I reasoned that adding pinna-independent cues might help.

(a) Rendering Early Reflections through HRTFs

Previously, early reflections used equal-power panning. This was a flaw: atan2(x, z) yields identical panning gains for sound sources above vs. below. The reflections carried zero directional information. By routing each mirror image reflection through HRTFs based on its actual arrival angle, overhead sounds finally received floor reflections coming from below.

Room response difference (top vs. bottom): 5.9 dB.

(b) Modeling Torso / Shoulder Reflections

I added a comb filter notch between 440 Hz–1.2 kHz that moves with elevation. Because it operates in lower frequencies, it is less affected by headphone coloration.

Low-frequency difference (0.7–3 kHz): Analytical A = 0.11 dB, Analytical B = 2.15 dB.

(Note: The KU100 dummy head lacks a torso, so it inherently lacks these shoulder reflection cues—likely one reason the empirical dataset didn't outperform analytical models in Round 2.)

Perceptual outcome: Still weak.

Round 4: Manual Per-Listener Tuning (Elevation Lab)

I abandoned expanding generic models and shifted toward a listener-tuned manual calibration system.

I created three elevation anchors (Below −60°, Level 0°, Above +60°), each holding 8 parameters: notch frequency, depth, Q, companion peak ratio, HF shelf, and torso delay/gain. Intermediate angles are interpolated; angles beyond ±60° are extrapolated.

Anchors allowed independent tuning of top and bottom responses. In Analytical B, all parameters were derived from sin/cos of elevation, meaning tweaking "Above" invariably distorted "Below".

Verified via unit test: Shifting the Above notch anchor from 9.7 kHz → 14 kHz moved the rendered top notch to 13.4 kHz while the Below notch remained strictly fixed at 4850 Hz.

However, surfacing 24 raw parameters in the UI was completely unusable. It was mathematically sound, but terrible for real-time ears-on tweaking. I collapsed them into 4 macro controls: UP, DOWN, BODY, and FOCUS, hiding raw controls inside an Advanced foldout. At macro value 1.00, it bit-accurately reproduces Analytical B, ensuring "Reset" actually means Reset.

Perceptual outcome: "There was a slight sense of vertical motion, but still nowhere near a convincing 'above' localization."

It was better than Round 3—there was a sense of directional movement—but calling it "above" would be dishonest.

Conclusion & Key Takeaways

Metric	Analytic A	Analytic B	KU100 Measured
Upper Spectral Diff (4–14 kHz)	2.0 dB	5.8 dB	6.4 dB
Lower Spectral Diff (0.7–3 kHz)	0.11 dB	2.15 dB	—
ILD at az +90°	—	—	12.7 dB

All four approaches improved the numerical metrics. None achieved convincing vertical perception.

I concluded that this is not an implementation bug, but the known ceiling of static, non-personalized binaural audio. The reasons are clear:

Spectral elevation cues depend heavily on the unique physical shape of the listener's own ears.
Headphones heavily disrupt/re-color that exact 5–12 kHz frequency region.
The most powerful elevation cue—head tracking—is structurally impossible here, as audio dramas are distributed as pre-rendered static audio files.

Consequently, I decided to release the plugin while explicitly stating in the README that elevation cues are weak. The feature remains in the DSP pipeline, but I will not market it as a reliable localization tool. In voice productions, conveying height is far more reliably achieved through script design, footsteps, and spatial reverb—which is how traditional radio dramas have handled it for decades.

I committed all failed experiments and numerical findings directly into the public repository as elevation-findings.md. Negative results are worth preserving.

DSP & Architecture Lessons

1. Choice Lists (Enums) Must Be Frozen Before Release

Deciding this upfront saved the project.

Plugin state management (like JUCE's APVTS) saves choice parameters using denormalized indices, so appending options to the end of a list later won't break existing project files. Adding persistent string keys (e.g., analytic_b) ensures safety across display name changes or localizations.

The real hazard is host automation. VST3/AU automations save values normalized as index / (count - 1). The moment you add an option to an enum, count changes, causing all past host automations to point to the wrong option. This cannot be rescued by plugin state formats alone.

My rule: If you want to add options after release, create a new parameter ID. I explicitly marked frozen IDs in the CHANGELOG. This is why 4 HRTF profiles (including one dev-only profile) were reserved from day one.

(Self-correction note: I previously misspoke on this, asserting APVTS broke saved states. In reality, APVTS saves denormalized indices safely; it's the host automation mapping that breaks. Don't guess format behaviors—read the code!)

2. Keep the DSP Core Independent of JUCE

I enforced an architectural rule: src/dsp must never #include <JuceHeader.h>.

Because of this, 30 acceptance tests run without instantiating a plugin wrapper. Builds and test executions complete in milliseconds, and CI failures can be pinpointed instantly.

3. Don't Trust CI Until You See It Fail (and Pass)

A Git tag triggers GitHub Actions to run configure → build → test → package → publish, generating a draft release. If tests fail, the workflow halts.

However, this failed me once: I added CI but didn't monitor its real run. A runner mismatch (windows-latest dropping VS 2022 components) broke CI on every push without me noticing. Pinning to windows-2022 fixed it. CI implementation isn't done when you commit the file; it's done when you watch it turn green.

Summary

Geometric ITD, proximity modeling, and late-only ducking worked as intended.
Elevation failed perceptually across 4 iterations despite solid numerical improvements. I accepted this as a fundamental ceiling of static binaural audio and documented it in the README.
Freeze irreversible contracts (parameter IDs, choice lists) before v1 release.

As an alpha release, there is still room to polish the sound. It's available as Windows VST3 + Standalone under the AGPLv3 license. If you're interested, feel free to give it a spin—headphones are required!

👉 GitHub: https://github.com/moe-charm/nekospace-audio

What I Learned Building 12 Generations of Memory Allocators: Balancing Speed and Low RSS

CharmPic — Tue, 14 Jul 2026 23:57:58 +0000

My personal research project, the Hakozuna memory allocator, has recently reached its 12th generation (HZ12).

Even though it doesn't make me a single dime, I somehow ended up building 12 different generations.
This time, I have published a paper on Zenodo that synthesizes the findings and designs of HZ10, HZ11, and HZ12.

Paper (Zenodo): https://doi.org/10.5281/zenodo.21360690
GitHub: https://github.com/hakorune/hakozuna

Note: The Zenodo repository includes PDFs of both the English and Japanese versions of the paper.

What is Hakozuna?

Hakozuna is a family of memory allocators I developed to research various aspects of memory management, including malloc/free performance, RSS (Resident Set Size), remote free operations, and safety.

Each generation has a specific focus:

Generation	Key Theme
HZ3	High-speed local-heavy allocation
HZ4	Remote-free / message-passing
HZ5	Descriptor-owned, low RSS
HZ6	Fail-closed route contracts
HZ8	Balanced allocator for general-purpose use
HZ10	Route, lifecycle, and measurement boundaries
HZ11	Ownerless, speed-first recycling
HZ12	Advisory ownership and bounded span reclamation

Currently, HZ8 is the recommended default allocator for general use.
On the other hand, the HZ10–HZ12 series represents a more research-oriented branch.

HZ11: Prioritizing a Fast Recycling Path

In HZ11, we explicitly avoided the design where the thread freeing an object must return it to its original owner thread on every single free call.

Instead, we introduced the following structure:

front cache ──> transfer cache ──> central spans ──> ownerless recycling

By avoiding ownership checks during every free operation, we can significantly shorten the hot path.

In our remote/mixed benchmarks on Linux x86-64, HZ11 fine128 achieved the following throughput ratios compared to tcmalloc:

Workload	HZ11 / tcmalloc Throughput Ratio
`main_r50`	1.853x
`main_r90`	2.346x
`medium_r50`	4.590x
`medium_r90`	6.097x

⚠️ Disclaimer: These results are highly specific to certain benchmarks, machines, and lanes. This does not imply that HZ11 is universally faster than tcmalloc.
For instance, in the Windows broad-MT balanced benchmark, HZ11 reached about 422M ops/s, which is roughly 81.7% of tcmalloc's performance. However, in larger_sizes, it achieved around 149%. There are very clear strengths and weaknesses.

The Weakness of Ownerless Recycling

While ownerless recycling is incredibly fast, it introduces a major challenge: when objects are scattered across multiple threads' caches or central structures, it becomes extremely difficult to determine if a specific span has become completely empty.

Fast recycling of objects 
   └── BUT ──> Hard to safely decommit entire spans

Adding atomic counters or owner lookups to every free call would make tracking empty spans easier, but it increases the fixed overhead of malloc and free.

This trade-off is what led to the design shift in HZ12.

HZ12: Decoupling Ownership from Safety Guarantees

In HZ12, the ownership tag is no longer treated as the ultimate authority that guarantees the safety of a reclaim operation. Instead, it serves merely as a hint to find candidates.

Ownership token: A hint to narrow down candidate searches.
Reclaim authority: Decided by verifying multiple conditions on the cold path:
Complete-span snapshot
Inbox emptiness
State validation
Reclaim budget
Depot capacity

By validating these conditions on the cold path, we avoid putting any diagnostic, per-operation atomic accounting into the high-performance production hot path of malloc/free.

Bounded Span Reclamation

To ensure safety, HZ12 enforces a strict sequential contract during reclamation:

Search for complete span candidates.
Verify inbox and owner state.
Check the reclaim budget.
Pre-reserve depot capacity. (Crucial!)
Detach the route.
Decommit the payload.
Roll back if any step fails.

If you decommit a span first and only then realize there is no space to store it, the span falls into a "limbo" state where it belongs to nowhere. To prevent this, depot capacity must be reserved prior to decommitting.

Reclamation Results on Linux

We measured owner turnover over 8 generations on Ubuntu/Linux x86-64.

Conditions: 64 spans per generation, 64-byte objects, RUNS=5.

Metric	Result
retirement p50	1.089 ms
retirement p99	1.144 ms
retirement max	1.167 ms
reclaimed spans	512 total
discarded bytes	32 MiB total
limbo spans	0
peak RSS	7.56 MiB
post RSS	3.56 MiB

We successfully reclaimed all 64/64 spans across all 8 generations. More importantly, the number of limbo spans was exactly 0.

Platform-Specific Implementations over Unified Code

Instead of forcing a single implementation across operating systems, we separate the OS backing layers while sharing the core semantics.

Windows: Uses VirtualAlloc with decommit / recommit.
Linux: Uses mmap with madvise(MADV_DONTNEED).

What they share is not the code itself, but the contract:

Reclaim only complete spans.
Keep budget and depot bounded.
Roll back on failure.
Never create limbo spans.
Keep the speed lane and diagnostic lane strictly separated.

We believe implementing the same contract tailored to each OS is far cleaner than squeezing them into a single, highly abstracted codebase.

Documenting the Failures (The "NO-GO" Experiments)

In the Hakozuna project, we document not only the successful optimizations but also the experiments that ended up as "NO-GOs."

Experiment	Decision	Reason
Inbox capacity 2048/4096	CLOSED	Expanding capacity violates our low RSS policy.
Per-operation atomic accounting	NO-GO (Speed Lane)	Introduces too much fixed overhead on the hot path.
Incomplete reclaim snapshot	NO-GO	Fails to serve as a reliable safety authority.
Depot reservation after decommit	MUST FIX	Creates dangerous "limbo" spans.
Lock-free per-free handoff	OUT OF SCOPE	Not the focus of the HZ12 architecture.

In allocator optimization, looking only at the "what went faster" results can easily lead to misinterpreting the actual design space. Documenting what we tried and why we rejected it is just as valuable a research contribution.

Roles of HZ8, HZ11, and HZ12

Here is how the current lineup is positioned:

HZ8: * General-purpose allocator.
Balanced throughput and low post-workload RSS.
Fail-closed ownership.
HZ11: * Ownerless, speed-first baseline.
Built for throughput research.
HZ12: * Advisory ownership and bounded span reclamation.
Built for researching the trade-offs between speed and RSS.

HZ12 is not an absolute upgrade to HZ11. Managing ownership and lifecycles always introduces some overhead; for purely speed-oriented workloads, HZ11 may still have the upper hand. Additionally, we are not claiming that HZ12 replaces HZ8 at this stage.

Conclusion

The core question we wanted to answer with HZ10–HZ12 was:

How far can we balance the speed of ownerless recycling with efficient span reclamation, without adding owner lookups or diagnostic atomic operations to the malloc/free hot path?

Our current answer is:

Hot path: Keep it short and completely ownerless.
Cold path: Narrow down candidates using advisory ownership, verify safety using complete-span validation, and cap the reclamation volume using a bounded budget and depot.

We haven't built a "silver bullet" allocator that completely replaces tcmalloc across the board. However, we have gained deep, practical insights into how to trade off speed, RSS, safety, and complexity within a unified allocator design.

For a deeper dive into the architectural details and comprehensive benchmark data, please check out our paper and repository!

📄 HZ10-HZ12 Paper: https://doi.org/10.5281/zenodo.21360690
🐙 GitHub Repository: https://github.com/hakorune/hakozuna

Custom Memory Allocator HAKOZUNA HZ8: A balanced allocator that prioritizes low RSS over raw speed.

CharmPic — Wed, 01 Jul 2026 07:48:19 +0000

I have created HZ8 as a new line for my custom memory allocator, Hakozuna.

HZ8 is not an allocator designed to be the "fastest across all benchmarks."

The goal is to return the post-workload RSS to a low level while maintaining a practical throughput.

In short, HZ8 is characterized as follows:

HZ8:
balanced low-RSS allocator
practical throughput
fail-closed ownership
cross-thread free correctness

I have consolidated the insights gained from experimenting with HZ3, HZ4, HZ5, and HZ6 into HZ8, organizing it as the primary allocator line to choose for general use.

HZ8 Design Principles

In HZ8, we put a particular emphasis on the following points:

Keeping RSS low.
Preventing breakdown under remote-heavy workloads.
Handling cross-thread frees safely.
Making ownership and route determination fail-closed.
Balancing practical speed and memory usage rather than aiming for the absolute fastest.

The current default is HZ8-v2 / KeepRefill.

KeepRefill is a mechanism designed to avoid heavy empty/reactivate loops under remote-heavy workloads. When a medium run becomes empty, it retains the owner-local refill candidate rather than destroying it immediately.

Benchmark Results

The environment is Ubuntu 22.04.5 / Linux 6.8.0-90 / x86_64, RUNS=10, THREADS=16, ITERS=50000.

The representative results are as follows:

Row	HZ8 ops/s	HZ8 post RSS	mimalloc ops/s	mimalloc post RSS	tcmalloc ops/s	tcmalloc post RSS
small_interleaved_remote90	12.023M	2.91 MiB	10.960M	50.98 MiB	23.900M	32.94 MiB
main_interleaved_r90	6.048M	4.57 MiB	4.715M	183.12 MiB	12.178M	90.31 MiB
medium_interleaved_r50	8.128M	3.81 MiB	4.151M	162.54 MiB	15.870M	79.06 MiB

tcmalloc shows strong throughput in many rows.

On the other hand, HZ8 demonstrates significantly lower post-workload RSS.

Therefore, the core proposition of HZ8 is as follows:

HZ8 is not intended to fully replace tcmalloc.

However, it is highly useful as an allocator that returns RSS to a low level while maintaining practical speed.

Comparison: MT lane x remote%

Aligning HZ3, HZ4, HZ5, HZ6, and HZ8 makes the positioning of HZ8 slightly easier to visualize.

Lane	hz3	hz4	mimalloc	tcmalloc	Best HZ5	HZ6	HZ8
main_r0	292.15M	85.63M	146.73M	318.82M	157.44M	16.88M	107.633M
main_r50	31.46M	62.32M	14.26M	64.87M	79.43M	15.08M	29.633M
main_r90	22.31M	67.14M	7.72M	45.42M	62.31M	10.99M	20.610M
guard_r0	318.98M	156.68M	258.19M	375.71M	149.00M	189.48M	224.750M
cross128_r90	2.78M	27.66M	3.52M	7.21M	22.39M	6.38M	37.342k

HZ8 is not universally fast.

In particular, cross128_r90 is a current bottleneck.

However, since HZ8 is a line focused heavily on keeping RSS low, it shouldn't be evaluated solely by throughput.

LargeDirect Experiment

To address the weakness in cross128_r90, we also tested an opt-in profile called LargeDirectOwned.

This provides evidence showing that the performance bottleneck in cross128_r90 stems from the large/direct boundary.

cross128_r90:
  baseline: 62.940k ops/s
  LargeDirect candidate: 2.835M ops/s
  ratio: 45.048x

However, the RSS increases:

peak RSS:
  150.17 MiB -> 260.07 MiB

post RSS:
  107.04 MiB -> 190.61 MiB

For this reason, LargeDirect is not enabled by default.

The default for HZ8 remains the KeepRefill balanced default.

Summary

HZ8 is not the fastest allocator.

However, it has become an allocator with the following distinct characteristics:

HZ8:
  Practical speed
  Low post-workload RSS
  Resilience against remote-heavy workloads
  Cross-thread free correctness
  Fail-closed ownership

If speed is the sole metric, tcmalloc remains incredibly strong.

On the other hand, for workloads where returning RSS to a low level is critical, HZ8 occupies a very compelling position.

Moving forward, we plan to maintain the balanced line of HZ8 while advancing further speed-oriented research under HZ9.

Links

GitHub: https://github.com/hakorune/hakozuna

HZ8 paper / Zenodo: https://zenodo.org/records/21084279

Hakozuna HZ5: Page/Runfast Sidecar Allocator Prototype Design Notes

CharmPic — Wed, 27 May 2026 12:46:50 +0000

Hakozuna HZ5: Design Notes for a Page/Run-First Sidecar Allocator Prototype

In this post, I will outline the design principles for HZ5, a new experimental prototype within Hakozuna, a memory allocator project implemented in C.

Up until now, Hakozuna has evolved primarily around the HZ3 and HZ4 allocator profiles. HZ5 is an extension of that lineage, but it isn't just a branch aimed at slightly accelerating the existing fast path.

In HZ5, we are revisiting the internal architecture of the allocator to explore the following directions:

Page/Run-first classification
Sidecar metadata
Fail-closed ownership determination
Descriptor-owned front-end
Page-oriented remote free
Profile-specific allocator lanes
Experimental build/benchmark paths for Linux and Windows

Rather than a finished product, HZ5 serves as a testbed for rethinking allocator design.

Differences Between HZ3, HZ4, and HZ5

Hakozuna is categorized into several distinct allocator profiles:

First, HZ3 / ACE-Alloc is a profile primarily designed for local-heavy allocation workloads. It focuses on compact memory usage and O(1) pointer-to-bin lookups using PTAG32.

Next, HZ4 is a message-passing / remote-free profile. It is intended for remote-heavy workloads and scenarios with high thread counts.

In contrast, HZ5 is a page/run-first sidecar allocator prototype.

The differences can be summarized as follows:

HZ3 / HZ4:
  Polishing existing profiles.
  Optimizing small object paths and remote-free paths.

HZ5:
  Reimagining classification, ownership, and metadata layout.
  Designing around pages/runs and descriptors.

While HZ3 and HZ4 focus on "strengthening existing profiles," HZ5 is a prototype for "reconstructing the internal structure of the allocator from a different perspective."

HZ5 Design Principles

The core of HZ5 is the concept of classifying pointers in page/run units and consolidating that information into sidecar descriptors.

When performing a free, the allocator needs to determine at least the following:

Does this pointer belong to this allocator? (Ownership)
Which size class, run, or page does it belong to?
Can it be returned locally, or should it be treated as a remote free?
Which front-end or profile should it be dispatched to?

Instead of forcing this metadata to be stored immediately adjacent to the pointer itself, HZ5 explores a direction centered on descriptors corresponding to pages/runs.

The flow looks like this:

user pointer
    |
    v
page / run lookup
    |
    v
sidecar descriptor
    |
    +--> owner
    +--> profile
    +--> size class
    +--> front-end policy
    |
    v
allocation / free dispatch

Crucially, HZ5 is not just about "placing metadata outside." By shifting metadata to a sidecar, we can centralize ownership, profile, and dispatch policy within the descriptor. This means that instead of each front-end making independent decisions, the descriptor dictates "how this pointer should be handled."

Why Sidecar Metadata?

One of the hardest parts of an allocator is the free(ptr) operation.

With malloc(size), the requested size is explicit. However, with free(ptr), only a pointer is provided. The allocator must recover the owner, size class, and return destination from that pointer alone.

Consequently, the placement of metadata is critical.

Some designs place metadata close to the user allocation, which can be advantageous for locality and implementation simplicity. HZ5, however, tests a page/run unit descriptor approach, where the allocator looks up the descriptor via the pointer's page/run.

This design emphasizes:

Clarifying pointer classification at the page/run level.
Centralizing ownership logic within the descriptor.
Organizing policy dispatch for each profile.
Opting for a fail-closed approach for unknown pointers or ambiguous states.

In this context, "fail-closed" means that instead of "proceeding despite uncertainty," the system defaults to the safe side if ownership cannot be confirmed.

In high-speed allocators, there is a temptation to eliminate every extra branch or lookup. However, allocator ownership logic is a high-impact area if corrupted. In HZ5, the clarity of classification is as much a design goal as raw speed.

Current State of the Windows Port

While HZ5 began as an experiment on Linux, we are now establishing native Windows build and benchmark paths.

However, I want to be cautious here: HZ5 is still experimental. It is not yet at a stage where it can generally replace existing allocators across the Windows ecosystem.

Its current role is as follows:

Establishing the pipeline for native Windows builds.
Enabling profile-specific benchmarks on Windows.
Observing workload trends (remote-heavy, local-heavy, mixed, etc.).
Comparing how designs formulated on Linux translate to the Windows environment.

Allocator benchmarks vary wildly depending on the environment. Factors such as OS, compiler, thread count, allocation size distribution, remote-free ratios, and RSS management all shift the results. Therefore, it is safer to treat HZ5 results not as "globally faster on Windows," but as "exhibiting these tendencies in this specific profile/benchmark lane."

Notes on Interpreting Benchmarks

It is difficult to judge an allocator by a single number.

High throughput may come at the cost of excessive RSS. An allocator that excels in local-heavy workloads might struggle when remote frees increase. Performance with small objects might not translate to large allocations or mixed workloads.

As such, HZ5 evaluates benchmarks across several axes:

Local-heavy vs. Remote-heavy.
Small object focused vs. Mixed size.
Throughput vs. RSS.
Scalability with increased thread counts.
Consistency between Linux and Windows.

The danger in allocator evaluation is claiming it is the "best" based on a single successful case. HZ5 is not for making such claims. Rather, it is an experiment to see what happens when the allocator's structure is varied by profile.

Why Assign a DOI?

We have assigned a DOI via Zenodo to HZ5 for this release.

HZ5 Zenodo record: https://zenodo.org/records/20411598
HZ5 DOI: https://doi.org/10.5281/zenodo.20411598
HZ5 all-version DOI: https://doi.org/10.5281/zenodo.20411597

(Note: HZ3/HZ4 also has its own separate artifact DOI.)

GitHub repositories are updated daily, which is great for development but problematic for citing a specific version of a paper, source, or artifact. A Zenodo DOI allows us to freeze the deliverables at a specific point in time.

The HZ5 artifact includes:

HZ5 source code
Design notes
Benchmarks and reproducibility artifacts
English and Japanese paper PDFs

Separating the DOIs for HZ3/HZ4 and HZ5 was intentional. HZ3/HZ4 focuses on the maturity and comparison of existing profiles, while HZ5 represents a different design line as a sidecar allocator prototype. Keeping them separate makes the intent clearer for readers and researchers.

Future Outlook

HZ5 is not "finished"; it has simply reached a stage where its form is organized enough to be shared.

Moving forward, I aim to:

Refine the Windows HZ5 path.
Expand Linux/Windows benchmark coverage.
Categorize stability by profile.
Consolidate comparisons with HZ3/HZ4.
Synchronize papers, READMEs, and artifacts.
Further streamline reproducibility procedures.

The behavior of an allocator can change drastically based on minor implementation details. This is exactly why we need to clarify which profile is effective for which workload under what constraints, rather than just saying it's "fast."

HZ5 is the testbed for that inquiry.

We still need to verify the effectiveness of page/run-first classification, sidecar descriptors, fail-closed ownership, and profile-specific dispatch. However, with this milestone, HZ5 has transitioned from a "prototype folder in a repo" to a "research artifact with design intent and a DOI."

I look forward to growing it further, step by step.

Finishing Hakozuna HZ5: From Experimental Allocator to DOI-Archived Artifact

CharmPic — Wed, 27 May 2026 12:25:37 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

Reviving Hakozuna HZ5: From Allocator Sidecar Prototype to Citable Research Artifact

What I Built

I built and revived Hakozuna HZ5, an experimental page/run-first sidecar allocator prototype written in C.

Hakozuna started as a personal allocator research project. Earlier versions focused on the HZ3/HZ4 allocator profiles:

HZ3 / ACE-Alloc: a compact, local-heavy allocation profile using PTAG32-based O(1) pointer-to-bin lookup.
HZ4: a remote-free / message-passing profile for remote-heavy and high-thread-count workloads.

HZ5 is the next experimental branch of that work. Instead of only optimizing the existing small-object paths, HZ5 explores a more structural design:

page/run-first allocation
sidecar metadata
fail-closed ownership checks
descriptor-owned front-ends
page-oriented remote free
profile-specific Linux allocator lanes
an active experimental Windows native build/benchmark path

The project matters to me because it is not only code. It is a record of trying to turn allocator experiments into something reproducible, understandable, and citable. This finish-up pass was about taking HZ5 from "interesting prototype in the tree" to "documented artifact that another person can inspect, cite, and build on."

Project links:

GitHub repository: https://github.com/hakorune/hakozuna
HZ5 Zenodo record: https://zenodo.org/records/20411598
HZ5 DOI: https://doi.org/10.5281/zenodo.20411598
HZ5 all-version DOI: https://doi.org/10.5281/zenodo.20411597
HZ3/HZ4 Zenodo record: https://zenodo.org/records/20411402
HZ3/HZ4 DOI: https://doi.org/10.5281/zenodo.20411402

Demo

The main demo is the repository and the archived research artifact.

Recommended screenshots or captures to include:

Repository top page showing the Hakozuna README and DOI badges.
hakozuna-hz5/ directory showing the HZ5 source layout.
Windows build documentation showing the active native Windows path.
Zenodo HZ5 record page showing the DOI and uploaded English/Japanese PDFs.
Benchmark or reproducibility documentation from the HZ5 docs.

If adding a short video walkthrough, I would show:

The root repository README and how HZ3/HZ4 and HZ5 are separated.
The hakozuna-hz5/ directory layout.
The Linux and Windows documentation entry points.
The HZ5 design notes and benchmark documentation.
The Zenodo DOI page that archives the HZ5 paper PDFs and artifacts.

The Comeback Story

Before this finish-up pass, HZ5 existed as a promising allocator prototype, but the project was still hard to understand from the outside.

The core ideas were there:

page/run-first allocation
sidecar metadata
descriptor/policy separation
Linux profile experiments
Windows native build and benchmark notes
benchmark and reproducibility notes

But the presentation was not finished. HZ5 was still mixed into the broader Hakozuna story, the top-level README still made the project feel mostly Linux-research oriented, and the relationship between HZ3/HZ4 and HZ5 was not clear enough for a reader landing on the repository for the first time.

The comeback work focused on turning the prototype into a clean research artifact:

clarified HZ5 as a separate experimental profile next to HZ3/HZ4
prepared English and Japanese paper PDFs
published the HZ5 artifact on Zenodo
assigned a citable DOI to HZ5
updated README links so HZ3/HZ4 and HZ5 have separate DOI references
clarified the current Windows HZ5 path as experimental and actively being developed
documented the artifact contents, source layout, and reproducibility materials
made the repository easier to navigate for future readers

The most important change was not one single optimization. It was making the project legible.

An unfinished allocator prototype can be valuable, but it is fragile if the design context only exists in the author's head. This pass made HZ5 easier to preserve, cite, and continue.

My Experience with GitHub Copilot

I used GitHub Copilot as a finishing and review partner, not as a replacement for the allocator design work.

For this project, that distinction matters. HZ5 is low-level C allocator work, so I did not want AI to blindly rewrite memory-management logic or make benchmark claims for me. The core allocator design, implementation direction, and benchmark interpretation were driven by my own work and manually checked.

Copilot helped in the finishing stage:

polishing the README direction
reviewing the DEV post narrative
checking whether the public repository had enough entry points for readers
helping separate the HZ3/HZ4 and HZ5 artifact story
keeping the claims scoped to the actual profiles and platforms

I also used other AI tools for discussion and drafting, and I am disclosing that openly. The useful pattern was not "AI writes the project." It was closer to having an extra reviewer asking: is the story clear, are the links findable, is the scope honest, and would a new reader know where to start?

That was exactly the kind of help this project needed. HZ5 did not need to be reinvented. It needed to be made understandable, archived, and easier to continue.

What Changed Technically

HZ5 is organized as a page/run-first sidecar allocator prototype.

Important areas include:

hakozuna-hz5/: HZ5 allocator source
api/: public allocator API surface
contract/: SpeedLane descriptor ABI and purity contract
policy/: HZ5-native allocation/free dispatch policy
lowpage/, midpagefront/, and largefront/: experimental page/run front-ends
Linux benchmark scripts and profile matrices
Windows native build and benchmark documentation

The HZ5 design direction is different from simply tuning the previous allocator profile. It treats page/run ownership, metadata, and profile dispatch as first-class design concerns.

That makes HZ5 useful as a research branch even when individual benchmark lanes are still experimental. I am intentionally keeping performance claims profile-scoped: the interesting results are tied to specific allocator lanes, workloads, and platforms, not a blanket claim that HZ5 is universally faster everywhere.

What I Learned

Finishing a research-code project is not only about writing more code.

For this project, "finished enough to share" meant:

the source is present
the design intent is written down
benchmark and reproducibility notes exist
the artifact is archived
the DOI is stable
the README tells readers where to start

The biggest lesson was that a prototype becomes much more useful when its boundaries are clear.

HZ5 is not just "the next allocator folder." It is now a named artifact with its own DOI, its own design story, and its own place next to HZ3/HZ4.

What's Next

Next steps for HZ5:

continue Linux allocator profile experiments
continue the active Windows port and native benchmark path
improve benchmark coverage
clarify which HZ5 lanes are stable research artifacts and which are exploratory
add more reproducibility notes
keep HZ3/HZ4 and HZ5 documentation separated but cross-linked

The comeback is not the end of HZ5. It is the point where the project becomes easier to continue.

Language Barriers: A Struggle for Japanese Developers on Dev.to

CharmPic — Sun, 12 Apr 2026 06:58:52 +0000

As a Japanese developer, I love browsing Dev.to to keep up with the latest tech trends. However, I often face a significant "wall" that hinders my learning experience: the language barrier.

The "I Can't Read English Fast Enough" Problem
Let’s be honest—reading long technical articles in English is exhausting when it's not your native language. Even if a headline looks incredibly interesting, the psychological hurdle of clicking on a wall of English text is surprisingly high.
The Limitations of Browser Translation
You might say, "Just use Google Translate or built-in browser features!" But it’s not that simple:

Friction: Having to manually trigger translation for every single page is a tedious extra step.

Accuracy: Standard browser translations often struggle with technical context. They sometimes mangle code snippets or turn specific jargon into nonsensical Japanese, forcing me to switch back to the original text anyway.

A Dream Feature: AI-Powered Native Translation I often find myself wishing Dev.to would implement an integrated AI translation feature.

With the power of modern LLMs, we could have context-aware, high-quality translations at the click of a button. Imagine a "Read in Japanese" toggle right next to the article!

I understand that API costs are a major concern, making this a difficult feature to implement for free. But it’s painful to think about how many amazing insights I’m missing out on just because of the language gap. T^T

I’d love to hear from you:
How do non-native English speakers handle this? Do you use any specific tools or extensions that make your Dev.to experience smoother?

Re-evaluating the ROI of GLM-5.1 Pro After a Massive Price Hike to $680

CharmPic — Sun, 12 Apr 2026 06:29:49 +0000

Headline: GLM-5.1 Pro Price Hike: 3x Increase to $680/year — Time to Look for Alternatives?

I recently received some shocking news regarding the GLM-5.1 Pro plan.
The annual subscription, which used to be a reasonable $180, has suddenly spiked to over $680. That is a staggering 3x increase.

To be fair, the GLM-5.1 Pro plan offered incredible value. Its performance and limits were comparable to the Claude Code $200/month (Max) tier, making it a "hidden gem" for developers. Even at $680/year, one could argue it still offers decent value considering the high-end capabilities.

However, a 600% price jump changes the equation. At this price point, we can no longer ignore other major AI players in the market. It’s time to start comparing the cost-to-performance ratio against other leading LLMs again.

Instant Glory: The App That Makes Every Coder a DEV Challenge Winner

CharmPic — Fri, 10 Apr 2026 17:20:15 +0000

This is a submission for the DEV April Fools Challenge

The Ultimate Ego Booster: Challenge Winner Simulator 2026

What I Built

Have you ever felt the unbearable emptiness of not winning a DEV challenge? The sleepless nights. The existential dread. The nagging suspicion that your code may not be "useless" enough to qualify for greatness?

I built a gloriously unnecessary victory machine that solves all of that.

Challenge Winner Simulator 2026 is a delightfully over-the-top praise engine: enter your name, and the app transforms into a full-blown cosmic celebration of your alleged brilliance. You get dramatic compliments, absurd statistics, galactic proclamations, a cinematic Star Wars-style credit crawl, and enough visual excess to convince any developer that they are, in fact, the chosen one.

And because the joke simply refused to stay in the browser, I also built a Windows desktop version of the app with Flutter and WebView2. So now the same majestic nonsense can be launched as a native Windows app, packaged like a serious piece of software despite being fundamentally unserious in every possible way.

Demo

Web demo:

https://moe-charm.github.io/dev_challenges/20260411winner/index.html

Windows release:

https://github.com/moe-charm/dev_challenges/releases/tag/winner-simulator-20260411

Click the "CELEBRATE!" button to trigger the full auditory and visual experience.

And yes, the music absolutely matters.

Code

Web version:

https://github.com/moe-charm/dev_challenges/tree/main/20260411winner

Windows version:

https://github.com/moe-charm/dev_challenges/tree/main/winner_simulator_app

Release build:

https://github.com/moe-charm/dev_challenges/releases/tag/winner-simulator-20260411

How I Built It

I wanted this to feel both ridiculous and weirdly overengineered, so I kept the web version lightweight while piling on just enough spectacle to make it feel expensive.

Vanilla HTML/CSS/JS: no framework, no mercy, just pure DOM manipulation and theatrical confidence.
CSS transforms and animations: used for the big cinematic crawl, dramatic fades, glowing text, and all the unnecessary grandeur.
Canvas API: used for fireworks and particle effects so the whole thing could sparkle like it was accepting an award nobody asked for.
Web Audio API: used for fanfares, drum rolls, cat-like sounds, and the kind of BGM that insists your name deserves a standing ovation.
i18n logic: supports both English and Japanese, because winning should be internationally embarrassing.
Flutter + WebView2: for the Windows desktop edition, which embeds the same HTML challenge into a standalone app so the joke can live outside the browser too.
Embedded assets: the Windows build packages the challenge inside the app, so it can be distributed as a release ZIP without needing a separate content folder.

The whole project is intentionally excessive for something fundamentally useless, which is exactly what made it fun to build.

Prize Category

Best Ode to Larry Masinter

This project is basically a shrine to the spirit of playful protocol absurdity. It leans hard into the glorious nonsense of 418 I'm a teapot, celebrates the ritual of turning a tiny joke into a grand experience, and fully embraces the idea that the web can be both technically elaborate and completely ridiculous at the same time.

The Golden Teapot is not just a trophy. It is a philosophy.

Google AI Usage (Best Google AI Usage Entry)

This entire project was built in a deep pair-programming session with Antigravity, Google’s agentic AI coding assistant.
Antigravity wasn't just a code generator; it acted as a "Dramatic Consultant" and "Vibe Architect." Here’s how we used it:

Rapid Prototyping: Antigravity generated the complex CSS 3D transforms for the credit crawl and the Canvas-based firework engine from scratch.
Agentic Iteration: We iterated on the visual "wow factor" by asking the AI to "make it more over-the-top" and "add more galactic energy," which led to the inclusion of glitch effects, screen shakes, and dynamic starfields.
Creative Writing: The AI helped craft the hyperbolic, universe-shattering narratives in the crawl and world reaction sections, ensuring the "uselessness" was presented with the highest possible prestige.
Sound Engineering: The AI assisted in integrating the Web Audio API for real-time sound synthesis while managing the external BGM integration.
Cross-Platform Escalation: When our ambitions got too big and we decided to build a native offline Windows desktop app via Flutter, the AI (along with a strategic assist from ChatGPT for Windows WebView2 virtual hosting) helped us bypass local CORS restrictions and materialize the embedded assets natively! The collaboration felt less like "writing code" and more like "directing a digital movie." AI allowed me to focus on the humor and vision while it handled the heavy lifting of the visual and auditory implementation.

NyanZip: The Delightfully Useless Cat-Language Compression App

CharmPic — Fri, 03 Apr 2026 04:44:05 +0000

This is a submission for the DEV April Fools Challenge

NyanZip: The Delightfully Useless Cat-Language Compression App

What I Built

I built NyanZip, a browser-based joke app that takes normal text and turns it into exaggerated cat language.

It has two modes:

A playful "compress" mode that expands text into a noisy stream of meow and MEOW!!
An "ultra" mode that uses real compression under the hood, but still wraps everything in cat-themed nonsense

It also includes optional Gemini-powered cat commentary, because every compression tool deserves a tiny, judgmental reviewer in a bow tie.

The result is intentionally impractical, a little chaotic, and exactly the kind of project that feels right for April Fools.

Demo

Live demo: https://moe-charm.github.io/dev_challenges/20260402april/

Repository: https://github.com/moe-charm/dev_challenges

Code

The code is all in the repository above. The main pieces are:

App shell and UI: 20260402april/index.html
Main interaction logic: 20260402april/app.js
Cat-text encoder and decoder: 20260402april/js/engine.js
Ultra compression pipeline: 20260402april/js/rans.js
Optional AI cat review feature: 20260402april/js/chat.js
Localization strings: 20260402april/js/i18n.js

How I Built It

I built NyanZip with plain HTML, CSS, and JavaScript.

A few things made it fun to put together:

TextEncoder and TextDecoder for converting text to bytes and back
CompressionStream and DecompressionStream for the ultra mode
A simple bilingual UI for Japanese and English
Optional Gemini integration for the cat review comments

I also published it with GitHub Pages so the joke works directly in the browser, with no setup required.

Prize Category

I’d submit this for Community Favorite.

It is intentionally silly, easy to try, and built to make people smile first and ask questions later. The optional Google AI feature adds a fun extra layer, but the core joke stands on its own.

Hakozuna v3.2 Released: Bringing Optimized Memory Allocation to M1 Mac

CharmPic — Thu, 19 Mar 2026 23:29:20 +0000

I've added the main text to chatgpt5.4 ↓

I am pleased to announce the release of Hakozuna v3.2.
While my previous update focused on Windows, this release marks a significant milestone: Full support for M1 Mac.

GitHub Release:https://github.com/hakorune/hakozuna

Zenodo Record: 19120414

DOI: 10.5281/zenodo.19120414

What is Hakozuna?
Hakozuna is a memory allocator designed for small objects, built upon the Box Theory framework. It is currently split into two specialized lineages:

hz3: Optimized for local-heavy / low-RSS workloads.

hz4: Optimized for remote-heavy / high-thread environments.

What’s New in the M1 Mac Update
The primary goal of this update was to establish a seamless workflow on M1 Mac—encompassing development, observation, and running benchmarks for academic papers.

Key Improvements:

Refined Mac Entrypoints: All Mac-specific logic is now consolidated in the mac/ directory.

Pipeline Separation: Decoupled the Build Lane and Observe Lane for better modularity.

Streamlined Paper-Suite: You can now run the full suite of benchmarks required for research papers with a single setup.

Comparative Benchmarking: Integrated mimalloc and tcmalloc into the suite to allow direct performance comparisons against hz3 and hz4.

Performance Insights: Where it Shines
Testing the paper-suite on Mac revealed clear strengths for each allocator:

hz3 showed dominant performance in the Larson benchmark.

hz4 took the lead in MT remote (Multi-threaded remote free) scenarios.

In Redis-like workloads, the winner shifted depending on the specific workload characteristics.

Note on mimalloc-bench: In our subset tests, certain malloc-large treatments were flagged as "no-go."

Segment Registry: For high-remote conditions, we found that slots=32768 yielded better results.

The Takeaway:
The M1 Mac results reinforce our core philosophy: rather than trying to create a "one-size-fits-all" allocator, partitioning "boxes" based on specific conditions leads to superior efficiency.

Conclusion
With v3.2, "Mac support" is more than just a port—it is a functional environment ready for rigorous academic benchmarking.

Summary of Gains:

Improved DX (Developer Experience) on M1 Mac.

Automated and reliable comparative benchmarking via paper-suite.

Clearer functional boundaries between the hz3 and hz4 lineages.

Next, I plan to utilize this Mac environment to refine the supplementary data and further validate my research for the upcoming paper.

Porting Hakozuna to Windows Native: Lessons from Benchmarking hz3 and hz4 beyond Ubuntu

CharmPic — Tue, 10 Mar 2026 14:36:09 +0000

The Windows native support for Hakozuna has finally moved past the "it runs" stage to the "measurable and comparable" stage.

Previously, my allocator research was focused on Ubuntu. The major milestone here is that the entire pipeline—from source builds to application benchmarks—is now fully operational on Windows.

The TL;DR: hz3 remains incredibly strong on Windows. Meanwhile, while hz4 is functional and reproducible, it hasn't yet consistently outperformed others in real-world application benchmarks on Windows without specific tuning. Investigation is ongoing.

What’s New?
This update isn't just about successful compilation. I've established a robust foundation for comparative allocator research on Windows:

Native Comparisons: Capability to benchmark hz3, hz4, mimalloc, tcmalloc, and CRT on Windows.

Real-world Workloads: Support for not just synthetic benchmarks, but also real-world Redis and memcached-style loads.

Infrastructure: Organized public runners, documentation, and benchmark summary repositories.

Publications: Updated both Japanese and English versions of the research paper with Windows-specific appendices.

Distribution: Updated GitHub Releases, Zenodo, and public PDFs.

The Challenges of Windows Porting
Porting to Windows was far from a simple "copy-paste" from Linux. The difficulties lay less in the allocator's hot path and more in the surrounding ecosystem:

Build Toolchains: Significant differences in build boxes and environments.

Linking Nuances: Handling DLL vs. static link mode variations.

OS-Specific APIs: Architecting around VirtualAlloc paths.

Porting Workloads: Bringing memcached, memtier, and Redis into a native Windows environment.

Fixed Costs: Noticing OS-specific fixed costs that were negligible on Linux but prominent on Windows.

Interestingly, some design choices and default "knobs" that worked perfectly for hz4 on Ubuntu didn't translate into a winning strategy for Windows application benchmarks. This highlights the fascinating—and exhausting—reality of how an allocator's behavior changes depending on the OS.

Key Benchmark Findings
While the Ubuntu results remain the primary baseline, the Windows native tests revealed:

hz3 Dominance: Highly performant in real Redis workloads (balanced, kv_only, list_only, highpipe).

Workload Sensitivity: In memcached external-client tests, the "winning" allocator shifts depending on the specific workload.

hz4 Potential: While hz4 shows promise in synthetic benchmarks with specific tuning, it showed mixed signals in real Redis balanced tests.

Current Verdict:

Default: Use hz3.

Research Focus: Use hz4 for remote-heavy and high-thread count scenarios.

Paper and Release Updates
I've synchronized all assets with this release:

Updated Japanese & English PDFs.

Added Windows Native supplemental tables.

GitHub Release v3.1 & Zenodo v3.1 (with updated DOI).

Latest papers are available directly in the repo at docs/paper/main_ja.pdf and main_en.pdf.

Personal Insights
The most intriguing discovery was seeing "boxes" (design components) that were unremarkable on Ubuntu suddenly show significant impact on Windows—and vice versa.

The gap between "performing well in synthetics" and "winning in real apps" is crucial. It’s a stark reminder that in allocator research, looking "fast" on paper matters far less than proving which workload you actually conquer.

What’s Next?
"Completion" of Windows support actually means reaching a level of maturity where research can truly begin. Moving forward, I plan to:

Further optimize hz4 specifically for Windows.

Refine common profiles and OS-specific configurations for Ubuntu/Windows.

Improve paper and documentation readability.

Evolve the "Box Theory" into the next architectural phase.

If there’s interest, my next posts will dive deeper into:

Why I separated hz3 and hz4.

How to design an allocator using Box Theory.

The technical nuances of what looks different on Windows compared to Linux.

https://github.com/hakorune/hakozuna