<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mlp on Jasper</title><link>https://jasper-aa64.github.io/tags/mlp/</link><description>Recent content in Mlp on Jasper</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://jasper-aa64.github.io/tags/mlp/index.xml" rel="self" type="application/rss+xml"/><item><title>Low-Latency Trading — A Cache Case Study: Repricing 64 Options per Tick</title><link>https://jasper-aa64.github.io/posts/low-latency-cache-case-study/</link><pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/low-latency-cache-case-study/</guid><description>One tick touches 140 cache lines, and most of the time goes into waiting for them. None of the four steps changes the computation; they change when data arrives, where it lands and who holds it: put the misses in flight together, ask for the next batch early, hand back lines that are dead after one read, read one line less across the handoff, and leave the lines the other core will read in L3.</description></item><item><title>Low-Latency Trading — Memory Latency and Bandwidth</title><link>https://jasper-aa64.github.io/posts/low-latency-memory-latency-bandwidth/</link><pubDate>Fri, 09 Oct 2026 00:00:00 +0000</pubDate><guid>https://jasper-aa64.github.io/posts/low-latency-memory-latency-bandwidth/</guid><description>One memory access takes about 100 ns and brings back 64 B. One at a time, that&amp;rsquo;s 0.64 GB/s, yet one core reading sequentially gets 15–60 GB/s. The missing factor is the number of requests in flight. Whether the next load&amp;rsquo;s address has to wait for this load decides whether your code is latency-bound or bandwidth-bound.</description></item></channel></rss>