Stroustrup Says C++ Beats C Code as Optimizers Outmatch Hand Tuning

Ryan Peterman

C++ abstractions generate faster code than C because modern compilers exploit high-level semantic context that manual pointer tricks obscure and modern CPU caches penalize.

AI-assisted summary of Bjarne Stroustrup (Creator of C++) On Why C++ Is Faster Than C — original source. Check the original for full context.

Source published: 2026-07-16

Key ideas

Bjarne Stroustrup refutes the belief that C is fundamentally faster than C++, pointing out that both share an identical underlying machine model since C adopted C++11's memory and concurrency model. (0:00)
C++ features enable 'negative-overhead abstractions' because richer semantic and type information allows compilers to generate faster machine code than low-level C counterparts. (0:00)
Manual micro-optimizations from the 1980s and 1990s often pessimize modern performance by degrading CPU cache locality and hindering compiler alias analysis. (3:11)
In a real-world fluid dynamics benchmark, deleting convoluted manual optimizations reduced the codebase to 80% of its size while boosting performance by 20%. (3:11)

Detailed notes

## Background This video was published on YouTube by Ryan Peterman on July 16, 2026. It is an excerpt from a longer conversation with Bjarne Stroustrup, the creator of C++, discussing Bell Labs, programming language design, and why modern C++ can outperform C.

## TL;DR Bjarne Stroustrup challenges the conventional belief that C is inherently faster than C++, explaining that both languages share the same underlying machine model while C++ provides richer semantic intent and compile-time evaluations that enable 'negative overhead' abstractions. Although an expert with infinite time might hand-craft tighter assembly for an isolated loop, human developers cannot outperform modern compiler optimizers across large-scale software. Stroustrup notes that legacy 1990s micro-optimizations frequently pessimize modern hardware performance by disrupting cache locality and compiler analysis. Instead, he advocates writing clean, expressive high-level abstractions for the vast majority of a codebase and using hardware profilers to optimize only the critical 2–3% of bottlenecks.

## Atmosphere & style The conversation carries the pragmatic, grounded authority of a legendary systems designer debunking persistent software dogma with dry wit and calm clarity. Peterman plays the role of an inquisitive interlocutor voicing common engineering assumptions, allowing Stroustrup to respond with self-deprecating humor and battle-tested industry anecdotes. Listening to the exchange feels like sitting in on an informal yet profoundly illuminating masterclass, where sweeping performance myths are gently disassembled in favor of disciplined measurement and architectural simplicity.

## Bulletin - [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) Bjarne Stroustrup refutes the belief that C is fundamentally faster than C++, pointing out that both share an identical underlying machine model since C adopted C++11's memory and concurrency model. - [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) C++ features enable 'negative-overhead abstractions' because richer semantic and type information allows compilers to generate faster machine code than low-level C counterparts. - [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Manual micro-optimizations from the 1980s and 1990s often pessimize modern performance by degrading CPU cache locality and hindering compiler alias analysis. - [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) In a real-world fluid dynamics benchmark, deleting convoluted manual optimizations reduced the codebase to 80% of its size while boosting performance by 20%.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) C and C++ share the same fundamental machine model, with C directly incorporating the memory and concurrency model defined in C++11. - [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) When identical low-level procedural code is written in both C and C++, modern compilers produce equivalent machine code. - [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) High-level abstractions in C++ give the compiler optimizer extra semantic context and intent, allowing it to outperform hand-written C. - [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) Compile-time evaluation allows C++ abstractions to disappear completely, achieving zero or even negative runtime overhead. - [01:36](https://www.youtube.com/watch?v=htY1IFhrGGc&t=96s) While a brilliant engineer with unlimited time could theoretically beat a compiler on an isolated loop, human developers cannot outperform modern optimizers across large codebases. - [01:36](https://www.youtube.com/watch?v=htY1IFhrGGc&t=96s) Over 98% of any given codebase is already fast enough when using expressive modern C++ abstractions. - [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Overly clever manual optimizations are brittle because they are closely coupled to specific hardware architectures. - [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Complex pointer manipulation and custom memory schemes from the 1990s disrupt modern CPU cache lines and compiler alias analysis. - [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Removing manual micro-optimizations in a fluid dynamics test suite reduced code size by 20% and increased execution speed by 20%. - [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Developers should adhere to Donald Knuth's advice on optimization, restricting manual tuning to the critical 2% to 3% of code identified through empirical profiling.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=htY1IFhrGGc&t=0s) Machine Models and Negative Overhead Abstraction

