DEV Community: Lori-Shu

Bridging the Gap: How Software Displays Modern 10-bit HDR Content on SDR Monitors

Lori-Shu — Sun, 08 Nov 2026 15:58:48 +0000

In the modern media landscape, producing 10-bit HDR content has become the unquestioned industry standard. Yet, consumer display hardware hasn't evolved at quite the same breakneck pace; a vast majority of monitors still operate natively on the 8-bit SDR standard.

Despite this hardware mismatch, we expect to seamlessly stream and view cutting-edge HDR media on our everyday screens. This exact friction birthed the software transformation pipeline. To bridge the gap and faithfully render 10-bit HDR content on legacy hardware, media players and graphics pipelines rely on two major transformations: Color Space Conversion and Tone Mapping.

1. Color Space Conversion (BT.2020 to BT.709)

Most 10-bit HDR content is mastered in BT.2020NCL (Non-Constant Luminance), a wide-gamut standard defined by the International Telecommunication Union (ITU). However, standard monitors are calibrated for BT.709—the traditional sRGB-equivalent color space.

Because contemporary displays and video pipelines must support both, mainstream media software uses a transformation matrix on the fly. This matrix maps the massive color volume of BT.2020 down into the narrower boundaries of BT.709 without completely distorting the color palette.

2. Tone Mapping (Adapting Luminance for SDR)

Color space conversion alone isn't enough; if you only translate the colors without adjusting brightness, the image will look washed out or severely clipped because HDR's peak luminance far exceeds what an SDR panel can physically emit.

To solve this, software employs tone mapping, which handles different HDR mastering standards:

SMPTE ST 2084 (Perceptual Quantizer / PQ): Widely adopted in cinema and professional media, PQ uses an absolute luminance scale (measured in nits, up to 10,000).

ARIB STD-B67 (Hybrid Log-Gamma / HLG): Popular in broadcasting, HLG is relative rather than absolute, making it inherently more backward-compatible with SDR displays—though often at the cost of peak visual fidelity compared to PQ.

To make these high-brightness formats viewable on a standard SDR monitor, media software compresses the dynamic range, mapping ultra-bright highlights down into the limited brightness range of standard panels.

Engineering Insight

Frictions between hardware evolution and software capability are a constant reality in systems engineering. Technology never moves at a uniform pace across every sector; hardware cycles are slow and capital-intensive, while software can iterate almost overnight. Engineers relentlessly build clever abstractions—like dynamic color matrices and real-time tone mapping—to bridge these physical gaps and keep our digital experiences seamless.

Rust Toolchain Migration: Supercharging Build Times with LLD on Windows

Lori-Shu — Tue, 03 Nov 2026 14:35:07 +0000

Recently, driven by the need to slash compilation and linking times, I migrated the toolchain for my pet Rust project. Previously, the project relied on the battle-tested stable-x86_64-pc-windows-gnu toolchain using the legacy ld linker—a notorious bottleneck responsible for much of Rust's sluggish build reputation on Windows.

While the speed payoff of switching to the lld linker was immediate, the transition exposed a labyrinth of subtle, platform-specific hurdles on Windows. Before diving into the migration details, let’s quickly break down the anatomy of how Rust compiles code.

Under the Hood: The Rust Compilation Pipeline

If you trace a Rust file from source text to binary, it moves through several sophisticated stages:

AST (Abstract Syntax Tree): rustc parses the source code into an AST, where macros are expanded.

HIR (High-Level Intermediate Representation): The AST translates into HIR. This is where Rust’s borrow checker flexes its muscles, enforcing memory safety and ownership rules.

MIR (Mid-Level Intermediate Representation): The HIR simplifies into MIR, marking the end of rustc's proprietary heavy lifting.

LLVM Optimization: The pipeline hands off to the LLVM infrastructure. MIR is translated into platform-agnostic bitcode, where LLVM applies State-Of-The-Art (SOTA) optimizations. (LLVM’s power is precisely why Apple, Google, and massive Linux/Windows ecosystems rely on it).

Code Generation & Linking: LLVM generates machine code for specific target architectures, after which linkers bundle system and third-party libraries into the final executable.

The Windows Toolchain Maze: GNU vs. GnuLLVM

While Rust packages essential LLVM components out of the box, target-specific concerns—like operating system interfaces, C calling conventions, and ABIs—are bound to external packages.

The GNU Target (stable-x86_64-pc-windows-gnu): Simply requires MinGW-W64-builds to complete the toolchain pipeline.

