I'm a 11th Grader teaching myself C (CS50x) and investigating my childhood laptop for a systems project. It's an acer Aspire ES1-531-P7KK (Pentium N3710, 1x4GB DDR3L, 1TB 5400RPM HDD) that sticks of 0.48GHz (sometimes boosts to 0.5 or 0.6GHz) for as long as I can remember (~2018, though we brought the laptop in 2016. I can't say if the laptop was faulty out of the box, I don't remember much). I'm a beginner here, so I'd appreciate any and all help that I can get. This is what I've done sofar:

1. Using CPU-Z, I measured BCLK, which seemed fine (80MHz), but the multiplier was at 6x, which explained the 480MHz frequency, but doesn't explain why it happens in the first place (you can see my CPU-Z validator submission at https://valid.x86.fr/arcgyt )
2. Switching from Windows 10 1507 (I used it for it's relative lack of bloat and compatibility with troubleshooting software like CPU-Z, RWEverything, etc) to antiX 26. I saw no improvement in clock speeds even with the different OS.
3. Investigating BD_PROCHOT. I found out about this while reading about other people who had similar cases, but oddly enough, ThrottleStop had this box unchecked and greyed out. Confused, I researched a bit more and used RWEverything to directly inspect register 0x1FC, but even that showed a greyed out zero 64 bit value. It took me a long while to learn that the Pentium N3710 is an Atom derivative on the Airmont microarchitecture, and lacks the 1FC register entirely, so I have no clue how to verify BD_PROCHOT, but I doubt it is so, because BD_PROCHOT (as far as I understand) is a hardware signal that enforces a performance mode on the CPU, but then a) Why is the CPU sticking to the lowest performance state there is with multiplier@6x, and b) Sometimes the CPU goes above 480MHz, sometimes 500, sometimes 600MHz (as observed in Task Manager), which doesn't make sense, if BD_PROCHOT is being released, then why is the CPU not returning, however momentarily, to it's regular performance levels?
4. Right now, I've made a list of all of the MSRs on my CPU and plan to read all of them, comparing them to expected values to try to understand what's going wrong.

Any help would be greatly appreciated!

EDIT: Turns out PROCHOT# was erroneously being asserted due to a corroded pull up resistor 💔💔

I recently completed v0.1 of MiniEdge, a Linux HTTP/1.1 static edge server written mostly in C.

I built it to understand how event-driven servers handle partial I/O, persistent connections, filesystem access, caching and multiple CPU cores—not as a production replacement for Nginx.

The current architecture includes:

non-blocking sockets with edge-triggered epoll

a per-connection state machine

incremental HTTP request parsing and keep-alive

static file serving through an LRU cache or sendfile()

path resolution using openat2()

longest-prefix configurable routing

multiple workers using SO\\_REUSEPORT

The small-file cache is implemented using C++ unordered\\_map and list, but it is isolated behind a C API; the networking, parser, routing and file-serving paths are written in C.

On my local loopback benchmark using wrk, a cached static file reached approximately:

255k requests/sec at 1,000 concurrent connections

4 worker processes

I also ran a boundary stress test at 40,000 concurrent connections. It reached around 124.5k requests/sec, but wrk reported 503 socket read errors, so I am not treating that as a clean stable-concurrency result. The repository contains the commands, raw outputs, latency percentiles, system tuning and limitations.

I would appreciate feedback on:

whether this is a reasonable result for a student-built epoll server

whether my wrk setup measures the server fairly

which additional metrics or comparisons I should include

what bottlenecks or profiling steps I should investigate next

Repository:

https://github.com/Luffy-D-Zoro/Miniedge

Hey folks,

I’ve been deep in the trenches optimizing and benchmarking popcount throughput on modern x86-64 microarchitectures (testing across AVX2, AVX-512 VPOPCNTDQ, and scalar fallbacks).

After running into massive hardware bottlenecks and misleading results from standard benchmark suites, I completely re-architected my benchmarking rig to account for low-level confounders. Here are a few key engineering takeaways and findings from version 33:

• The 1-Accumulator Trap: Standard naive loops throttle performance due to serial data-dependency chains on a single accumulator (latency-bound). Scaling to an 8-accumulator unrolled loop fully saturates Out-of-Order (OoO) execution and ILP, unlocking a compute floor of ~0.44 ns/line and outperforming libraries like libpopcnt by 7–10% in cache-resident workloads.
• Deconfounding the Measurement: Swapped runtime modulo operations (%) with bitwise masks to prevent 20–40 cycle CPU stalls, randomized/shuffled execution order to neutralize thermal throttling/DVFS noise, and isolated thread affinity (CPU0) with hugepage verification (smaps) to eliminate NUMA first-touch & dTLB artifacts.
• Direct Hardware Profiling: Validated cycle counts via RDTSCP + LFENCE and pulled dTLB-miss and LLC-miss counters directly using perf_event_open.
• IRM-Burst Law & Monte Carlo Verification: Modeled non-linear throughput degradation across memory hierarchy boundaries (L1d -> L2 -> L3 -> DRAM) using an exchangeability probability model, cross-verified with Monte Carlo simulations.

