<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Bit-Packing on cdelmonte.dev</title>
    <link>https://cdelmonte.dev/tags/bit-packing/</link>
    <description>Recent content in Bit-Packing on cdelmonte.dev</description>
    <generator>Hugo -- 0.147.7</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 09 Jun 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://cdelmonte.dev/tags/bit-packing/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Unpacking Parquet: Where Explicit SIMD Actually Matters</title>
      <link>https://cdelmonte.dev/deep-dives/unpacking-parquet-where-explicit-simd-matters/</link>
      <pubDate>Tue, 09 Jun 2026 00:00:00 +0000</pubDate>
      <guid>https://cdelmonte.dev/deep-dives/unpacking-parquet-where-explicit-simd-matters/</guid>
      <description>On the JVM, optimizing a hot kernel is not only about writing faster code: it is about controlling how much the result depends on the compiler recognizing the code&amp;rsquo;s shape. Using Parquet bit-unpacking as a concrete case, our experiment shows that a SIMD speedup depends on which scalar baseline C2 is handed, when explicit vectorization is actually justified, and why a more specialized scalar routine is not necessarily faster.</description>
    </item>
  </channel>
</rss>
