<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Wrapup on ./Code</title><link>https://blog.ouankou.com/tags/wrapup/</link><description>Recent content in Wrapup on ./Code</description><generator>Hugo</generator><language>en-US</language><copyright>© Anjia Wang</copyright><lastBuildDate>Mon, 04 May 2026 18:57:48 -0700</lastBuildDate><atom:link href="https://blog.ouankou.com/tags/wrapup/index.xml" rel="self" type="application/rss+xml"/><item><title>How REX Finished The LLVM 21 GPU Benchmark Suite</title><link>https://blog.ouankou.com/2026/04/30/how-rex-finished-the-llvm-21-gpu-benchmark-suite/</link><pubDate>Thu, 30 Apr 2026 00:00:00 +0000</pubDate><guid>https://blog.ouankou.com/2026/04/30/how-rex-finished-the-llvm-21-gpu-benchmark-suite/</guid><description>&lt;p&gt;The previous post removed the last confusing process-lifetime tax from the LLVM 21 comparison. GPU-total profiling had already shown that the suspicious &lt;code&gt;pathfinder&lt;/code&gt; and &lt;code&gt;srad&lt;/code&gt; rows were not device-side native LLVM wins. The process-exit teardown investigation then explained why some short wall-clock runs still looked worse for REX even when kernel and transfer totals were clean.&lt;/p&gt;
&lt;p&gt;At that point, the LLVM 21 performance work finally had a coherent scoreboard.&lt;/p&gt;
&lt;p&gt;This post is the wrap-up for that state. It is not another chronological debugging log. The chronological work is covered by the previous posts. This one answers a different question:&lt;/p&gt;</description></item></channel></rss>