The GnuLLVM Target (stable-x86_64-pc-windows-gnullvm): Requires standalone LLVM and llvm-mingw.

Navigating llvm-mingw can be jarring due to the sheer volume of overlapping binaries. Essentially, stock LLVM builds provide target-agnostic components that aren't inherently tied to MSVC or GNU C conventions. llvm-mingw bridges this gap, translating raw machine code into standard MinGW-compatible formats that Windows can execute.

Lessons Learned from the Trenches

Taming Windows toolchains is famously painful. It's the primary reason many developers flee to environments like MSYS2 or Windows Subsystem for Linux (WSL). However, because my pet project is a GUI application, native Windows integration is a must, and WSL's graphical UI maturity still introduces friction for native desktop apps.

The Golden Rule: Infrastructure upgrades like compiler toolchains should always be treated with extreme caution. Rigorous staging and testing are non-negotiable—never perform radical toolchain experiments blindly in production environments.

Bonus: Alternative Paths to Speed

If you want to tap into lld's blazing speed without undergoing a full toolchain migration, you can adopt it simply by changing some settings of your projects. Modern alternatives are pushing the boundaries of link-time performance even further. If you are feeling adventurous, check out these next-gen linkers built by hard-core pioneers:

mold — A high-performance, modern linker designed to drastically reduce build times.

wild — An experimental, incredibly fast linker written in Rust.

Optimize Service Logic of Your Rust Code by Replacing Arc::clone with Borrowing

Lori-Shu — Thu, 29 Oct 2026 06:23:28 +0000

In a previous post, I discussed the performance benefits of exposing references rather than cloning data outright. While refining my application logic recently, I realized that this principle applies broadly: eliminating unnecessary clones is one of the easiest ways to clean up general Rust code.

The `Arc::clone` Trap

Rust beginners often attempt to resolve stubborn borrow checker errors by simply cloning variables and moving them into closures or functions. While move is a fundamental idiom in Rust, excessive cloning should be avoided in production-grade code.

I’ve certainly been guilty of scattering Arc::clone across a codebase just to satisfy the compiler and push a feature across the finish line. The underlying motivation is often a casual approach to Arc.

Arc (Atomic Reference Counted pointer) is a foundational smart pointer for multithreaded Rust. Even though cloning an Arc is far more lightweight than cloning a deep struct, its overhead is non-trivial:

Atomic Operations: Cloning an Arc triggers atomic increment instructions.

Cache Invalidation: These atomic operations cause cache line invalidation across CPU cores.

Contention: High-frequency cloning under heavy concurrency can introduce subtle performance bottlenecks.

Standard borrowing (& or &mut), by contrast, incurs none of these costs.

Conclusion

Aside from scenarios where ownership transfer is strictly required--such as spawning new threads or moving data across async task boundaries—we should look to optimize our Rust architecture by replacing unnecessary Arc::clone calls with proper borrowing. Clean code isn't just about compiling successfully; it's about respecting ownership and memory layout.

Implicit Function or Implicit Type? Demystifying Rust Closures

Lori-Shu — Thu, 22 Oct 2026 14:54:15 +0000

Closure Note

Rust closures often feel like a mysterious monolith, but they were born to solve a fundamental need: first-class functions behavior with state capture.

In conventional linear execution, named functions are invoked immediately. Standard function pointers (fn()) let you store and call functions later, but they lack a crucial capability—they cannot capture or remember variables from their surrounding environment.

That is why closures were introduced to Rust. Although we casually refer to closures as "functions," it is much more accurate to think of them as concrete, compiler-generated types.

How Closures Work Under the Hood

When you write a closure, it captures the variables it needs from its enclosing scope. Behind the scenes, the Rust compiler:

Generates an anonymous, unique type for the closure.

Stores the captured variables inside fields of this generated struct.

Applies borrowing rules: By default, it uses "reborrowing" mechanics identical to regular function calls with reference arguments.

Implements function traits: The compiler automatically implements one of the core closure traits based on how the variables are captured:

Fn: Implemented if the closure only borrows captured variables immutably. It can be called multiple times.

FnMut: Implemented if the closure borrows any variables mutably. It can also be called multiple times, modifying state along the way.

FnOnce: The parent trait of the others. If the closure takes ownership of captured variables (such as via the move keyword) or consumes them, it implements FnOnce and can typically only be executed once.

The Role of the move Keyword

As counterintuitive, closure with move won't take ownership of the instances behind reference types. It just moves the variable into the closure. What is different from closure without move is that the outer variables (with owned or reference types) will be invalid after the closure is constructed.