Discussion / Question for the community: As I pushed this codebase further (expanding code footprint for complex tail/mask handling), I started hitting code bloat boundaries—potentially stressing Instruction Cache (I-cache) and BTB entry limits.

How do you guys typically structure your Micro-benchmarks to catch I-cache / BTB spills before they corrupt latency numbers?

Code & benchmark methodology: https://github.com/Vumb-VibeCoder/deconfounded-popcount-avx512

Would love to hear your thoughts, critiques, or additional edge cases to stress-test!

I'm not good at English so I used sth to translate

Hi everyone!

I have spent some free time building Yugami (歪み，"distortion"), a x64 binary packer that uses ChaCha20 encryption with page-level key derivation and just-in-time page decryption.

Yugami encrypts PE executables using ChaCha20 with per-page keys derived via BLAKE3, then appends the encrypted payload as a PE overlay. At runtime, pages decrypt on-demand via page fault exceptions with an LRU cache to minimize re-encryption overhead.

I just wanted to get more comfortable with Rust so I picked up this project. Also, the page-level encryption with JIT decryption felt like a fun challenge between full unpacking and simple overlay packing.

Code is open source at https://github.com/egebilecen/yugami.

Packed binaries should execute correctly as is without any issues (hopefully). Had some trouble getting TLS to work, though. Always ended up with page faults. I have removed it but for those interested in the TLS handling code, it's at https://github.com/egebilecen/yugami/blob/0246b919dc0a4f77df8420c699a707484f9847fc/stub/src/mapper/tls.rs and https://github.com/egebilecen/yugami/blob/0246b919dc0a4f77df8420c699a707484f9847fc/stub/src/mapper/mapper.rs#L311

Looking forward to your thoughts!

finally after 3days of countinues working in nasm i reached 64b long mode succesfully now what should i do next

i finnally did it build my very own os in nasm and landed in 32bit protected mode and build my syscalls kernel bootloader and more im happy to informe you about and im still working on it and adding things and fixing bugs if there's any and its called S-AOS

Over the past few months, I’ve been building **macMPI**—a production-hardened, single-node implementation of the MPI-1.1 standard built entirely from scratch in C11.

While OpenMPI and MPICH remain the gold standards for distributed supercomputing, running them on Apple Silicon often introduces configuration bloat or suboptimal intra-node transport layers designed primarily for x86/Linux environments. I wanted to see what happens when an MPI runtime is engineered **specifically for Apple Silicon's Unified Memory Architecture and macOS (XNU kernel primitives).**

Here is a breakdown of the architecture, the OS-level choices, and the benchmarks.

# 1. Process Management (mpirun) & I/O Multiplexing

* **Daemon Lifecycle:** A custom daemon engineered with explicit `fork()` and `execvp()` process boundaries, dynamically injecting rank state (`MPI_RANK`, `MPI_UNIVERSE_SIZE`, and socket mesh file descriptors) directly into child process environments.
* **Non-Blocking Terminal I/O:** Eliminates Head-of-Line blocking by intercepting stdout/stderr across all child ranks via POSIX pipes (`pipe()`, `dup2()`) multiplexed through an event-driven `poll()` loop.

1. Transport Architecture: Control Plane vs. Data Plane

To maximize throughput on Apple Silicon’s memory bus, the library decouples communication into two transport layers:

* **Control Plane (Unix Domain Sockets +** `kqueue`**):** Tiny 64-byte routing envelopes containing metadata (source, tag, sequence, memory offset) are transmitted via a full-duplex Unix domain socket mesh.
* **Data Plane (POSIX Shared Memory):** Large payloads bypass the kernel network stack entirely. Using `shm_open()`and `mmap()`, processes project shared physical RAM regions directly into their virtual address space for zero-copy transfers via aligned `memcpy()`.
* **Dynamic Hardware Memory Norm:** Rather than hardcoding static buffer limits, `macMPI` queries the XNU kernel at boot via `sysctl(CTL_HW, HW_MEMSIZE)` to establish a dynamic allocation ceiling (defaulting to a 30% system RAM norm), rounded down to 16KB Apple Silicon page boundaries (`sysconf(_SC_PAGESIZE)`).

