DEV Community: CharmPic

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

Does Audio Cable Affect Sound? I Built a Physics Simulator to Find Out.

CharmPic — Sat, 07 Mar 2026 07:54:38 +0000

Discussing whether audio cables change the sound often turns into a never-ending debate based on subjective impressions.
"Long RCA cables make the sound feel muddy."
"Silver wires add a glossy texture to the highs."
"Extremely long speaker cables lose their punch."

These anecdotes have existed for decades, but personal experiences alone don't reach a conclusion. Conversely, simple IDEAL circuit models often fail to explain what audiophiles actually hear.

That's why I decided to stop looking at the cable in isolation. Instead, I built a simulator that treats the entire signal path as a single physical system:

Physical characteristics of the cable

Interaction with connected equipment

Amplifier behavior

Response degradation in the time domain

Analytical metrics closer to human perception

The Project
GitHub: https://github.com/moe-charm/audio-chain-physics

Live Demo: https://audio-chain-physics.streamlit.app/

Zenodo DOI: https://doi.org/10.5281/zenodo.18898657

What I Built
Audio Chain Physics is a research-oriented simulator designed to handle the audio chain in stages. It models the following layers:

RLGC Model of the Cable: Moving beyond simple resistance.

Interface Interaction: Output impedance, input capacitance, and common return paths.

Non-linear Elements & Small-signal Stability: How the amplifier reacts to the load.

Dielectric Absorption: Approximating "trailing" responses.

Time-Domain Analysis: Group delay, impulse response, step response, and "TailRatio."

The core philosophy is not just analyzing the cable itself, but how the cable changes the operating conditions of the equipment.

For example, the propagation delay of a 3-meter cable is negligible. It’s too small to be an "audible difference" on its own. However, when you combine Output Impedance + Cable Capacitance + Load Capacitance + Amp Phase Margin + Complex Speaker Load, the settling time, group delay, and ringing change. This synergy is likely what manifests as a perceptible difference in sound.

What the Simulator Reveals (So Far)
The most significant result is that under extreme conditions, sound quality degradation can be clearly reproduced through calculation.

In scenarios such as:

Long, poor-quality RCA cables

Excessively long speaker cables

Amplifiers with high output impedance

The simulation clearly shows:

High-frequency attenuation or peaking

Distorted group delay

"Tails" in the impulse response

Ringing in the step response

Drop in Damping Factor

This confirms a solid starting point: If cables or connection conditions are handled poorly, the response of the entire audio chain will degrade.

What Still Remains Unexplained
To be completely honest, I haven't yet fully explained the more subtle audible differences I’ve experienced myself—those "nuances" that are hard to put into numbers:

The sense of "glossiness" or "air" in the highs.

Changes in "soundstage" or "depth."

The feeling of the sound becoming "thicker" or "denser."

While I can reproduce degradation in extreme cases, I cannot yet claim to have simulated those delicate nuances under "normal" high-end equipment conditions.

This is my current conclusion: While degradation due to extreme conditions is reproducible, explaining subtle sonic nuances requires further research. This feels like the most honest scientific stance at this stage.

Future Roadmap
There is still a lot of work to be done. My focus will move toward:

Validation: Comparing simulation results with real-world measurement data.

Complex Loads: Supporting measured speaker impedance curves.

Stochastic Models: Modeling RF interference, hum, and poor contact points.

Controlled Listening Tests: Correlating sim data with subjective perception.

I want to move from "degradation happens at extremes" to "explaining why we hear what we hear in everyday listening."

If you’re interested in the physics of audio, please check out the GitHub repo or the live demo!

GitHub: https://github.com/moe-charm/audio-chain-physics

Live Demo: https://audio-chain-physics.streamlit.app/

Building My Own Image Engine "HakoNyans": I Beat PNG, but WebP is a Wall

CharmPic — Sat, 21 Feb 2026 03:05:12 +0000

Hi DEV community! 👋

I originally started developing a custom image engine called HakoNyans for a DEV Challenge. The challenge has ended, but my passion hasn't—I'm still actively building and refining it every day.

The Milestone: Beating PNG
I'm happy to report that HakoNyans has officially surpassed PNG! Getting the architecture and logic right to beat such a classic, widely-used format was a huge milestone for this project.