Because of Rust's rigorous borrow checker, we frequently rely on the move keyword with closures to satisfy lifetime constraints—especially when spawning threads or returning closures from functions. Instead of borrowing variables from the stack, move forces the closure to take ownership of those variables, moving them directly into the compiler-generated struct.

While optimizing Rust code often involves careful lifetime management, mastering how closures handle memory under the hood is a rare and invaluable skill for writing high-performance systems.

To Borrow or To Clone: The Rust Struct Exposure Dilemma

Lori-Shu — Wed, 14 Oct 2026 03:43:23 +0000

Every Rust developer eventually hits a crossroads when trying to expose private struct fields cleanly. Here is a breakdown of the common approaches, their hidden costs, and how to strike the right balance.

1. The Brute-Force Route: Making Fields Public

The most direct fix for visibility issues is simply marking fields pub. While this instantly grants access, it sacrifices encapsulation and can introduce dangerous side effects. Giving outside callers full access means anyone can mutate internal state or even move values out of the struct entirely, risking broken invariants.

2. The Convenience Trap: Overusing Clone

Another route is writing getter methods that return cloned instances. It is frictionless enough that developers sometimes abuse it purely as an escape hatch to silence the borrow checker.

The downside? Cloning performs a deep copy of the underlying memory. If you are exposing large data structures, frequent cloning introduces hidden CPU overhead and memory bandwidth pressure.

3. The Idiomatic Choice: Strategic Borrowing

The high-performance solution is leveraging references and lifetime annotations. Although lifetimes can steepen the learning curve for developers coming from garbage-collected languages, borrowing is vastly more efficient than cloning. No matter how massive the original type is, a reference only copies a pointer-sized footprint.

Yet, zero-cost abstractions demand careful design. Combining complex lifetime bounds with multi-threaded safety and thread-pool concurrency can escalate quickly. Ultimately, writing production-grade Rust comes down to balancing clean borrowing strategies with minimizing resource contention.

From Thread to Task: Modern Concurrency Patterns

Lori-Shu — Thu, 08 Oct 2026 14:48:06 +0000

While conventional OS threading models offer raw parallel execution, modern programming languages have evolved distinct abstractions to overcome thread overhead and ergonomics challenges.

TypeScript & Python: Single-Threaded Event Loops

TypeScript and Python historically embraced a single-threaded event loop architecture, multiplexing execution over a single OS thread to yield non-blocking I/O and "emulated" parallelism without the headache of thread-resource management or lock contention. However, to bypass the CPU bottlenecks of this single-threaded design, Python has recently moved toward true OS-thread concurrency models (i.e., free-threaded CPython).

Go & Java: Managed Green Threads

Go and Java (via Virtual Threads) opted for user-space green-threading models (M:N scheduling), where a fixed pool of carrier OS threads executes millions of lightweight tasks. This drastically boosts throughput while preserving a synchronous, blocking programming style that seamlessly blends with legacy language syntax--bypassing the ecosystem splits common to traditional async models.

Rust: Stackless State Machines

Rust takes a radically explicit approach by compiling async functions into zero-cost, stackless state machines. Async tasks in Rust are typed as Futures—essentially tagged enums representing distinct state transitions. Built around an async/await syntax, Rust futures are passive by default and only execute when explicitly polled by an async runtime/scheduler.

Trade-offs & Abstraction Costs

No single model completely solves concurrency without trade-offs:

The Function Coloring Problem: Both TypeScript and Rust inherit function coloring via async/await, creating friction when bridging synchronous blocking contexts with async runtimes.
Ergonomics & Mental Overhead: Java’s approach can demand additional developer overhead when orchestrating complex future/task pipelines manually.
Implicit Contexts: Go’s seamless approach feels nearly optimal, yet it conceals execution boundaries by making concurrent tasks look identical to standard synchronous functions.

Architectural Decisions: Multi-Process vs. Multi-Threading

Lori-Shu — Wed, 30 Sep 2026 15:47:28 +0000

When designing parallel and concurrent systems, developers invariably face a core architectural dilemma: Multi-Process vs. Multi-Threading.

If you learned systems programming in C, you likely remember fork() and join() (or waitpid()) as the default primitives for spawning and managing execution units. In the early days of Linux, POSIX thread implementations were notoriously fragile, making process cloning the de facto standard for parallelism.

However, as operating systems matured and production-grade threading models stabilized, a massive wave of systems migrated toward multi-threading.