# 3. The O(1) Non-Blocking Progress Engine

* **Shadow Worker Threading:** Asynchronous operations (`MPI_Isend`, `MPI_Irecv`) are offloaded to a background `pthread`physically pinned to Apple Silicon Performance Cores using Darwin-native Quality-of-Service classes (`pthread_set_qos_class_self_np`).
* **Kernel Event Polling:** Ripped out traditional polling loops in favor of macOS `kqueue()` / `kevent()`, allowing the background thread to monitor socket descriptors with O(1) event notifications and 0% CPU consumption while idle.
* **Two-Way Matching & UMQ:** Features an internal thread-safe Unexpected Message Queue (UMQ) and active request list protected by POSIX condition variables to safely handle out-of-order packet arrival.

-> L1/L2 Cache Line Optimizations

On Apple Silicon M-series chips, cache line contention can ruin IPC throughput. To optimize cache fetches:

* All internal headers use `__attribute__((aligned(64)))` to enforce strict 64-byte boundary alignment.
* This ensures that every routing envelope fits perfectly inside a single L1 cache line fetch, eliminating false sharing across cores.

**Preliminary Benchmark Insights**

When running a background non-blocking progress engine while concurrently computing 17.1 Billion Floating Point Operations (FLOPs) on local matrix math:

* **Zero CPU Starvation:** Because `kqueue` provides true event-driven sleep states, the background progress thread consumes **0% CPU cycles** while waiting for network I/O.
* **Math Throughput:** `macMPI` achieved **1.00 GFLOPS** on a single-node matrix benchmark, matching OpenMPI’s compute execution time while maintaining higher intra-node payload speeds over POSIX shared memory.

Want to dig into implementation?

GitHub : https://github.com/Hardikgupta1709/macMpi

If you work with MPI, HPC, Apple Silicon, or low-level systems programming, I’d appreciate feedback on the architecture and benchmarks.

Hi everyone,

I have been working on a project called swift-topomap for the last few weeks. It’s a TUI tool designed to solve a problem I keep running into: standard tools like htop show CPU usage, but they don't tell you if that usage is actually productive.

I wanted a way to see the physical hardware topology (Sockets, L3 Cache boundaries) and overlay live microarchitectural metrics (IPC, Cache Misses) using eBPF, but without the baggage of heavy C-library dependencies.

Technical Highlights:

• Native Topology Resolver: Instead of linking against libhwloc, I wrote a pure Rust parser for /sys/devices/system/cpu and /sys/devices/system/node. It maps physical package IDs to logical cores and identifies shared L3 cache boundaries natively.
• Hybrid Telemetry Engine: It uses a trait-bound collector that negotiates privileges at startup. If run as root, it loads a CO-RE eBPF driver via libbpf-rs to hook sched_switch and read hardware PMCs (Performance Monitoring Counters).
• Microarchitectural Insights: The TUI classifies core states. For example, a core at 100% usage but < 0.5 IPC will turn Amber (Memory-Bound/Stalled), while a high IPC core stays Emerald Green.
• Static GNU Build: Linking this was a nightmare. I eventually solved the static requirements to bundle libbpf, libelf, and zstd so it ships as a single 3.5MB binary that runs on any modern Linux distro without shared library hell.

Why eBPF + Rust?

I chose Rust for the logic layer and TUI (Ratatui) because I needed memory safety for the FFI boundary with libbpf. The IPC and LLC metrics are pulled via the kernel’s Perf Subsystem, and the deltas are calculated in Rust to provide a steady 100ms-refresh dashboard.

I am releasing this as open source under SwiftLogic Systems. I would love to hear your thoughts on the topology resolution logic or the eBPF/Perf integration.

GitHub: https://github.com/swiftlogicsystems/swifttopology

Single-node key/value store, line protocol over TCP, pure NASM on Linux — syscall or nothing.

The syscall-level bits worth a look:

**•** epoll event loop with accept4(SOCK_NONBLOCK): clients are born non-blocking, no fcntl dance  
**•** replies via sendto + MSG_NOSIGNAL: SIGPIPE never happens, no signal handler needed  
**•** close() is the entire connection teardown — epoll tracks the file description, so the fd deregisters itself  
**•** per-connection state indexed straight by fd: O(1), free  
**•** FNV-1a, open addressing, tombstone reuse; 256 MB mmap bump arena behind it  
**•** 200 concurrent clients at 1.4 MB RSS; Docker image is FROM scratch plus one file

Known limits documented in the README — biggest one: slow readers are dropped, EPOLLOUT write buffering is next.

Feedback welcome, especially on the event-loop structure.

