--- title: Pikuma: SIMD in the 90s: Programming Intel's Pentium MMX description: A retrospective deep-dive into Intel's Pentium MMX, the 1997 SIMD extension that brought parallel integer processing to mainstream x86 PCs. Covers what MMX... canonical: https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Pikuma: SIMD in the 90s: Programming Intel's Pentium MMX | daily.dev og:description: A retrospective deep-dive into Intel's Pentium MMX, the 1997 SIMD extension that brought parallel integer processing to mainstream x86 PCs. Covers what MMX... og:url: https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq og:image: https://api.daily.dev/og/posts/uqI9hCgvq.png og:image:alt: Pikuma: SIMD in the 90s: Programming Intel's Pentium MMX og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Pikuma: SIMD in the 90s: Programming Intel's Pentium MMX **[Two Stop Bits](https://daily.dev/sources/twostopbits)** · [@gpezzi](https://daily.dev/gpezzi) · 16 min read · 1 upvotes · 1 comments ## Summary A retrospective deep-dive into Intel's Pentium MMX, the 1997 SIMD extension that brought parallel integer processing to mainstream x86 PCs. Covers what MMX was, how it reused x87 floating-point registers, packed integer arithmetic, saturating operations, the EMMS instruction, and CPUID detection. Explores whether MMX predates SIMD (it doesn't - ILLIAC IV and Cray-1 came decades earlier), discusses which games actually used MMX (fewer than expected, since Quake predates it and 3D accelerators were emerging), covers AMD's competing 3DNow! extension, and explains how SSE and SSE2 eventually made MMX obsolete by adding floating-point SIMD and wider 128-bit registers. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What was the MMX instruction set and how did it work on the Pentium MMX processor? MMX was a set of 57 additional instructions introduced with Intel's Pentium MMX processor in 1997 that let a CPU process multiple integers packed into a single 64-bit register simultaneously, instead of one at a time. It reused the x87 floating-point registers as eight 64-bit MMX registers (MM0-MM7), which meant MMX and floating-point operations could not run at the same time, requiring an EMMS instruction to clear MMX state afterward. _Track how classic architecture decisions like MMX still shape today's SIMD extensions using daily.dev._ ### Why didn't AMD's 3DNow! become as popular as Intel's MMX? 3DNow!, introduced with the AMD K6-2 in 1998, added floating-point SIMD instructions similar to MMX but never matched MMX's popularity because Intel had a huge head start (MMX shipped in January 1997) and a dominant x86 market share, so developers optimizing for 3DNow! only benefited AMD chips. Intel's 1999 introduction of SSE with the Pentium III delivered the final blow to 3DNow!'s adoption. _Compare rival CPU extensions like 3DNow! and MMX to understand tradeoffs when picking optimization targets, via daily.dev._ ### Why did MMX eventually become obsolete after SSE2 was introduced? SSE2, released by Intel in 2000, brought the integer SIMD operations MMX was known for into the newer 128-bit XMM register architecture, letting programmers process 16 pixels at once instead of MMX's 8 pixels per 64-bit register. Because SSE2 offered wider registers and covered MMX's integer strengths while also supporting floating-point SIMD, it made the older MMX registers largely unnecessary. _Follow how SIMD register widths evolved from MMX to SSE2 and beyond for performance-critical code on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 4 discussions and 106 comments across lobsters, hackernews (as of 2026-09-14). **TL;DR:** The deep technical thread mostly trades detailed personal history and corrections about MMX/SSE-era x86 internals, with one detailed rebuttal arguing the post overstates MMX's real-world impact and understates that most 'MMX support' was Intel marketing/bribery rather than genuine performance gains. **Sentiment:** 25% positive · 55% mixed · 20% skeptical **The case for** - Several developers confirm MMX genuinely helped in specific domains like image/video codecs, IDCT, motion compensation, and software 3D rasterization. - People enjoyed the nostalgic deep-dive and retro code-font presentation. **The pushback** - One detailed comment argues most 'MMX-optimized' games only got the label due to Intel paying developers, not real technical benefit. - Multiple commenters dispute or refine technical claims in the article, e.g. about x87/MMX/SSE register aliasing, whether MMX or cache size explained Quake's speed, and whether Quake used fixed-point math. - MMX is characterized as having been largely irrelevant or even actively harmful to 3D performance compared to 3DNow! and later SSE. - One person notes the page requires excessive JavaScript to render despite being mostly static text. **By community** - lobsters (mixed): No substantive discussion was present, so sentiment can't be meaningfully assessed. - hackernews (mixed): A large, technically rich thread mixes nostalgic reminiscence and appreciation with pointed corrections and a strong rebuttal claiming the article overstates MMX's real-world game impact. **Hottest debate:** Whether MMX actually delivered meaningful real-world performance benefits in games, or whether most 'MMX support' claims were just Intel marketing/payola rather than genuine technical gains. **Open questions** - Was Quake's speed really due to MMX/cache size rather than fixed-point arithmetic as the article suggests? - Did Coppermine-era P3 chips ever unify x87/MMX and XMM registers, or were they always separate? - Was Intel's SSE meaningfully faster in real shipped games compared to x87, given how hard it seems to find clear benchmarks showing this? **Highlights** > >Examples of games that either required or benefited from MMX enhancements in their software renderer were Eraser Turnabout, POD, and Extreme Assault POD "Designed for Intel MMX" meant _one_ optional audio filter effect. It was added in order for Ubisoft to cash out $1 Million bribe Intel was handling out while running new Pentium Inside campaign. Intel later tried repeating same stunt with SSE while promoting new Pentium 3, but failed to bag any serious takers other than Rage Software. Rage made a fake game demo (Dispatched) for Intel 1999 Comdex Fall booth which Intel used to manipulate benchmarks for a couple years by lying to Anandtech claiming its a real game :| https://web.archive.org/web/20210807020603/https://www.anand... https://www.hardware.fr/articles/95-5/jeux-optimises.html Two other examples from that link are SSE "optimized" Rage Software Expendables running slower than original, and "Pentium III optimized" PowerSlide by GT Interactive with zero fps difference. Neither ever released outside of Intels Comdex booth and marketing materials. >Even though Quake and Quake II are often used as examples of games that benefited from MMX technology, it's important to point out that Quake's famous software renderer predates MMX. Quake benefitted from MMX processors because those models had doubled L1 cache size :) No one cared about MMX, but jump from 16 KB to 32 KB meant visible fps bump in all games. > So, Quake's fast performance was achieved primarily through techniques like fixed-point arithmetic Quake didnt use fixed point math, whole magic of Quake relied on taking full advantage of pipelined FPU. Quake was never optimized for data locality tho and loved cache, the more the better. It scales linearly all the way to 2MB of L2 https://dependency-injection.com/2mb-cache-benchmarks/ and probably would higher if we had platforms supporting more to run tests. >Many games and other multimedia applications shipped with optional MMX code paths No, exact opposite. Barely any games, pretty much only the ones where Intel paid that $1m bribe, shipped with any MMX support directly because it was Integer only DSP like accelerator good for Audio/Video but useless for 3D. >Real floating-point SIMD for x86 didn't arrive until SSE (Streaming SIMD Extensions) several years later with the Pentium III series. but >The first processor to ship with 3DNow! technology was the AMD K6-2 from 1998. So which is it? :) >3DNow! was never more popular than MMX. It was much more popular where it counted considering game developers implemented it without bribes and it actually made games run faster. 3DNow's biggest problem was being introduced in bargain bin low end K6-2 CPUs. >Developers faced the choice of supporting either Intel CPUs or AMD CPUs True dichotomy. There is no choice because both technologies provide distinct non overlapping and non interchangeable features. Its like saying "Developers faced the choice of supporting audio filters or faster 3D" >choosing MMX meant potentially supporting a larger fraction of PC gamers MMX was _useless_ for early 3D accelerated gaming with CPU still having to perform FPU heavy T&L. Adding any MMX code meant lowering FPU performance of the renderer. >If you wrote a 3DNow!-optimized renderer, it would only benefit AMD chips that supported it. The difference being 3DNow!, unlike MMX, actually did benefit AMD owners FPS numbers. NovaLogic software based Voxel renderer is the sole exception, NovaLogic might be the only company consciously using MMX in a game without a bribe :o >Finally, the ultimate blow to AMD's 3DNow! was Intel's introduction of SSE (Streaming SIMD Extensions) with the Pentium III in 1999. Look at start of my comment :) Its super hard to find a game benchmark that visibly showed SSE having a positive effect. Partly because first SSE implementations werent that great, partly because developers were still learning SIMD programming. >what ultimately made the old MMX registers unnecessary? If y > — [rasz on hackernews](https://news.ycombinator.com/item?id=49296576) > I did extensive MMX and SSE2 optimization of audio and video codecs in the 2000s. MMX made a large difference, but it was a pain. MMX optimization practically required assembly language. The Pentium MMX was an in-order dual pipe CPU, and while compilers supported MMX intrinsics, their code generation for it was abysmal. Visual C++ 6, for instance, would emit code that was 2/3rds register-to-register moves, with values being unnecessarily moved between two registers between each ALU op. This was also a problem with SSE/SSE2 intrinsics. The worst case I saw was the _mm_set_epi8() intrinsic, which was used to construct a 128-bit vector from 16 inputs. When used with all constants, it should have generated a single 128-bit constant load; instead, Visual Studio 2008 generated ~80 instructions to compute it from byte loads. Microsoft didn't fix it until VS2010. The latency of MMX instructions combined with the in-order dual pipe architecture also made asm loops messy. Simple ops were single-cycle, but multiplies had 3 cycle latency, stores required data an additional cycle in advance, and computed load/store addresses were also needed a cycle in advance. Simply running 2-4 iterations in parallel wasn't an option as there were only 8 vector registers and you'd still get bottlenecks on functional units. Getting peak performance thus often required interleaving loop iterations with special entry and exit code around the loop. The issue with EMMS is understated. When the CPU switched to MMX, it marked the entire x87 stack as full. If you forgot the EMMS instruction, it wasn't just some strange floating-point bugs that would happen -- the next few x87 floating point calculations could just outright produce NaNs due to FP stack overflow. Furthermore, as these NaNs propagated, the CPU required microcode assists to handle them. So, even if the program didn't crash, an entire calculation domain would get poisoned and slow down by ~20x. Ultimately, I don't think SSE2 was what killed MMX, but rather SSE, and specifically floating point. MMX not only didn't support floating point, but was also highly concentrated on 16-bit signed integers and secondarily 8-bit unsigned integers. Support for 32-bit integers was particularly lacking and pack/unpack conversions were a bottleneck. Trying to do 3D was cramped because doing so required fixed-point and MMX didn't have the same affordances as DSPs or NEON for rounding or implicit narrow/widen in operations, or even swizzles. SSE, on the other hand, was just straight floating point with standard automatic IEEE rounding and also had important added operations like swizzles and insert/extract. Thus, when 3D took off, SSE was far more useful than MMX. MMX, however, still remained useful for a while for image and signal processing. SSE2 being twice as wide didn't help algorithms that couldn't use the greater width, such as 8x8 block motion prediction. Additionally, some CPUs at the time only had a 64-bit data path and had to split SSE2 ops, but because of their 4-1-1 decode template, could only decode one such instruction per cycle. The result was that code using the MMX registers could still run noticeably faster than with the SSE registers. This caused some confusion with the 64-bit version of Windows since Microsoft tried to say that x87/MMX shouldn't be used in long mode, but after queries from video processing companies had to document that the x87/MMX registers were enabled and context switched for user mode code. > — [ack\_complete on hackernews · 2 comments](https://news.ycombinator.com/item?id=49323856) > When MMX first came out and there were games that supported it, many reviewers were convinced that it improved 3D performance. As far as I could tell, it wasn't really used for 3D and that the only enhancement was to the audio system. But the placebo effect of "If has MMX thus its better" did stick around for a long while. An aside, but when SSE came a long that was a real big leap in 3D performance, just as GPU's started to gain some independence. So in about 2010, I tried to fire up Turok 2 just to see how fast it would run on a then modern CPU/GPU setup. It couldn't crack 200fps, however games only a year or two later would fly way past that. Turok 2 came out just before SSE and thus basically ran in purely x86/x87 space, thus the performance gap. > — [ColdStream on hackernews · 1 comments](https://news.ycombinator.com/item?id=49325184) > John Carmack promised that Quake II will use MMX, but this wasn't done. That's why software rendering in Quake II is so boring, it doesn't even support colored lighting. In the other hand Unreal did use MMX, which allowed it to work in 32-bit color mode with colored lighting and a bunch of other effects. > — [Panzerschrek on hackernews · 2 comments](https://news.ycombinator.com/item?id=49326926) > >> I believe that only the first Pentium 3 core, Katmai, did this. > No, all Pentium 3s as well as the Pentium M. Pentium 4 notably didn't suffer from it, but it of course had many, many, MANY other performance issues. I had to google a bit to confirm this, and seems like I'm not the only one that understood it the way I did: https://www.vogons.org/viewtopic.php?p=1360606#p1360606 https://www.vogons.org/viewtopic.php?p=1360620#p1360620 Basically, the info I knew was that Katmai had 128 Bits SSE registers but processed it as 2x64 Bits. That info is well reference pretty much everywhere. What is NOT explicitly mentioned is whenever Coppermine/Tualatin maintained that arrangement or had 128 Bits compute units for SSE, so the wording always made Katmai to look like an exception, as if everything else was 128 Bits. > — [zir\_blazer on hackernews · 1 comments](https://news.ycombinator.com/item?id=49325544) **Source threads** - [lobsters](https://lobste.rs/s/sfuvd2/simd_90s_programming_intel_s_pentium_mmx) · 1 points · 0 comments - [hackernews](https://news.ycombinator.com/item?id=49304862) · 5 points · 2 comments - [hackernews](https://news.ycombinator.com/item?id=49285096) · 88 points · 100 comments - [hackernews](https://news.ycombinator.com/item?id=49280088) · 8 points · 4 comments ## Similar posts on daily.dev - [Why We Need SIMD \(The Real Reason\)](https://daily.dev/posts/why-we-need-simd-the-real-reason--sne5fy70g) · Hacker News · 4 upvotes · 0 comments - [A preview of the future Intel Architecture documentation](https://daily.dev/posts/a-preview-of-the-future-intel-architecture-documentation-qo0wpjuoj) · Lobsters · 0 upvotes · 0 comments - [Building a Quake PC: Benchmarking Quake](https://daily.dev/posts/building-a-quake-pc-benchmarking-quake-yztv1mdgi) · Fabien Sanglard · 0 upvotes · 0 comments --- Tags: [#performance](https://daily.dev/tags/performance), [#game-development](https://daily.dev/tags/game-development), [#architecture](https://daily.dev/tags/architecture), [#assembly](https://daily.dev/tags/assembly) [View this post on daily.dev](https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Pikuma: SIMD in the 90s: Programming Intel's Pentium MMX","url":"https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq"},"datePublished":"2026-08-15T09:20:36.436Z","dateModified":"2026-09-14T08:00:22.780Z","description":"A retrospective deep-dive into Intel's Pentium MMX, the 1997 SIMD extension that brought parallel integer processing to mainstream x86 PCs. Covers what MMX...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/7b81797f00687bb504eb08445a146135?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/7b81797f00687bb504eb08445a146135?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Two Stop Bits","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Person","name":"Gustavo Pezzi","url":"https://daily.dev/gpezzi","image":"https://lh3.googleusercontent.com/a/AEdFTp6jTc4OC1F1PtPiN8-1kImPopa9YI6fXOPXWfRUKg=s96-c","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":170}},"commentCount":1,"discussionUrl":"https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"performance,game-development,architecture,assembly","timeRequired":"PT16M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Two Stop Bits","item":"https://daily.dev/sources/twostopbits"},{"@type":"ListItem","position":3,"name":"Pikuma: SIMD in the 90s: Programming Intel's Pentium MMX"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/pikuma-simd-in-the-90s-programming-intel-s-pentium-mmx-uqi9hcgvq#faq","mainEntity":[{"@type":"Question","name":"What was the MMX instruction set and how did it work on the Pentium MMX processor?","acceptedAnswer":{"@type":"Answer","text":"MMX was a set of 57 additional instructions introduced with Intel's Pentium MMX processor in 1997 that let a CPU process multiple integers packed into a single 64-bit register simultaneously, instead of one at a time. It reused the x87 floating-point registers as eight 64-bit MMX registers (MM0-MM7), which meant MMX and floating-point operations could not run at the same time, requiring an EMMS instruction to clear MMX state afterward. Track how classic architecture decisions like MMX still shape today's SIMD extensions using daily.dev."}},{"@type":"Question","name":"Why didn't AMD's 3DNow! become as popular as Intel's MMX?","acceptedAnswer":{"@type":"Answer","text":"3DNow!, introduced with the AMD K6-2 in 1998, added floating-point SIMD instructions similar to MMX but never matched MMX's popularity because Intel had a huge head start (MMX shipped in January 1997) and a dominant x86 market share, so developers optimizing for 3DNow! only benefited AMD chips. Intel's 1999 introduction of SSE with the Pentium III delivered the final blow to 3DNow!'s adoption. Compare rival CPU extensions like 3DNow! and MMX to understand tradeoffs when picking optimization targets, via daily.dev."}},{"@type":"Question","name":"Why did MMX eventually become obsolete after SSE2 was introduced?","acceptedAnswer":{"@type":"Answer","text":"SSE2, released by Intel in 2000, brought the integer SIMD operations MMX was known for into the newer 128-bit XMM register architecture, letting programmers process 16 pixels at once instead of MMX's 8 pixels per 64-bit register. Because SSE2 offered wider registers and covered MMX's integer strengths while also supporting floating-point SIMD, it made the older MMX registers largely unnecessary. Follow how SIMD register widths evolved from MMX to SSE2 and beyond for performance-critical code on daily.dev."}}]} ```