Ryan Peterman opens by questioning a common intuition held across software engineering: that writing code "closer to the machine" inherently yields higher performance, leading many developers to assume C is fundamentally faster than C++. Bjarne Stroustrup immediately pushes back against this assumption. He points out that C and C++ share the exact same underlying machine model, noting that C explicitly adopted the memory and concurrency model defined in C++11. When identical, low-level procedural code is written in both languages, modern compilers produce equivalent machine code.

The divergence happens when leveraging modern C++ features. Stroustrup explains that C++ compilers have superior compile-time calculation capabilities and receive richer type and intent information from high-level abstractions. When an optimizer has more semantic context to work with, it can generate code that runs as fast as or faster than C. In response to Peterman's suggestion that higher-level abstractions must introduce overhead, Stroustrup emphasizes that C++ abstractions are designed to vanish completely during compilation. He jokes that his traditional term, "zero-overhead abstraction," actually sells the language short:

> “And people are beginning to take me to task for that because that's underestimating the and understating the ability of the C++ plus compiler. We can do negative overhead uh, abstraction.”

- Both C and C++ rely on an identical underlying machine model, as C incorporated the C++11 memory model. - High-level abstractions provide the compiler optimizer with extra semantic information, allowing it to perform optimizations that raw C code obscures. - Compile-time evaluation in C++ eliminates abstractions before runtime, producing zero or even negative runtime overhead compared to manually written low-level patterns.

---

