u/lonter100

▲ 5 r/BareMetalDev+1 crossposts

I built a real-time 3D LEGO Raymarcher in the terminal (~70 FPS, zero Python/C). Then I squeezed the entire project down to just 11 KB.

Hey everyone!

I’ve been experimenting with low-level software rendering inside standard Linux terminals. I wanted to see how fast I could march 3D Signed Distance Fields (SDF) and render dynamic, illuminated 3D geometry without using any heavy frameworks, Python wrappers, or C/C++ source files in the project.

The engine renders an animated 3D LEGO® Minifigure (walking animation, waving arm, facial details, space emblem) and a Space Rover on a studded baseplate at 160x48 resolution @ ~70 FPS with 24-bit ANSI TrueColor, PBR clearcoat gloss, soft shadows, ambient occlusion, and interactive WSAD camera flight.

After getting it running smoothly, I decided to see how far I could push the footprint optimization without losing a single frame or feature.

📏 File Footprint Breakdown (200 KB →→ 11 KB Total)

Here is how the project breaks down before and after stripping/compression:

textSOURCE CODE (DSL):
  • scene_lego.hray        : 2.4 KB  -->  0.9 KB (Minified DSL scene description)
  • hray_compiler.hydra    : 2.7 KB  -->  1.1 KB (VLIW-8 Hardware Microcode)
  • hray_compiler.hmat3d   : 2.8 KB  -->  1.0 KB (3D Spatial Matrix Definitions)
  --------------------------------------------------------------------------
  Total Source Code Size   : 9.2 KB  -->  ~3.0 KB (Full 3D Scene + Microcode)
COMPILED NATIVE BINARY:
  • Raw Executable Binary  : 27 KB   --> 14 KB (Stripped debug symbols)
  • UPX Compressed Binary  : 14 KB   --> ~7 KB (Self-extracting ELF executable)
COMPLETE REPOSITORY FOOTPRINT:
  • Initial workspace size : ~200 KB (including benchmark builds)
  • Minified total size    : ~11 KB  (Over 94% total footprint reduction!)

🛠️ Key Technical Highlights:

  1. Custom Vector Language (DSL): Everything is defined in .hray (geometry/materials), .hydra (instruction stream), and .hmat3d (spatial transformations).
  2. SIMD Alignment: Ray packets execute in 8-lane AVX2/FMA3 SIMD vector passes directly on CPU registers.
  3. Artifact-Free Precision: Fixed surface penetration gradient collapse (black spots) by enforcing 1.0x conservative stepping precision and camera-vector fallback normals.
  4. Zero Overhead: Launches instantly from terminal via a 1.5 KB shell script.

The entire project — source code, microcode, shaders, materials, and executable binary — fits into ~11 KB, which could easily fit on a vintage 5.25" floppy disk with 99% of space to spare.

Happy to answer any questions about the SDF mathematics, SIMD vector alignment, or terminal framebuffer commit optimizations!

Subreddits & Tags

#programming #graphicssoftware #gamedev #CommandLine #linux #LowLevel #SIMD #AVX2 #Raymarching #Lego

u/lonter100 — 8 days ago
▲ 7 r/BareMetalDev+1 crossposts

Reducing 250k file traversal & content search from 410 ms to 180 ms in C on a 15W dual-core Broadwell CPU (SYS_getdents64 + AVX2)

How do you reduce recursive directory traversal and file content search across 250,000 files from 410 ms down to 180 ms on a 15W mobile Intel Core i5 processor?

While optimizing high-density filesystem search workflows (Directory Traversal + Content Search), I benchmarked standard POSIX pipelines and modern SIMD CLI utilities against native C engines built directly on low-level Linux primitives:

• hfind – A directory traversal engine built directly on the Linux SYS_getdents64 system call, featuring a page-aligned 32 KB kernel buffer and lock-free parallel recursion using OpenMP tasking.

• hgrep – A memory-mapped scanning engine leveraging 256-bit AVX2 SIMD vectorization, zero-copy mmap (MADV_SEQUENTIAL | MADV_HUGEPAGE), and 4-way unrolled vector loops.

• hsearch – An integrated pipeline combining VFS node filtering and SIMD content scanning in a single pass.

(See benchmark screenshot attached)

🔍 Key Architectural Factors Behind the Speedup:

• Bypassing POSIX libc Allocation Overhead:

Standard opendir() and readdir() abstractions allocate heap memory structures per directory stream. Issuing raw syscall(SYS_getdents64, ...) fetches raw directory record streams directly into L1/L2 cache buffers, eliminating allocator overhead across deeply nested folder hierarchies.

• Vectorized Non-Matching Block Elimination (_mm256_cmpeq_epi8):

Rather than scanning byte-by-byte, 256-bit AVX2 registers process 32 bytes per clock cycle. Bitwise masking evaluates and discards 128-byte chunks of non-matching data in a single operation, bypassing scalar branch loops entirely.

• L1/L2 Cache Locality & Hardware Prefetching:

On power-constrained hardware (Intel Broadwell 15W TDP), memory bus latency is the main bottleneck. Coupling hardware prefetch hints (_MM_HINT_T0) with MADV_WILLNEED page advice keeps the memory bus saturated at maximum bandwidth.

⚙️ Engineering Takeaway:

When handling high-density I/O operations over hundreds of thousands of small objects, bypassing standard runtime abstractions in favor of direct kernel system calls and vector primitives yields a >2x execution speedup on existing hardware without hardware upgrades.

What has been your experience bypassing standard C runtime abstractions for direct kernel system calls in performance-critical paths?

#Linux #SystemProgramming #C #Performance #AVX2 #Optimization #OperatingSystems #Developers

u/lonter100 — 9 days ago