The Case for Multi-Threading

Multi-threaded architectures offer compelling performance and developer-experience advantages:

Seamless Memory Sharing: Sharing state and pointers across threads is fundamentally simpler and cheaper than orchestrating Inter-Process Communication (IPC) mechanisms like shared memory segments, pipes, or Unix domain sockets.
Lower Allocation Overhead: Spawning a thread carries significantly less CPU and memory overhead compared to cloning an entire process address space.
Predictable Lifecycle Management: Thread lifecycles are naturally tied to their parent process. When the host process exits, its threads are cleaned up automatically, reducing the risk of dangling zombie processes or lingering resource leaks.

Why Multi-Process Is Far From Obsolete

Despite the popularity of threads, the multi-process model remains indispensable for specific high-assurance workloads:

Error Isolation & Fault Tolerance: A panic, segmentation fault, or unhandled exception in a worker thread can crash the entire application. In contrast, a crashed process dies in isolation, leaving the primary supervisor running intact—making it ideal for sandboxing and plugin ecosystems (e.g., modern web browsers).
Granular Observability & Debugging: Because each child process operates with a distinct PID, OS-level tools like htop, perf, and strace can monitor resource usage, memory footprints, and system calls per unit much more cleanly than inside a dense multi-threaded runtime.
Language-Specific Workarounds: In languages constrained by a Global Interpreter Lock (GIL)—such as Python or Ruby—multi-processing remains the primary strategy for bypassing single-core bottlenecks to achieve true multi-core utilization.

Summary

Neither pattern is inherently superior; the optimal choice depends on your application's constraints:

Reach for Multi-Threading when performance, shared memory access, and low latency are your top concerns.
Reach for Multi-Processing when safety, crash resilience, and strict fault isolation outweigh the overhead of IPC.

Shrinking Your Rust Allocations: Replacing Vec and String with Boxed Slices

Lori-Shu — Mon, 28 Sep 2026 16:00:43 +0000

When building high-performance systems in Rust, managing dynamic allocations efficiently is key to keeping your memory footprint lean.

Developers often reach for Vec<T> and String by default whenever they need owned collections. However, if data is read-only after creation—such as static assets, loaded images, or unmodifiable configuration strings—holding onto expandable collections wastes unnecessary bytes on the stack.

By "downgrading" fixed-size collections from dynamic types like Vec<T> and String to boxed slices like Box<[T]> and Box<str>, you can trim excess heap metadata without sacrificing ownership.

Why Box<[T]> Beats Vec for Static Data

A Vec<T> and a String carry 24 bytes of stack metadata (on 64-bit systems):

A heap pointer (8 bytes)

The current length (8 bytes)

The allocated capacity (8 bytes)

Because dynamic vectors must support growing and shrinking, they maintain spare capacity. But if your data is loaded once and never resized, tracking capacity is unnecessary overhead.

Converting to a boxed slice (Box<[T]> or Box<str>) drops the capacity field entirely, shrinking stack metadata down to 16 bytes (pointer + length). Across thousands of instances, this metadata reduction adds up quickly.

Practical Implementation

Here is how you can convert dynamic types into boxed slices using .into_boxed_slice() and .into_boxed_str():

use std::path::Path;

pub struct NamedImage {
    buf: Box<[u8]>,
    name: Box<str>,
}

impl NamedImage {
    pub fn new(img_path: &Path, img_name: String) -> Self {
        // Load raw image data and shrink allocation from Vec<u8> to Box<[u8]>
        let buf = image::load_png(img_path).into_boxed_slice();

        // Convert owned String to Box<str>, dropping capacity overhead
        let name = img_name.into_boxed_str();

        Self { buf, name }
    }
}

When .into_boxed_slice() or .into_boxed_str() is called, Rust reallocates or re-slices the heap allocation to match the exact length of the data, freeing any excess capacity back to the allocator.

Beyond &self and &mut self: Rust’s Underrated Method Receivers

Lori-Shu — Sun, 27 Sep 2026 16:51:34 +0000

If you write Rust, you interact with &self and &mut self every single day. They are the backbone of idiomatic Rust, signaling at a glance whether a method reads from or mutates an instance.

However, Rust’s ownership and type system goes deeper than just standard references. Tucked inside the language specification is arbitrary self types—allowing specialized receivers like self: &Arc and self: &Mutex.

While rare in everyday application code, these self-types are power tools when architecting concurrent and multi-threaded systems.