[01:36](https://www.youtube.com/watch?v=htY1IFhrGGc&t=96s) Hand-Written Assembly vs. Modern Optimizers

Peterman follows up by asking whether a programmer who has mastered assembly language and possesses infinite time could beat modern C++ compilers. Stroustrup concedes that a brilliant engineer with unlimited time could theoretically produce tighter code for an isolated hot loop. However, he counters with the reality of software engineering: humans do not have infinite time, and software engineers are no longer as smart as modern compiler optimizers across large codebases. Human ingenuity can only realistically be focused on tiny fragments of an application, meaning manual low-level tricks quickly hit diminishing returns.

Stroustrup recounts an address he gave to an audience composed of low-latency finance engineers who obsess over micro-optimizations. He deliberately titled his talk *“Don't be (too) clever,”* joking that he could not pronounce the parentheses out loud, but was pleased that he *"got out alive."* His core message was pragmatic: modern C++ is more than fast enough for over 98% of any given codebase. Relying on expressive language abstractions frees up engineering time so developers can reserve manual tuning for the fraction of code that truly requires it.

```mermaid flowchart TD accTitle: Modern Optimization Strategy accDescr: Flowchart contrasting brittle manual optimizations with the modern profile-guided approach.

subgraph Problem["Manual 'Clever' Code"] A["Manual pointer tricks & assembly"] --> B["Tied to specific CPU architecture"] B --> C["Hardware update / compiler upgrade"] C --> D["Pessimized performance & cache misses"] end

subgraph Solution["Modern C++ Approach"] E["Write expressive high-level C++"] --> F["98%+ of codebase is fast enough"] F --> G["Profile and time bottlenecks"] G --> H["Apply targeted optimizations only to 2-3%"] end ```

> “If you are very smart and you have infinite time, uh, you can do better. Um, by and large, we are not as smart as the optimizers anymore. And we don't have infinite time.”

---

[03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Why 1990s "Cleverness" Pessimizes Modern Code

Stroustrup explains that clever optimizations tend to be deeply machine-dependent. Techniques designed around the hardware constraints of the 1980s and 1990s—such as intricate webs of pointers or complex manual memory allocation schemes—frequently backfire on modern systems. These legacy tricks hinder the compiler's alias analysis, thrash CPU caches, and degrade cache line locality. When migrating code across new hardware generations or updating compilers, these manual micro-optimizations often pessimize performance rather than improve it.

Whenever he needs to improve the throughput of an application, Stroustrup's standard first step is to strip away the "clever" code entirely. Removing convoluted pointer arithmetic and manual memory pools almost always speeds up execution because it lets the optimizer maximize cache performance. He illustrates this with an empirical example from a fluid dynamics test suite he co-authored with a colleague in Spain. By deleting convoluted, manual optimizations and shrinking the codebase down to roughly 80% of its original size, they achieved an instant 20% performance improvement.

Invoking Donald Knuth's famous dictum on premature optimization, Stroustrup emphasizes that the critical threshold is knowing where to stop:

> “Knuth says don't do premature optimization. But he also pointed out that 2 to 3% is where you uh where you stop optimize. Which is exactly the number I'm using.”

Peterman clarifies that this "cleverness" refers to human-level, manual resource management meant to eke out marginal speed. Stroustrup agrees, emphasizing that developers must write clean high-level abstractions first, measure with real hardware timers rather than guessing, and only target bottlenecks when data proves it necessary:

> “Code that was cleverly and correctly optimized in 1990s are often pessimized today because machine architectures have changed. And the compilers have improved.”

- Intricate pointer usage and manual heap allocations confuse modern compiler optimizers and hurt hardware cache utilization. - In a non-toy fluid dynamics benchmark, stripping out manual optimizations cut the codebase down to roughly 80% of its size while delivering an immediate 20% speed boost. - Developers should avoid guessing at bottlenecks; code must be timed with real hardware profilers before considering manual micro-optimizations.

## Notable quotes > [03:11](https://www.youtube.com/watch?v=htY1IFhrGGc&t=191s) Code that was cleverly and correctly optimized in 1990s are often pessimized today because machine architectures have changed. And the compilers have improved. — Bjarne Stroustrup

## Mentioned Bjarne Stroustrup, Ryan Peterman, C++, C, C++11, Donald Knuth, Bell Labs, The Peterman Pod

## Video description This is a clip from a longer conversation with Bjarne Stroustrup (Creator of C++). We talked about what Bell Labs was like, programming language design, and interesting anecdotes from his experience.

Full conversation here: • YouTube - https://youtu.be/U46fJ2bJ-co • Spotify - https://open.spotify.com/episode/52pEgoAglP6iPSNCxNeEvi?si=20L-_ZwnQyK_PzqaK0zNZQ • Apple Podcasts - https://podcasts.apple.com/us/podcast/the-peterman-pod/id1777363835 • Transcript - https://www.developing.dev/p/creator-of-c-bell-labs-negative-overhead

[Source](https://www.youtube.com/watch?v=htY1IFhrGGc)

中文简报

Stroustrup称现代优化器超越手动调优，C++性能胜过C语言现代编译器能够利用高级语义上下文，而手动指针技巧会掩盖这些信息且现代CPU缓存会对其施加惩罚，因此C++抽象生成的代码比C语言更快。 Bjarne Stroustrup对C语言必然比C++更快的传统观念提出了质疑。他解释称，这两种语言共享相同的底层机器模型，而C++提供了更丰富的语义意图和编译期求值，从而实现了“负开销”抽象。尽管拥有无限时间的专家或许能为孤立的循环手写出更紧凑的汇编代码，但在大型软件中，人类开发者无法超越现代编译器优化器。Stroustrup指出，20世纪90年代的遗留微优化往往会破坏缓存局部性并干扰编译器分析，反而在现代硬件上导致性能下降。因此，他提倡在绝大多数代码库中编写整洁、富有表现力的高级抽象，并利用硬件性能分析工具仅针对关键的2%至3%瓶颈进行优化。 Bjarne Stroustrup驳斥了C语言从根本上比C++更快的观点，并指出自C语言采纳C++11的内存和并发模型以来，两者便共享完全相同的底层机器模型。 (0:00) C++特性能够实现“负开销抽象”，因为更丰富的语义和类型信息让编译器能够生成比低级C语言对应实现更快的机器代码。 (0:00) 20世纪80年代和90年代的手动微优化往往会降低CPU缓存局部性并阻碍编译器的别名分析，从而常常导致现代硬件性能下降。 (3:11) 在一个真实的流体动力学基准测试中，删除繁琐的手动优化后，代码库缩减至原有规模的80%，同时性能提升了20%。 (3:11)

Reading summary

Bjarne Stroustrup argues that C++ can match or surpass C in runtime performance because modern compilers leverage rich type information and compile-time evaluation, whereas manual low-level micro-optimizations frequently degrade performance on modern architectures. Shared Machine Models and Negative Overhead (0:00) Stroustrup refutes the assumption that C is inherently faster than C++ simply because it operates closer to the machine. He notes that both languages share the same underlying machine model, pointing out that C explicitly adopted the memory and concurrency model introduced in C++11. When writing identical procedural code, modern compilers generate equivalent machine output for both languages. Where C++ diverges is in its compile-time capabilities and type systems. Stroustrup explains that high-level abstractions supply the optimizer with intent and semantic context that raw pointer manipulation obscures. Because these abstractions vanish during compilation, they introduce zero runtime cost. He argues they can even yield "negative overhead" by enabling optimizations that would be impractical or error-prone to implement manually in low-level code. Compiler Optimizers Versus Hand-Written Code (1:36) Addressing whether an expert with infinite time could outperform a compiler using hand-written assembly, Stroustrup concedes this might hold for an isolated hot loop, but rejects it as a viable software engineering strategy. Across large systems, human developers cannot match the holistic optimization capabilities of modern compilers, nor do they possess unlimited time to fine-tune code. Recalling an address to low-latency finance engineers titled "Don't be (too) clever," Stroustrup emphasizes that expressive C++ abstractions are fast enough for more than 98% of any given codebase. Relying on the compiler for the vast majority of the program preserves developer effort for the tiny fraction of code where specialized tuning is genuinely required. Why Legacy Cleverness Pessimizes Modern Architectures (3:11) Techniques once considered optimal in the 1980s and 1990s—such as intricate pointer networks and manual memory pooling—frequently backfire on modern hardware. According to Stroustrup, these legacy idioms hinder compiler alias analysis and degrade CPU cache line locality, turning historical optimizations into performance bottlenecks whenever hardware or compilers are upgraded. Stroustrup notes that his first step when tuning an application is often stripping out manual micro-optimizations. In a fluid dynamics test suite he co-authored, eliminating convoluted manual optimizations shrank the codebase to roughly 80% of its initial size while delivering an immediate 20% speedup. Citing Donald Knuth's guidance on premature optimization, he stresses that manual intervention should be restricted to the remaining 2% to 3% of code, guided strictly by hardware profilers rather than developer intuition. Stroustrup concludes that modern software performance depends on clean, expressive abstractions that assist compiler analysis and hardware cache utilization, rather than manual low-level tricks. Developers should rely on high-level C++ by default and restrict manual micro-optimization strictly to verified bottlenecks identified by hardware timers.

精炼阅读摘要

C++ 创造者 Bjarne Stroustrup 指出，C++ 与 C 共享相同的底层机器模型，现代 C++ 凭借编译期计算与高层抽象提供的丰富语义信息，不仅能消除抽象开销，更能协助优化器生成超越传统手写 C 代码的高效机器指令。机器模型一致性与负开销抽象 (0:00) 软件工程界普遍存在一种直觉，认为越贴近机器底层的代码性能越好，并由此推测 C 语言本质上快于 C++。Stroustrup 明确反驳了这一观点，强调两者基于完全一致的硬件底层模型，因为 C 语言明确吸收了 C++11 制定的内存与并发模型。在编写等效的底层过程式代码时，现代编译器生成的机器码没有任何性能差异。两者的分水岭体现在现代语言特性的应用。Stroustrup 表示，C++ 编译器具备出色的编译期求值能力，能从高层抽象中获取更丰富的类型与开发者意向。当优化器掌握更多语义上下文时，生成的代码性能便能与 C 持平甚至更优。他认为传统术语“零开销抽象”（zero-overhead abstraction）低估了 C++ 编译器的能力，现代 C++ 能够在编译阶段完全消除抽象层，实现超越手写底层代码的“负开销抽象”（negative overhead abstraction）。现代优化器与工程现实破除手写神话 (1:36) 针对“顶级程序员投入无限时间手写汇编能否超越编译器”的假设，Stroustrup 承认，技术顶尖的工程师在时间充裕的情况下确实可能在极个别孤立的热点循环中榨取微弱优势。但在实际工程中，团队不具备无限时间，而且在庞大复杂的现代代码库全局范围下，开发者的综合调优洞察力已经赶不上现代编译器优化器。人工微优化的边际效益极低，且难以规模化铺开。 Stroustrup 曾对关注微秒级延迟的金融行业工程师提出“不要过于机巧”（Don't be (too) clever）的建议。他指出，现代 C++ 的抽象表达能力足以让项目中超过 98% 的代码直接达到优异的执行效率。依赖语言自身的高级抽象不仅能保证性能，还能节省出大量的工程时间，让开发者有精力去专门应对少数真正存在瓶颈的狭窄代码路径。历史微优化在现代硬件架构中的反噬 (3:11) Stroustrup 解释称，针对 20 世纪 80 至 90 年代硬件限制所设计的机巧优化（如复杂的指针网络与手动内存分配策略）在现代计算机上往往适得其反。这类历史遗留的底层技巧会阻碍编译器的别名分析（alias analysis），造成 CPU 缓存抖动并降低缓存行局部性，在硬件迭代或编译器更新后反而会劣化（pessimize）系统性能。为了改善程序吞吐量，Stroustrup 通常首先剔除代码库中自作聪明的手动优化。他以一项流体力学测试套件的实际重构为例说明：在删减大量底层复杂优化后，代码体积缩减至约 80%，同时直接获得了 20% 的运行速度提升。引用高德纳（Donald Knuth）关于警惕过早优化的观点，Stroustrup 强调开发者应先编写清晰的高级抽象，利用硬件计时器和性能分析工具精准定位，仅对数据证实的 2% 至 3% 的瓶颈区域进行针对性优化，避免主观臆测。 Stroustrup 总结认为，追求现代性能的关键在于依靠清晰的高层抽象向编译器传递完备语义，而非依赖过时的手动内存与指针技巧；开发者应当先通过可读代码获得基准性能，再借助真实硬件性能分析工具，将有限的人工调优精准限制在 2% 至 3% 的核心代码段。

Source quotes

[3:11] Bjarne Stroustrup: Code that was cleverly and correctly optimized in 1990s are often pessimized today because machine architectures have changed. And the compilers have improved.

Original transcript

[0:00] Generally with programming languages, [0:02] there's this [0:04] you know, high-level intuition that the [0:06] closer to the machine you are, the [0:08] higher the performance is. And um, you [0:11] know, I I tend to see C as closer to the [0:14] machine than C++ for instance. Um, you [0:18] know, that's not the case. [0:19] >> It's not the case. It's not as good as [0:21] compile time calculation as C++ is. And [0:26] anyway, we have exactly the same machine [0:28] model because [0:31] C borrowed the C++ 11 machine model. [0:35] Um, so [0:37] if you write the same code in both [0:39] languages, it's [0:40] you get the same result. Except the C++ [0:44] compilers can do more at compile time. [0:48] And so C++ runs as fast or faster than C [0:53] in most cases. [0:55] There's more information. [0:57] If if if you give the [0:59] optimizer some more information, it can [1:01] do a better job. [1:02] >> Ah, okay. Yeah, cuz that was what I was [1:04] going to ask you was [1:06] you had said somewhere that C++ can be [1:09] more performant than C, but I tend to [1:12] think that more abstraction costs you [1:14] something. [1:14] >> It's compiled away. This is why I talk [1:17] about zero overhead abstraction. [1:20] And people are beginning to take me to [1:22] task for that because that's [1:25] underestimating the and understating the [1:28] ability of the C++ plus compiler. We can [1:31] do negative overhead uh, abstraction. [1:36] >> What if I was really good at writing [1:38] assembly and I had all the time in the [1:40] world to write it? Could that How about [1:42] How does that compare? [1:44] >> If you are very smart [1:47] and you have infinite time, [1:49] uh, you can do better. [1:52] Um, [1:53] by and large, we are not as smart as the [1:57] optimizers anymore. [1:59] And we don't have infinite time. [2:02] So, if we are [2:03] smart enough, we can only do a small [2:06] piece of code. [2:08] And now [2:09] the question is did we get [2:12] enough time to use our smarts? [2:15] Uh [2:16] this is even starting to affect [2:20] uh clever code. [2:23] I gave a talk to [2:25] uh Slack last year, which is the group [2:27] of [2:28] very performant interested people from [2:32] the finance industry. [2:34] And my title was don't be clever. [2:39] Actually, the written title was don't be [2:41] too clever, but I can't pronounce [2:43] parentheses. [2:44] Um [2:46] and I got out alive. [2:48] Um and my main point was that C++ is [2:52] good enough [2:54] for [2:56] uh more than 98% of your code. [2:59] So, if you want time to be clever, [3:02] you use these techniques that I showed [3:04] modern C++. [3:06] And that way you get time so you can do [3:09] all the clever optimizations. The [3:11] problem is clever optimizations these [3:13] days tend to be machine dependent. [3:17] That is, if you get a new [3:20] computer or if you get a new version of [3:23] the compiler, you might actually have [3:26] pessimized your code. I've seen this [3:29] repeatedly ever since the [3:31] uh the ages. [3:33] Uh [3:34] and there there there there's people who [3:36] does nothing but uh [3:39] um [3:40] using different optimizations on the [3:42] next generation hardware. [3:45] And um my standard techniques for [3:49] um [3:49] for for improving things [3:52] actually is to first throw away the [3:54] clever stuff. [3:57] And then see if you run fast or slow. [4:01] Usually you run faster. Because clever [4:03] stuff tend [4:05] at least 9090s [4:07] store style clever stuff, which is [4:09] there's a lot of it still today. [4:12] Because the techniques carry on in [4:15] people's heads and [4:17] some of the code remains. [4:20] Uh tend to use a richness of pointers. [4:23] And that [4:24] gives the compilers and optimizers [4:27] problems. [4:29] They also sometimes use [4:32] more allocations. [4:34] Which is not good. You want to minimize [4:36] memory access. You want to [4:38] maximize your cache performance and [4:42] things like that. [4:44] And compilers are getting very good at [4:46] that. [4:47] And I have seen [4:49] this kind of thinking. I wrote a paper [4:52] about it together with a friend of mine [4:54] in Spain doing fluid dynamics. [4:58] And uh [4:59] uh we we we threw away [5:02] uh the clever stuff for a [5:04] uh [5:05] uh [5:07] actually a performance uh [5:09] test suite example. So it was not toy. [5:14] And we got only 20% improvement. [5:17] You know, [5:18] by reducing the code to about 80% of uh [5:22] what it was before. [5:24] And so some people didn't think that was [5:27] significant. I thought it was a [5:29] significant proof that the technique was [5:31] appropriate. You apply optimizations [5:35] only when you need them. [5:37] Knuth says don't do premature [5:40] optimization. But he also pointed out [5:42] that 2 to 3% is where you [5:45] uh where you stop optimize. Which is [5:47] exactly the number I'm using. [5:51] And so, first build the stuff [5:54] using high-level facilities, [5:57] see if it's good enough, and if it isn't [6:00] uh, and you have to time it. You don't [6:03] guess, you time. Uh, then you [6:06] uh, [6:07] then you figure out where the time is [6:09] spent, and then you optimize that. [6:12] But, a lot of the time you don't need to [6:14] go to that stage. It's It's fast enough. [6:18] >> I see. So, when you say cleverness here, [6:20] it's uh, like human-level uh, manual [6:23] management that eke out performance. [6:25] Yes. And you're saying that actually, if [6:28] you don't do that, the compiler you're [6:30] giving the compiler more to optimize, [6:32] and they can do a good job. [6:34] >> It's and it's much much better than it [6:36] used to be. Code that was cleverly and [6:39] correctly optimized in 1990s [6:43] are often pessimized today [6:47] because machine architectures have [6:49] changed. [6:51] And the compilers have improved.