The Current Struggle: The WebP Wall
However, my next target is WebP, and let me tell you... WebP is incredibly strong.

Here is where HakoNyans currently stands against WebP:

Processing Speed: Currently 20% slower.

Compression Ratio: Losing by 20% (resulting in larger file sizes).

I've hit a bit of a wall. Competing with WebP's highly optimized compression logic is no easy task. Closing this 20% gap in both speed and size is my current obsession.

Let's Discuss!
I'm continually pushing the limits of my current algorithms, but I'd love to hear from the community.

Has anyone else here tried building an image codec or data compression engine from scratch?

What optimization techniques or mental models helped you break through performance plateaus?

Any advice, feedback, or shared experiences would be greatly appreciated. I'll keep pushing HakoNyans forward!

4 Months of Developing a Memory Allocator: Updating "Hakozuna" to v3.0 (hz3/hz4)

CharmPic — Tue, 17 Feb 2026 20:13:31 +0000

4 Months of Developing a Memory Allocator: Updating "Hakozuna" to v3.0 (hz3/hz4)

Introduction

I am excited to announce the release of Hakozuna, a high-performance memory allocator.

Repository: [https://github.com/hakorune/hakozuna]
Paper & Artifacts (Zenodo v3.0): [https://zenodo.org/records/18674502]

Over the past four months, I’ve been through countless cycles of implementation and benchmarking, optimizing the performance against industry standards like mimalloc and tcmalloc.

The biggest takeaway from this journey? Instead of trying to create a "one-size-fits-all" configuration to win every race, the real solution was to branch out into specialized profiles based on use cases.

hz3: Optimized for local-heavy / Redis-like workloads.
hz4: Optimized for remote-heavy / high-thread workloads.

What is Hakozuna?

Hakozuna is built on Box Theory—a design philosophy centered on aggregating boundaries to isolate responsibilities. During development, I prioritized:

Zero overhead in the hot path: Eliminating unnecessary operations where it matters most.
Reversibility: Ensuring every optimization can be toggled via compile flags.
Observability: Using A/B benchmarking and one-shot counters to make performance data transparent.

Benchmark Summary (Ubuntu Native, Representative Values at RUNS=10)

MT lane x remote% (Ops/s)

Configuration	`hz3`	`hz4`	`mimalloc`	`tcmalloc`
main_r0	375.4M	137.4M	224.2M	232.7M
main_r50	66.5M	78.1M	17.9M	84.3M
main_r90	62.6M	67.6M	13.0M	54.9M
cross128_r90	1.80M	50.65M	10.94M	7.50M

Redis-like (Median ops/s)

hz3: 571,199
mimalloc: 568,740
tcmalloc: 568,052
hz4: 560,576

Choosing the Right Version

For most scenarios, I recommend starting with hz3 as the default. Switch to hz4 only if your workload is strictly remote-heavy or involves extremely high thread counts.

# hz3 (Default)
cd hakozuna/hz3
make clean all_ldpreload_scale
LD_PRELOAD=./libhakozuna_hz3_scale.so ./your_app

# hz4 (Remote-heavy / High-thread)
cd ../hz4
make clean all
LD_PRELOAD=./libhakozuna_hz4.so ./your_app

Key Lessons Learned

Through this development process, I gained two major insights:

Identify "NO-GOs" Early Documenting and archiving optimizations that didn't work was just as important as the successes. Moving on quickly from failed paths ultimately accelerated the final progress.
There is no single "winning" path Stability in performance numbers only came after separating the logic: hz3 for local-heavy and hz4 for remote-heavy/high-thread counts. Specialization is the key to outperforming general-purpose allocators in specific niches.

HakoNyans: A Transparent Lossless Codec Challenge (with GitHub Copilot CLI)

CharmPic — Sat, 14 Feb 2026 17:11:27 +0000

This is a submission for the GitHub Copilot CLI Challenge

## What I Built

I built HakoNyans, an experimental image codec focused on practical decode speed and transparent lossless results
across different image types (photo, anime, UI/screen).

For this challenge, I focused on two things:

A clearer lossless workflow in CLI
Added a new command:
hakonyans encode-lossless <in.ppm> <out.hkn> [preset: fast|balanced|max]
This makes lossless testing reproducible from the terminal without custom scripts.
Reproducible visual and metric snapshots
Prepared a dedicated asset pack for challenge demos:
docs/assets/devchallenge_2026_01_21/
Included side-by-side comparisons and both win and lose cases (to keep reporting honest).

What this project means to me:

I wanted to show not just “best-case screenshots,” but a realistic engineering snapshot:
where HKN already wins (some natural-photo cases), and where PNG is still much stronger (some structured/UI-like cases).

## Demo

Repository:
https://github.com/hakorune/HakoNyans
Challenge asset pack:
https://github.com/hakorune/HakoNyans/tree/main/docs/assets/devchallenge_2026_01_21

### Screenshots

Main comparison

Main comparison metrics (Artoria, lossless)

Source PNG (Artoria): 17,669,320 bytes
Env: HAKONYANS_THREADS=1
Command: ./build/hakonyans encode-lossless <in.ppm> <out.hkn> <preset>
Encode time: 2-run median wall time

| Preset | HKN bytes | PNG bytes | PNG/HKN | Encode time |
| balanced | 17,374,550 | 17,669,320 | 1.0170 | 2.94 s |
| max | 16,767,516 | 17,669,320 | 1.0538 | 101.18 s |

PNG/HKN > 1.0 means HKN is smaller.

Lossless win case (nature_01)

Lossless lose case (hd_01)

### Example metrics snapshot (fixed6, max preset)

nature_01: HKN 812,567 bytes vs PNG 1,281,481 bytes (PNG/HKN = 1.577)
nature_02: HKN 999,685 bytes vs PNG 1,446,470 bytes (PNG/HKN = 1.447)
hd_01: HKN 699,858 bytes vs PNG 8,785 bytes (PNG/HKN = 0.0126)

So currently:

HKN can beat PNG on some photo-like content.
PNG still dominates some structured/worst-case images.
The project is actively improving both sides.

## My Experience with GitHub Copilot CLI

GitHub Copilot CLI was most useful for my fast implementation loop:

Refactoring large headers into smaller units safely
Adding a new CLI command (encode-lossless) while preserving existing behavior
Running repetitive verify loops quickly (build, ctest, benchmark checks)
Generating and validating challenge-ready visual assets from command pipelines

The biggest impact was speed + consistency.
I could iterate quickly in terminal-first workflows while keeping changes verifiable (tests, checksums, RMSE checks,
benchmark CSVs).

DEV Community: CharmPic

Hakozuna HZ5: Page/Runfast Sidecar Allocator Prototype Design Notes

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

Differences Between HZ3, HZ4, and HZ5

HZ5 Design Principles

Why Sidecar Metadata?

Current State of the Windows Port

Notes on Interpreting Benchmarks

Why Assign a DOI?

Future Outlook

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

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

What I Built

Demo

The Comeback Story

My Experience with GitHub Copilot

What Changed Technically

What I Learned

What's Next

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

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

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

The Ultimate Ego Booster: Challenge Winner Simulator 2026

What I Built

Demo

Code

How I Built It

Prize Category

Google AI Usage (Best Google AI Usage Entry)

NyanZip: The Delightfully Useless Cat-Language Compression App

NyanZip: The Delightfully Useless Cat-Language Compression App

What I Built

Demo

Code

How I Built It

Prize Category

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

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

Does Audio Cable Affect Sound? I Built a Physics Simulator to Find Out.

Building My Own Image Engine "HakoNyans": I Beat PNG, but WebP is a Wall

4 Months of Developing a Memory Allocator: Updating "Hakozuna" to v3.0 (hz3/hz4)

4 Months of Developing a Memory Allocator: Updating "Hakozuna" to v3.0 (hz3/hz4)

Introduction

What is Hakozuna?

Benchmark Summary (Ubuntu Native, Representative Values at RUNS=10)

MT lane x remote% (Ops/s)

Redis-like (Median ops/s)

Choosing the Right Version

Key Lessons Learned

Links

HakoNyans: A Transparent Lossless Codec Challenge (with GitHub Copilot CLI)