The Standard Receivers: A Quick Refresh

Before diving into the exotic variants, here is how the standard receivers behave:

&self (Shared Reference): Borrow the instance immutably. Multiple callers can execute this method simultaneously without mutating state.

&mut self (Exclusive Reference): Borrow the instance mutably. Guarantees exclusive access to modify the object's internal fields.

self (By Value): Consume the instance, taking full ownership and moving it into the method.

The Power Receivers: &Arc and &Mutex

In concurrent Rust, state is frequently wrapped inside thread-safe smart pointers or synchronization primitives—most notably Arc<T> (Atomic Reference Counting) and Mutex<T>.

Normally, calling a method on an Arc requires cloning the Arc explicitly before calling a standard method:

// Traditional approach
let shared_node = Arc::new(MyNode::new());
MyNode::process_node(shared_node.clone());

By explicit receiver typing, you can make the method itself demand the smart-pointer wrapper directly on self:

impl MyNode {
    // Requires the caller to pass a reference to the Arc wrapping this instance
    pub fn spawn_task(self: &Arc<Self>) {
        let clone = Arc::clone(self);
        tokio::spawn(async move {
            clone.do_work();
        });
    }
}

How do I encapsulate a tool type in Rust?

Lori-Shu — Mon, 31 Aug 2026 14:05:56 +0000

I’ve been wrapping a few tool types in a Rust project lately and ran into some friction. Along the way I picked up a few practical lessons on what a clean tool type should look like. Here’s what I landed on:

Decouple unrelated fields:
The first and hardest step is deciding which fields the type actually owns. Real-world code is full of types that do more than they should; those extra responsibilities are usually candidates for being pulled out.

Prefer immutable interfaces:
A good tool type should expose only immutable methods so callers never need a mutable handle. Rust’s type system pushes you in this direction, and following it let me drop a lot of interior-mutability wrappers I had previously needed at runtime.

Distinguish different kinds of output:
Some values are fixed once the type is created; others change over time. The former can stay as plain owned types, while the latter are better expressed as shared types. I also try to avoid handing out mutable references. When mutation is required, specific methods should own that responsibility.

Insight:
A surprising amount of this is already enforced by the Rust type system. The rules can feel strict, but treating the compiler as a collaborator usually leads to cleaner design and less code.

Introduction to Experiment Indicators

Lori-Shu — Mon, 24 Aug 2026 15:43:57 +0000

Scientific experiments typically need clear indicators to measure and quantify performance. This is especially true in data-processing contexts, where several key metrics deserve close attention.
We can start with a few fundamentals familiar from high-school math: the average (mean), the mode, and the variance. The average corresponds to the "expectation" discussed in probability courses; it summarizes the overall property of a dataset in a single number. The mode is simply the value that appears most frequently. Variance indicates stability—if a dataset shows large variance, it is considered unstable.
Residual is another useful indicator. It measures the difference between data points that have a time-domain character. Residuals are particularly valuable in signal processing, where data are typically ordered by time. They are calculated by taking the difference between values at separate time points.
From residual we derive RSS (Residual Sum of Squares), also known as SSE (Sum of Squared Errors). RSS is obtained by squaring each residual and then summing the results. RMSE (Root Mean Squared Error) takes this a step further: it divides the RSS by the number of data points and then takes the square root. The result has the same magnitude as the original data and effectively represents the average residual. RMSE is especially powerful when the data contain both positive and negative values, because squaring prevents opposing residuals from canceling each other out.

The Trend of Modern Programming Languages

Lori-Shu — Sun, 23 Aug 2026 16:06:05 +0000

In 2026, programming languages—the core tools of software engineers—are undergoing a clear and accelerating shift: they are becoming more static.
Two major design paradigms have long shaped language design. On one side are the static-first languages such as C and Rust. These typically feature strong type systems and sophisticated, heavyweight compilers. On the other side are the dynamic-first languages such as Python and JavaScript. They traditionally rely on weaker type systems while leveraging powerful, professionally engineered runtimes.

Insight:The current trend is unmistakable: languages that once embraced dynamic features are steadily adopting more static characteristics. Many of them have borrowed ideas and mindsets from languages like Rust. Evidence shows that this shift delivers tangible benefits—faster startup times, reduced runtime memory usage, and greater code determinism.
Recognizing this evolution helps us better understand the interplay between static and dynamic elements in our own software. The practical recommendation is straightforward: prefer static approaches whenever possible, and only fall back to dynamic solutions when something is genuinely difficult to make static.