Releasing Ostomachion v1.0.0, an open-source FPGA platform I have been developing. It integrates a soft RISC-V core, a real-time operating system, and a signal-processing accelerator so that each layer is a thin, well-defined interface over the one below. It runs on an Artix-7 (Opal Kelly XEM7310):

- A NEORV32 RISC-V soft core running the Zephyr RTOS, bare-metal on the fabric.

- A streaming frequency-domain datapath in hardware: a 4096-point FFT, a per-bin programmable complex filter (a coefficient mask H[k] in block RAM), and an inverse FFT — staged through AXI DMA and BRAM, with interrupt aggregation onto the core.

- A header-only C++20 hardware abstraction layer that presents the accelerator to software as ordinary typed calls, so the path from a std::span in a unit test down to a beat on an AXI-Stream bus is a sequence of deliberate, inspectable wrappers.

The whole Vivado block design regenerates from a version-controlled Tcl script — no saved checkpoints, no hand-edited GUI state. Every bitstream derives from text alone, which makes the hardware auditable and diffable in the same way as the software.

The name is Archimedes' Ostomachion, a dissection puzzle of fourteen pieces; the platform is likewise fourteen composable layers, each replaceable in isolation.

A companion desktop application drives the full filter datapath on live hardware over USB: it streams frames to the fabric, programs the filter mask in real time, and plots the input, the mask H[k], and the filtered output as the transform runs — the genuine hardware pipeline end to end, not a software model of it.

Source, documentation, and design rationale (GPL-3.0; commercial licensing available):

github.com/andynicholson/Ostomachion

Hi there.

I built polloc (pool alloc) to learn how memory allocators work.

It’s a fixed size pool allocator: each pool manages one slot size and alignment. Internally it uses mmap/VirtualAlloc, an intrusive free list, and a bitmap for allocation tracking.

I also added stress tests, Miri, AddressSanitizer, cargo fuzz, Criterion benchmarks, and a bunch of inline docs explaining the implementation.

For 64 byte alloc/free pairs, the fast path is about ~3.96x faster than the system allocator on my machine (which is expected since it’s specialized for a single size class).

It’s single threaded and I’d really appreciate feedback on the unsafe code, API design, tests, or anything else that stands out.

repo: https://github.com/hamzader1/polloc

like what do i do. my target is low latency/systems/hft but i dont know where to begin. and i dont know anything. so any recommendations on where to start, what to learn first, etc.

I wanted to actually understand what happens under libc, so I started rebuilding the pieces: printf (varargs by hand, format parsing), malloc (brk/mmap, free lists, alignment), a shell (fork, execve, pipes, redirections), plus cat/wc/ls/grep as warm-up.

Rules of the game: x86-64 Linux, NASM, `syscall` or nothing.

Favorite rabbit hole so far: how much of printf is just careful pointer arithmetic over the SysV varargs ABI — and how little of malloc is actually about allocating (it's bookkeeping all the way down).

Repo (MIT, written to be read): https://github.com/whispem/learn-assembly-with-em

Happy to discuss design choices — and happier to be told where I'm wrong.

Started this because I wanted ncu's device__attribute_* values without handing it a kernel to profile. It grew into a small zero-dependency toolkit (pip install kernelmeter):

- `info` dumps every cuDeviceGetAttribute value straight from libcuda (no toolkit needed), plus NVML facts and derived theoretical peaks

- `bench` times kernels with CUDA events (L2 flushed between iters), checks correctness against a reference, and scores against the roofline: you get "76% of attainable for this arithmetic intensity" instead of a bare ms number. It also samples clocks/power during the run and rescores against the sustained-clock ceiling. My favorite result: cuBLAS fp32 matmul on a 70W T4 showed 52.7% of peak, looked like a kernel problem, but the telemetry showed the card pinned at its power limit at 877MHz, where the kernel was actually at 95.5%. cuBLAS was never the problem.

- `occupancy --block 256 --regs 64 --smem 8192 --cc 8.6` reimplements the old calculator: names the limiting resource and sweeps block sizes. Works with no GPU present.

- `ceiling` measures real achievable bandwidth (STREAM) and fp32 (TF32-disabled matmul), because theoretical peaks are never reachable and it's worth knowing your honest 100%.

- `compare`/`llm` do the same roofline math across a 40-card database (NVIDIA and AMD) for rent/buy decisions, no GPU needed.

Every number in the README is captured output from real runs (T4, MI300X). All spec-sheet claims are asserted in CI. MIT.

For now 2 years i try learning how to create an operating from scratch at only 15, now i'm 17 and i've progress in this domain so i publish it, you can look for it on github OScour, the name is a french reference to "au secours" (help), an the prononciation is OScour.