Jim Keller Rejects x86 Hegemony, Backs RISC-V for AI Compute

[7] Jim Keller, Silicon Wizard 🧙‍♂️ — TechTechPotato

TechTechPotato

Keller argues instruction set architectures dictate negligible efficiency differences compared to physical dataflow structures, positioning simplified designs like RISC-V and modular matrix tiles to outpace legacy processors as AI workloads expand.

AI-assisted summary of [7] Jim Keller, Silicon Wizard 🧙‍♂️ — original source. Check the original for full context.

Source published:

Key ideas

  • Jim Keller argues that instruction set architectures (ISAs) have minimal impact on peak processor performance, as six basic instructions dominate 80% of execution and suboptimal encodings introduce at most a 10% to 20% efficiency penalty. (19:44)
  • Moore's Law is constrained by organizational misalignment between equipment toolmakers and fabricators rather than hard physics, with functioning semiconductor junctions theoretically viable down to approximately ten atoms across critical dimensions. (37:49)
  • Modern computing has split into three distinct categories—CPUs, GPUs, and dedicated AI processors—driven by vastly differing requirements for branch prediction, memory latency, and dense matrix graph execution. (21:44)
  • When turning around underperforming chip engineering teams, Keller advocates reorganizing existing internal talent rather than bringing in outside teams, pointing to AMD's Zen core turnaround which was executed predominantly by company veterans. (44:00)

Detailed notes

## Background This wide-ranging interview was published by Dr. Ian Cutress on the YouTube channel TechTechPotato on June 21, 2021. The discussion explores whether legendary silicon architect Jim Keller was truly the 'father of Zen,' covering his tenures across AMD, Intel, Apple, DEC, and Tesla, alongside his philosophies on engineering management, processor architectures, and the future of compute as CTO of Tenstorrent.

## TL;DR In this extensive conversation, Jim Keller demystifies his reputation as the 'father of Zen,' emphasizing that AMD's turnaround was driven by distributed collaboration, long-tenured internal engineers, and clean-slate organizational resets. He examines why instruction set differences between x86, Arm, and RISC-V matter far less than execution predictability and memory bottlenecks, arguing that modern compute is fracturing into CPUs, GPUs, and spatial AI hardware. Drawing on decades of leadership across DEC, Apple, Tesla, and Intel, Keller shares how he scales organizations by matching individuals to the right problems, removing political operators, and leveraging subconscious problem-solving. He remains bullish on Moore's law and discusses how future computing will evolve beyond traditional planar silicon toward photonics, biological assembly, and AI-designed black-box processors.

## Atmosphere & style The interview feels intimate, reflective, and intellectually invigorating, contrasting Dr. Ian Cutress's structured technical queries with Keller's candid, off-the-cuff storytelling. Keller speaks with the relaxed clarity of an experienced veteran who has seen repeated industry cycles, effortlessly weaving microarchitectural details together with references to Carl Jung, Shakespeare, and personal reflections on dyslexia. The dynamic carries an unpretentious, whiteboarding vibe where corporate posturing is stripped away in favor of pragmatic engineering realities and honest human psychology.

## Bulletin - [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Jim Keller argues that instruction set architectures (ISAs) have minimal impact on peak processor performance, as six basic instructions dominate 80% of execution and suboptimal encodings introduce at most a 10% to 20% efficiency penalty. - [37:49](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2269s) Moore's Law is constrained by organizational misalignment between equipment toolmakers and fabricators rather than hard physics, with functioning semiconductor junctions theoretically viable down to approximately ten atoms across critical dimensions. - [21:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1304s) Modern computing has split into three distinct categories—CPUs, GPUs, and dedicated AI processors—driven by vastly differing requirements for branch prediction, memory latency, and dense matrix graph execution. - [44:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2640s) When turning around underperforming chip engineering teams, Keller advocates reorganizing existing internal talent rather than bringing in outside teams, pointing to AMD's Zen core turnaround which was executed predominantly by company veterans.

## Key takeaways - [00:32](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=32s) Keller joined AMD in an operational VP role rather than as an advisory architect to directly align microarchitectural direction with team execution, establishing the foundation for Zen. - [05:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=316s) Keller dismisses the sole 'Father of Zen' title, crediting a distributed team across Austin, Fort Collins, Sunnyvale, Boston, and India with the core and SoC development. - [07:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=436s) Architectural rewrites rarely start completely from zero code; they generally retain or adapt 20% to 80% of RTL while restructuring bottlenecks, layouts, and dataflow pipelines. - [18:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1104s) Engineering team sizes remain capped around 150 contributors due to flat human cognitive capacity, requiring electronic design automation (EDA) and abstraction layers to absorb scale. - [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Branch prediction tables, instruction boundary predictors, and cache structures consume vastly more silicon area in modern out-of-order CPUs than decode logic, making x86 decoding overhead negligible. - [26:48](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1608s) RISC-V currently offers the cleanest and fastest target for clean-slate computer design due to its absence of legacy commercial instructions and architectural cruft. - [25:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1547s) Dedicated AI processors must combine matrix math with integrated general-purpose vector and scalar cores on the same silicon fabric to eliminate off-chip PCIe data transfer bottlenecks. - [37:49](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2269s) Semiconductor manufacturing pacing relies heavily on equipment suppliers like ASML and Applied Materials, whose technological innovations outpace individual fabrication companies. - [49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) Early career engineers develop fastest by committing deeply to solving hard problems under superior leadership rather than rapidly switching groups to pursue superficial breadth. - [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) Organizational leadership and team debugging are better informed by classical literature, Carl Jung, and Machiavelli than conventional business management books. - [01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) Conscientious, introverted engineers often need to deliberately learn self-promotion and extroverted communication to secure resources for ambitious technical architectures. - [01:26:14](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5174s) Software-enforced security boundaries inevitably fail as code expands, making hardware-enforced isolation essential against side-channel and hypervisor vulnerabilities. - [01:33:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5627s) Future computing paradigms will likely move past planar silicon lithography into photonics, biological molecular assembly, and quantum neutral-atom arrays designed via AI systems.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=0s) Jim Keller's Role and Responsibilities at AMD

Ian Cutress introduces the second installment of his interview series with Jim Keller, who is serving as the CTO of AI startup Tenstorrent. While reciting Keller’s storied career spanning DEC, Apple, AMD, Intel, Broadcom, SiByte, and Tesla, Keller immediately chimes in with a quick correction: “I worked at AMD twice.”

Cutress dives directly into Keller's second stint at AMD, noting that much of the public associates him with Zen, the Project SkyBridge initiative, and AMD’s resurgence against Intel. Cutress asks Keller to clarify the rampant community confusion regarding his actual day-to-day contributions: was he in the trenches nailing down the microarchitecture for Zen, Zen 2, and Zen 3, or was he an executive setting up teams, signing off on architectural targets, and concentrating on the Arm counterpart (K12) and Infinity Fabric?

Keller sets the scene at the time he rejoined AMD. The company was relying on Bulldozer and Jaguar. Although both had interesting elements, neither achieved market success, roadmaps were not sufficiently aggressive, and AMD was falling further behind Intel. He points out that when already trailing a competitor, “you better be catching up, not falling behind.” He initially took charge as vice president of the CPU team, which was roughly 500 people. Over the subsequent three years, his organization expanded to include the SoC team, the fabric team, and several IP groups, swelling to roughly 2,400 to 2,500 people with a staff of around 15 senior directors and senior fellows.

Because of the scale of the role, Keller was not personally writing RTL. Though he views himself primarily as a computer architect rather than a corporate manager, he deliberately wanted that management seat:

> “I knew that the technical changes we had to make would be involved in getting people aligned to it, and I didn't want to be the architect on the side arguing with the VP about why somebody could or couldn't do the job or why this was the right or wrong decision.”

He pitched this premise to AMD Chief Technology Officer Mark Papermaster, who agreed to give it a try. Keller emphasizes that having executive authority alone does not solve the problem, because “people don't really do what they're told to do, right? They're do—they do what they're inspired to do.” His mandate was assessing who could execute the vision, breaking the habit of people clinging to their past work, and combating the assumption that things could not be fundamentally redesigned. Keller entered with the premise that conditions were severe enough that nearly everything required an overhaul, effectively flipping the burden of proof: instead of proving why a new idea was good, teams had to prove why an old implementation was worth keeping.

While he wasn't personally drawing every block diagram or generating RTL, he guided the architectural vision alongside key technical talent—such as Mike Clark, Leslie Barnes, Jay Fleischman, and Debjit Das Sarma. The effort spanned Zen, its Arm sibling, follow-on integration, a revamped SoC methodology, and systemic IP refactoring.

```mermaid flowchart TD accTitle: Keller's Multi-Team Organization at AMD accDescr: Diagram showing Jim Keller leading multiple distributed teams across the Zen CPU and SoC roadmap.

subgraph Leadership["Executive Architectural Leadership"] JK["Jim Keller<br/>(VP / Chief Nudge)"] MP["Mark Papermaster<br/>(CTO)"] JK <-->|"Alignment & Strategy"| MP end

subgraph OrgTeams["Distributed Engineering Teams"] direction TB Austin["Austin Team<br/>Core Execution & Front End<br/>(Mike Clark, Steve Hale, Suzanne)"] Colorado["Colorado Team<br/>Floating Point & Cache"] Sunnyvale["Sunnyvale Team<br/>Arm Front End / K12"] Boston["Boston Team (Harry Fair)<br/>Excavator Finishing & Physical Design"] SoC["SoC & Fabric Teams (Austin & India)<br/>SoC 15 & Infinity Fabric"] end

JK --> Austin JK --> Colorado JK --> Sunnyvale JK --> Boston JK --> SoC ```

[05:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=316s) The "Father of Zen" Moniker and Distributed Engineering

Cutress asks Keller whether he accepts the widely used title "Father of Zen," or if that honor belongs elsewhere. Keller deflects the label, joking about being “one of the uncles” instead, and points out:

> “Success has a lot of authors, failure has one, so that was the success.”

He explains that Zen was a massive collaboration among distributed teams across the world: - The core execution engine and front end were driven in Austin by engineers including Mike Clark, Steve Hale, and Suzanne. - The floating-point unit and cache hierarchy were built by the team in Fort Collins, Colorado. - The Arm front end for the paired K12 project was centered in Sunnyvale. - The SoC design was split between Austin and India, supported by a global design methodology team. - Crucial organizational moves occurred simultaneously, such as handing off Excavator to Harry Fair’s Boston group to complete its design and physical implementation, freeing up core teams to focus on Zen.

Rather than claiming solitary authorship, Keller describes his function as “the instigator and the chief nudge, and you know, part architect, part, you know, it's a transformational leader.”

[07:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=436s) Roadmap Longevity and Architectural Rewrites

Cutress asks if the pipeline of designs Keller influenced is fully out in the wild, or if remnants of his five-year roadmap are still emerging. Keller explains that building an entirely new architecture—paired with "SoC 15," the internal design effort that created the fabric and interconnect—inherently means laying out a multi-generation runway. He compares it to his earlier work at Apple: when creating a clean-slate core, you must build “big bones.”

When seeking CPU speedups, Keller observes there are fundamentally only two levers: expanding the primary underlying structures or tweaking specific microarchitectural features. Zen established wide structural bones, leaving a straightforward list of architectural performance enhancements planned out over multiple consecutive years.

Cutress brings up that AMD described Zen 3 as a complete ground-up rewrite, asking if that reflects Keller's original plans. Keller demystifies what chip teams mean by "rewrites." Even on a clean-slate top-level project like the original Zen, engineers deliberately port over functional RTL blocks from previous designs like Bulldozer and Jaguar, adapting them to fit the new top-level framework:

> “Hardware guys are super good at using code when it suits them, and so when they say they did a big rewrite, you know, they probably took some pieces and, you know, re-architected them at the top, but when they built the code, you know, it wouldn't surprise me somewhere between 20 and 80 percent of the code was the same stuff or mildly modified.”

Keller notes that true architectural rewrites are about correcting structural layout and dataflow bottlenecks rather than throwing away every line of RTL: “The key is to get the structure right and then reuse code as needed as opposed to taking something that's complicated and trying to tweak it to get somewhere.”

[09:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=592s) Career Longevity: Is Tenstorrent a "Forever Home"?

Cutress notes that Keller has continually moved between prominent companies across his career—including DEC, AMD, Apple, Tesla, Intel, and now Tenstorrent alongside his former colleague Ljubisa Bajic—and asks bluntly whether Tenstorrent is destined to be his "forever home."

Keller pushes back on the characterization that he has always been a nomad. He points out that he spent 15 years at Digital Equipment Corporation (DEC). That tenure encompassed two distinct engineering eras: - Designing refrigerator-sized minicomputers using emitter-coupled logic (ECL) within DEC’s mid-range systems division. - Transitioning to the Alpha microprocessor group, building what were then considered monstrously large chips—300 mm² silicon consuming 50 watts, a power budget that shocked the industry at the time.

After DEC, Keller joined AMD for his first tour of duty during the late-1990s dot-com boom. That fast-paced period produced the K7/Athlon, the K8/Opteron, 64-bit x86 extensions (AMD64), HyperTransport, and dual-socket multiprocessor server topologies, kicking off the cycle of building transformative technologies in intense multi-year bursts.

[11:04](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=664s) Career Transitions: SiByte, P.A. Semi, Apple, Tesla, and Joining Tenstorrent

Jim Keller traces the path of his career across the semiconductor industry, noting that although observers often view him as someone who jumps frequently between companies, his stints have often involved substantial longevity and clear deliverables. During the late 1990s internet boom, he joined SiByte, which was later acquired by Broadcom; across four years there, his group shipped several generations of products. He subsequently moved to P.A. Semi to build low-power PowerPC architectures, but the company shifted focus away from selling its product standalone with an eye toward being acquired by Apple. Keller moved to Apple directly, and when Apple bought P.A. Semi soon after, he integrated with those teams. Between P.A. Semi and Apple, he spent seven continuous years developing Apple's custom silicon foundations.

```mermaid flowchart LR accTitle: Jim Keller Career Trajectory accDescr: Sequence of Jim Keller's key roles across major semiconductor and tech firms. subgraph Early["Foundational Systems"] SB["SiByte / Broadcom<br/>(4 Years)"] --> PA["P.A. Semi"] PA --> AP["Apple<br/>(7 Years combined)"] end subgraph Growth["Architectural Revolutions"] AP --> AMD["AMD<br/>(Zen Architecture)"] AMD --> TS["Tesla<br/>(Hardware 3 / FSD)"] TS --> IN["Intel<br/>(Silicon Eng. Group)"] end subgraph Startup["Next-Gen Compute"] IN --> TT["Tenstorrent<br/>(CTO & President)"] end ```

After Apple, Keller returned to AMD, where he spearheaded the architecture teams before jumping to Tesla. At Tesla, his team delivered the Hardware 3 (Full Self-Driving) computer from scratch:

> “Standing start to driving the car in 18 months, I don’t think that’s ever been done before.”

Tesla manufactured roughly one million of those custom processors the prior year. Addressing his mindset as an engineer and executive, Keller acknowledges his specific operational strengths:

> “I like either a clean piece of paper or a complete disaster, you know, that seems to be the things I do best at. It's good to know yourself; I'm not an operational manager.”

Now serving as CTO and President of AI processor startup Tenstorrent, Keller emphasizes that he has significant personal financial equity and deep professional commitment to his colleagues there, viewing it as a long-term venture aimed at capitalizing on explosive machine-learning compute workloads.

- SiByte: 4 years through Broadcom acquisition; delivered multiple product generations. - P.A. Semi / Apple: Combined 7 years developing custom silicon architectures. - Tesla Hardware 3: Designed and deployed from scratch to production vehicle testing in 18 months; over 1,000,000 units manufactured in the past year. - Tenstorrent: Keller holds major equity and leadership roles (CTO and President) with an explicit commitment to stay long-term.

---

[13:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=801s) Restructuring Silicon Engineering at Intel

Reflecting on his tenure at Intel, Keller describes the sheer scale of the Silicon Engineering Group, which encompassed roughly 10,000 engineers and dozens of concurrent system-on-chip (SoC) developments:

> “The team was 10,000 people... It was something like 60 or 70 SoCs in flight at time, literally from, you know, design to, you know, prototyping, debugging, and production.”

While Keller originally believed he was joining Intel purely to architect novel computing technologies, he ended up devoting the bulk of his energy to deep organizational and CAD methodology transformations. Intel had traditionally succeeded by building massive monolithic client and server processors. A few years prior to his arrival, the company had begun transitioning toward a modern "SoC IP" design reuse strategy, but the shift was faltering. Keller observed that simply taking monolithic heritage designs and chopping them up into modular IP blocks failed because reusable IP requires fundamentally different design collateral, qualification libraries, process technology characterizations, and automated tooling.

Managing that scale meant Keller operated almost entirely through vice presidents and senior fellows, juggling up to 14 discrete meetings a day. When Ian Cutress jokingly asks how he got anything done under such a schedule, Keller clarifies what senior executive leadership actually entails:

> “I don't get anything done; like I told you, I was the Senior Vice President... The key thing about getting somewhere is knowing where you're going and then put an organization in place that knows how to do that.”

He spent his time setting direction, making critical architectural judgment calls, and steering personnel adjustments rather than coding directly, quipping that while he wrote little source code, he sent thousands of text messages to keep execution aligned.

---

[15:57](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=957s) Assessing Intel Leadership and Career Longevity

When asked whether he would ever return to Intel now that veteran engineer Pat Gelsinger has taken over as CEO, Keller remains noncommittal, explaining that he is fully committed to his work in the rapidly expanding AI hardware sector. Nevertheless, he speaks highly of Gelsinger's technical heritage:

> “He definitely cares a lot about Intel and he's had real success in the past, so he's definitely going to bring a lot more technical focus to the company.”

At the same time, Keller pushes back against common external narratives by noting that he genuinely enjoyed working alongside former Intel CEO Bob Swan.

Pondering whether decades of pivoting between high-performance computing, low-power mobile architectures, and AI accelerators ever gets boring, Keller explains that the core challenge remains perpetually fresh even if the physics of computation never changes:

> “Computers at the bottom, they just, you know, you add ones and zeros together... It’s not that complicated, but... the building block shifted from, you know, 200 gates to four teraflops, so that’s kind of a wild transformation.”

On the DEC VAX 8800 early in his career, systems were built from gate arrays packing a mere 200 logic gates per chip. By contrast, Tenstorrent's Tensix processor cores each deliver four trillion operations per second (4 TOPs), arrayed across more than 100 cores per die. Keller notes that while the raw scale and automated electronic design tooling evolved exponentially, human cognitive capacity evolved not at all.

---

[18:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1104s) Organizational Scaling: The Limit of Human Bandwidth

Discussing whether modern engineers require greater interpersonal and soft skills to navigate modern multi-layered technology stacks, Keller rejects the premise that individuals can simply shoulder broader multidisciplinary burdens through personal effort alone:

> “Here’s the fundamental truth: people aren’t getting any smarter, right? So people can’t work across more things, that’s just dumb. Right, you do have to build tools and organizations that support people's ability to do complicated things.”

To illustrate this constraint, Keller highlights that the DEC VAX 8800 design team had approximately 150 engineers. Decades later, the Apple engineering team that built the foundational Hurricane custom processor core consisted of almost the exact same head count: about 150 people. The productivity difference did not stem from wider individual communication nets, but from modern design automation: - Placement and routing tools went from handling 200 gates to over 2,000,000 gates automatically. - Simulation farms scaled from single machines to thousands of compute nodes running concurrent regressions. - The social bandwidth of individual contributors remained completely flat.

Keller observes that an engineer required to communicate deeply with more than five people in a single working day will quickly lose focus and effectiveness. True scaling, therefore, depends on constructing clear organizational abstraction boundaries rather than forcing individual engineers to multitask across wider human and technical surface areas.

---

[19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) The Reality of Instruction Sets: x86 vs. Arm vs. RISC-V

Addressing the persistent industry debate over instruction set architectures (ISAs)—specifically x86 versus Arm versus RISC-V—Keller dispels the belief that the ISA fundamentally dictates modern high-performance processor performance. In practice, code execution is overwhelmingly dominated by a tiny handful of foundational primitives:

> “Eighty percent of the execution is like six instructions: load, store, add, subtract, compare, and branch. You pretty much covered it.”

```mermaid flowchart TD accTitle: Execution Breakdown and Predictor Dominance accDescr: Illustration showing how six instructions dominate execution and branch prediction dominates die area. subgraph Operations["Execution Profile (~80% of Workloads)"] direction LR I1["Load / Store"] I2["Add / Subtract"] I3["Compare / Branch"] end subgraph Hardware["Die Area Allocation"] direction LR P["Predictors & Branch Tables<br/>(Determines limits of modern IPC)"] D["Decoder ROM & Logic<br/>(Historically ~33-50%, now negligible)"] end Operations -.->|"Governed by"| P ```

While suboptimal instruction encodings can cost an architecture 10% to 20% in raw efficiency, modern microarchitectural techniques have largely neutralized the traditional penalties of variable-length instructions like x86. Historically, variable-length x86 code was notoriously complex to decode compared to clean, fixed-length RISC formats. In modern super-pipelined out-of-order processors, however, designs rely on dense branch target and instruction-boundary prediction tables to map instruction locations in advance: - **Historical Silicon Distribution**: Early RISC implementations held a significant edge because early x86 chips devoted 30% to 50% of their total die area to microcode ROM. - **Modern Silicon Distribution**: On modern nanometer process nodes, instruction decoders, adder circuits, and microcode ROMs are minuscule features on the die. - **Fixed vs. Variable Length**: Fixed-length instructions remain beneficial for tiny low-power microcontroller designs, but in large high-performance cores, branch predictors and predecode hardware comfortably dwarf decode logic overhead.

Keller concludes that the primary barrier limiting modern computer performance is predictability—especially branch prediction and cache predictability—rather than the surface-level mechanics of the instruction set syntax itself.

[21:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1304s) Predictors, Adders, and Three Kinds of Computers: CPU, GPU, and AI

Jim Keller explains how modern CPU design has shifted its transistor budget toward prediction. Modern chips rely heavily on instruction predictability, branch predictability, and data locality. Because modern branch predictors must anticipate complex program behavior, they have grown dramatically in size—to the point where the predictors are significantly larger than the execution adders themselves. This creates a fundamental contrast between CPUs, GPUs, and specialized AI hardware:

```mermaid flowchart TD accTitle: Comparison of Three Compute Paradigms accDescr: Diagram illustrating differences in workload handling between CPUs, GPUs, and AI engines.

subgraph CPU["CPU (Complex Control & C Programs)"] C1["Large Predictors & Caches"] --> C2["Few Threads, Complex Logic"] C2 --> C3["Optimized for Serial Code & Branches"] end

subgraph GPU["GPU (Massive Fine-Grained Parallelism)"] G1["Thousands of Simple Threads (~6,000)"] --> G2["Massive Array of Adders/ALUs"] G2 --> G3["'Army of Ants' Processing 8M Pixels"] end

subgraph AI["AI Engine (Coarse Matrix & Graph Compute)"] A1["Fewer Threads, Massive Multipliers"] --> A2["Spatial Mesh of ~4 TOPS Tiles"] A2 --> A3["Optimized for Dataflow & Large Math"] end ```

GPU advocates often point out that their chips eliminate branch predictors in favor of raw compute, packing in vastly more adders and subtractors because they execute workloads in parallel. Keller notes that while this trade-off makes sense for parallel graphics pipelines, GPUs struggle at running standard C programs. GPUs were architected to execute shader programs over millions of pixels—a modern GPU might manage 6,000 threads executing thousands of instructions per frame across 8 million pixels, behaving like “an army of ants carrying around grains of sand.”

In contrast, dedicated AI supercomputers tackle problems that are inherently large rather than composed of tiny individual pixel tasks. They feature massive matrix multipliers and a much smaller number of threads executing large volumes of math. Keller emphasizes that the industry has split into three distinct categories of machines: CPUs, GPUs, and AI processors. While Nvidia attempts to straddle the middle ground by enhancing GPUs for AI workloads—achieving undeniable success despite considerable architectural complexity—this mirrors historical patterns where general-purpose CPUs added vector extensions to handle small vector tasks while leaving heavy workloads to dedicated GPUs.

As Jim Keller summarizes: > “So there's genuinely three different kinds of computers: CPUs, GPUs, and AI.”

---

[23:42](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1422s) Graph Computing and Sizing the AI Engine: The Tenstorrent Architecture

Ian Cutress brings up Keller’s prior comments that moving beyond simple matrix multiplication requires mapping out massive graph structures, which is central to Tenstorrent’s design as a graph compiler and compute engine. Keller frames this progression through the evolution of hardware math capabilities alongside transistor budgets:

* **Scalar math** ($A = B + C \times D$): The baseline era when transistor counts were severely limited. * **Vector math**: Transistor growth allowed an entire equation or vector lane to execute in a single operational step. * **Matrix math**: Further transistor density enabled hardware matrix multipliers. * **Spatial / Graph compute**: Deconstructing massive operations across distributed processing blocks.

Keller cautions that hardware efficiency collapses if a matrix multiplier becomes too large, because the energy cost of moving data across an oversized execution unit wastes immense amounts of power. The goal is to identify an optimal block size—neither as tiny as an individual GPU thread nor so massive that a single matrix engine monopolizes the entire die. Tenstorrent targets medium-sized processing blocks rated around 4 TOPS (tera-operations per second), a figure Keller humorously recalls used to represent supercomputing scale.

Because an AI workload is structured as a graph of massive mathematical operations that decompose into subgraphs, the architecture maps these operations across an array of distributed 4 TOPS processors, allowing data to flow directly between them across the silicon. Keller notes that while he and his colleague Raja Koduri used to refer to this paradigm as "spatial" compute, "graph" is a more precise description.

---

[25:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1547s) Tightly Coupling Vector Engines and General-Purpose Compute

Addressing Cutress's query about Tenstorrent integrating vector units and general-purpose processor cores into next-generation graph processing nodes, Keller confirms that AI pipelines cannot survive on pure matrix math alone. In real-world AI pipelines, workloads frequently need general-purpose processing or require running a C program directly on intermediate results output by an AI layer.

Integrating general-purpose CPU cores with vector units directly onto the same silicon fabric drastically minimizes transfer latency and keeps power consumption reasonable compared to round-tripping data across PCIe buses to a host CPU. Keller highlights that balancing this hybrid partition remains one of the most active frontiers in computer architecture:

> “And by the way, that's a little computer architecture research area, like what's the right—everybody has this idea what's the right mix with accelerated computing and general purpose computing, and how are people using it, and how do you build it in a way programmers can actually use it?”

---

[26:48](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1608s) Arm vs x86 vs RISC-V: The Lifecycle of ISA Bloat

When Cutress asks whether he cares about the competition between Arm and x86, Keller reflects on the predictable historical lifecycle through which all instruction set architectures (ISAs) accumulate bloat:

| ISA | Origins & Early Design | Sources of Accumulated Bloat & Complexity | Current Status | |:--- |:--- |:--- |:--- | | **x86** | Clean, simple 8-bit architecture; openly licensed by Intel to seven companies | Expanded across 16-bit, 32-bit, and 64-bit eras; added paging, hardware virtualization, legacy modes, and complex vector extensions | Heavily weighed down by legacy compatibility | | **Arm** | Clean, minimalist 32-bit RISC architecture designed as a simpler alternative to x86 | Added 16-bit Thumb, the cumbersome `IT` (If-Then) instruction, register-overlay vector/floating-point extensions, 64-bit mode, and specialized boot/security logic | Significantly more complex than its initial release | | **RISC-V** | Developed in academia as a clean, modern, open-standard ISA | Early in its lifecycle; free from commercial baggage, obsolete modes, or unnecessary extensions | Simplest and fastest foundation for building modern high-performance cores |

```mermaid flowchart LR accTitle: ISA Evolution and Complexity Accumulation accDescr: Flow diagram showing how ISAs inevitably transition from clean simplicity to complex bloat over time.

A["Clean, Simple ISA<br/>(Targeted Feature Set)"] -->|"Add Extensions & Modes"| B["Commercial Expansion<br/>(Market Demands & Back-Compat)"] B -->|"Refuse to Deprecate"| C["Legacy Baggage<br/>(Feature-on-Feature Interactivity)"] C -->|"Diminishing Returns"| D["New Clean Slate Emerges<br/>(e.g., RISC-V)"] ```

Keller explains that every architecture begins clean. When x86 arrived, it competed with chips like the Motorola 6800 and the MOS 6502 (all of which Keller programmed early in his career). Over four decades, however, features layered onto features without subtracting the past. Arm followed the same path: though originally celebrated for its purity compared to x86, it quickly accumulated complexity through Thumb, the reviled `IT` conditional execution instruction, and overlapping floating-point registers.

RISC-V represents the fresh alternative simply because of its age and pedigree. Born in university research environments where designers had no interest in bolting on superfluous commercial junk, it contains the critical core instructions necessary for performance without decades of technical debt. When selecting an ISA to build an ultra-fast modern core, Keller asserts:

> “If I was just going to say I want to build a computer really fast today, and I want it to go fast, RISC-V is the easiest one: it's the simplest one, it's got all the right features, it's got the right top eight instructions that you actually need to optimize, it doesn't have too much junk.”

Keller notes that complexity theory and engineering dynamics inevitably trigger diminishing returns. Engineers add ten good features that each improve capabilities on paper, but the cross-interactions between them make subsequent development exponentially more difficult. Customers and marketing managers demand that no legacy feature ever be removed, yet simultaneously gravitate toward newer, simpler architectures that only execute 70% of legacy functions but execute them dramatically faster.

---

[30:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1824s) Managing Legacy Baggage and the Modular CPU Architecture

Cutress questions whether x86 will ever be comprehensively overhauled or if it will simply linger as a legacy standard while alternatives like RISC-V take over. Keller points out that when AMD engineered the Zen architecture, they cleaned house by deprecating many ancient 16-bit operational paths and obsolete quirks.

The architectural secret to managing legacy instructions is isolation: support compatibility where necessary, but keep the legacy logic entirely decoupled from the high-performance execution pipeline, utilizing emulation or low-overhead fallback paths rather than letting legacy instructions dictate core clock timing or wiring.

Keller contrasts historical CPU layout with modern methodologies: * **Historical pipeline design**: In older CPUs, the boundaries separating functional blocks—instruction fetch, dispatch, execution, load/store, and L2 cache—were crisscrossed by hundreds of unbuffered wires whose signaling depended on fragile sub-cycle clock phases. * **Modern decoupled architecture**: Modern high-performance CPUs are partitioned into semi-autonomous processing domains. Interfaces communicate across structured instruction boundaries using packetized handshakes and acknowledge (`ACK`) protocols.

As Keller describes, modern processor interiors no longer resemble an intractable tangle of random signals; instead, a modern high-performance CPU functions as roughly eight distinct computers networked together on a single die, each executing dedicated stages such as instruction fetch, dispatch, integer execution, and memory management.

[031:46] The Cost of Violating Abstraction Layers

Keller explains that in chip architecture, when designing a modular unit—such as a floating-point unit—a disciplined design allows an engineer to overhaul it entirely without disrupting adjacent modules. The breakdown of this principle usually happens when under pressure: an engineer thinks, “boy, if I could just add these five wires between these two boxes, I could get rid of this problem.” Keller cautions that every hack violating an architectural abstraction creates technical debt: “Every time you violate the abstraction layer, you've created a problem for future Jim.” Over time, small shortcuts compound into architectural calcification and kill design velocity.

Ian Cutress asks Keller where this pervasive engineering ethos took root. Keller laughs at Cutress calling it a “pervasive element” of his personality, joking that he repeats the principle constantly to convince himself. He traces the realization back to his transition between Digital Equipment Corporation (DEC) and AMD:

* **DEC Alpha 21264 (EV6):** Architected alongside Dirk Meyer, EV6 relied on DEC's custom, transistor-level methodology. Keller jokes that when asked what was in their design library, his answer was simply “both of them: N devices and P devices.” Engineers rolled custom circuits with 22 different flip-flop variants, resulting in a short, tight, out-of-order execution pipeline that had immense internal interdependencies, making it excruciating to build and verify. * **AMD K7 (Athlon):** AMD used a standard cell library approach. Rather than dozens of hand-crafted variations, AMD designers relied on a clean abstraction layer between the transistors and the designers, utilizing just two primary flip-flop designs: “a big one and a little one.” Even prior to advanced automated place-and-route tools, this disciplined abstraction was far more productive. * **The S2K Bus to HyperTransport Evolution:** On the EV6 system bus (which was later licensed to AMD as the S2K bus), Keller and his team designed complex bespoke transactions for snoops, loads, stores, reads, and writes. Keller explained the implementation to Kourosh Gharachorloo, a friend at Digital Western Research Laboratory who later became a prominent security expert at Google. Gharachorloo shook his head and told him flatly: “Jim, that's not the way you do this.” He taught Keller the concept of virtual channels—establishing abstract channels of information before assigning wire-level bit encodings or bus commands. That design critique led directly to HyperTransport, AMD’s packetized, high-speed interconnect architecture. * **The K8 Misstep:** Keller admits that on their initial swing at K8, they temporarily backtracked into transistor-level thinking because he and his circuit partner, Pat Patla (or his circuit counterpart), were exceptionally comfortable reading raw transistors together. Keller realized that relying on a small handful of people who hold the whole transistor layout in their heads is an unsustainable way to scale computer engineering.

```mermaid flowchart TD accTitle: Evolution of Design Abstraction in Jim Keller's Work accDescr: Progression from transistor-level custom design at DEC Alpha to decoupled modular architectures at AMD Zen.

subgraph Alpha ["DEC Alpha (EV6)"] A1["Custom Transistor Level<br/>(22 flip-flop types, N/P devices)"] A2["S2K Bus<br/>(Tightly coupled command wires)"] end

subgraph Transition ["Architectural Maturation"] B1["Kourosh Gharachorloo Critique:<br/>Virtual Channels & Abstract Routing"] B2["Cell Library Abstraction<br/>(2 flip-flops: big & little)"] end

subgraph ModernZen ["AMD (K7, HyperTransport & Zen)"] C1["HyperTransport Packetized Fabric"] C2["Clean Front-End / Back-End Partition<br/>(200-engineer team split across clean contract)"] end

Alpha --> Transition Transition --> ModernZen ```

Keller emphasizes that abstraction layers are fundamentally human-scaling mechanisms: “If you want to build something bigger and more complicated, you better solve the abstraction layers, because people aren't smarter, and if you put more than 100 people on it, it'll slow down, not speed up.” Humans naturally maintain close familiarity with an inner circle of 10 to 20 people and can reasonably track up to 50 to 100 colleagues. Once an organization exceeds 100 engineers, everyone outside becomes a semi-stranger, requiring cleanly enforced contractual boundaries between design components.

When Keller built the original Zen architecture at AMD with a team of roughly 200 people, he enforced a strict architectural separation: approximately half the team built the front-end fetch/decode pipeline, while the other half worked on the back-end execution engine. Because the functional boundary interface was sharply defined, engineers on either side rarely had to haggle over internal microarchitectural details behind that contract.

---

[037:49] Why Moore's Law Isn't Dead

Cutress asks Keller if his relaxed stance on the continuation of Moore's Law comes from apathy or an assumption that foundry engineers will somehow resolve it. Keller rejects the notion of apathy outright: “Super proactive... that's not apathetic at all, like I know a lot of details about it.”

Keller argues that people conflate Intel's specific execution delays on its 10nm node with the fundamental limits of semiconductor physics. While Intel slipped, TSMC's roadmap proceeded cleanly because TSMC paced its cadence against ASML's EUV (Extreme Ultraviolet) machine availability:

1. **TSMC Node Pacing:** TSMC executed half-steps, delivering first-generation 7nm with standard deep ultraviolet (DUV) immersion lithography, moving to 7nm+ with initial EUV layers, scaling down to 5nm with broader EUV usage, and continuously refining lithography masks. 2. **Equipment Vendors as the True Locus of Innovation:** The public frequently views TSMC, Intel, and Samsung as the sole drivers of semiconductor progress, but Keller points out that the true locus of innovation sits within equipment makers like ASML and Applied Materials. ASML's market capitalization surpassed Intel's precisely because the equipment manufacturers design and construct the foundational tools that foundries run. TSMC alone committed to purchasing roughly 150 EUV machines by 2023.

Keller rejects claims that physical limits have been reached, pointing out that modern developments like X-ray lithography show clear paths forward. He cites Richard Feynman’s famous lecture: “There's lots of room at the bottom.” Keller states that when counting the number of atoms across a modern transistor gate, significant headroom remains: you only need roughly ten atoms across a junction before disruptive quantum tunneling and leakage dominate.

Keller describes semiconductor scaling as a complex interplay between toolmakers and fabrication craftsmen. Tool manufacturers build equipment with distinct lithography, deposition, and etching capabilities, while foundry process engineers act as master craftsmen who determine layer heights, aspect ratios, and pitch geometries. While toolmaker-foundry coordination misalignments occasionally cause multi-year delays, Keller insists that these bottlenecks are engineering alignment hurdles, not hard limits imposed by fundamental physics.

- TSMC’s execution roadmap was built around early tool adoption and multi-stage steps (7nm DUV $\rightarrow$ 7nm+ EUV $\rightarrow$ 5nm EUV). - Equipment makers like ASML and Applied Materials bear the primary research and development burden for next-generation lithography tooling. - Keller notes that a functional semiconductor junction can theoretically operate with as few as ten atoms across the critical dimension before quantum effects disrupt standard transistor behavior.

[42:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2526s) Lithography Beyond EUV: X-Rays, Multi-Patterning, and Innovation Bandwidth

Ian Cutress presses Jim Keller on the physical limits of lithography, noting that while High-NA EUV is slated to arrive within a couple of years, Keller had previously brought up x-ray lithography—a technology Ian points out is not even on his own immediate radar. Keller reflects on the commercialization timeline, recalling that new semiconductor manufacturing technologies typically enter production in highly targeted fashion rather than all at once. When extreme ultraviolet (EUV) lithography was initially integrated into DRAM manufacturing, it was deployed for just a single critical step or two before expanding. Keller estimates that initial commercial experimentation with x-rays might begin around 2023 or 2024, meaning teams are already actively playing with and testing working machines.

Keller points out that the transition from deep optical lithography (DUV) to EUV represented roughly a 10x reduction in wavelength. That optical era required extreme multi-patterning and intricate optical proximity corrections, resulting in bizarre interference patterns on masks. While EUV initially permitted direct printing of fine features, Keller explains that the exact same engineering tricks are now being reapplied to EUV itself, with EUV multi-patterning coming online around the 3nm node. Beyond the optics, making these nodes work introduces a cascade of thorny physics problems, from extreme material purity to microscopic temperature stabilization to prevent mechanical drift. Despite the daunting complexity, Keller remains confident that the industry will not stall out.

> “There's literally hundreds of thousands of people working on it so, you know, every group of 10 people have an innovation, there's more than enough innovation bandwidth.” — Jim Keller

- EUV was first introduced in DRAM fabrication for only one or two mask steps before widespread adoption. - The leap to EUV provided roughly a 10x reduction in wavelength over previous optical wavelengths. - EUV multi-patterning is anticipated around the 3nm node as feature sizes shrink below the single-exposure resolution limits.

---

[44:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2640s) Finding vs. Building a Team: Michelangelo’s Marble and Avoiding Clones

Ian shifts the conversation to Keller’s well-known track record of moving across top hardware companies and asks how he approaches building engineering teams, particularly whether he prefers bringing former colleagues along. Keller reframes the premise by distinguishing between *building* a team and *finding* one that already exists. He draws an analogy to the Galleria dell'Accademia (which he references alongside the statue of David), recalling the massive twenty-by-twenty-foot blocks of quarried marble sitting outside. Michelangelo looked at the raw stone and understood the sculpture was already inside; the only task was carving away the excess marble. Keller explains that in any company with a thousand employees, a world-class engineering team is already present in the building. During his tenure at AMD, he hardly hired anyone from the outside; instead, he simply identified, redeployed, and reorganized the exceptional talent already there.

In contrast, when Keller joined Tesla, he had to build an entire silicon team from scratch because no one at the company had ever designed chips. While he hired some familiar faces initially, he broadened recruitment to people he had never met before. Keller warns against a common executive failure mode: senior leaders jumping between companies and dragging an entourage of 20 loyalists with them. A 20-person cohort is just large enough to recreate their old environment and isolate the rest of the company, cutting off the local organization and preventing fresh thinking. Because every engineering group eventually gets stuck in a local minimum, combining one person from ten different high-performing teams often produces a superior result, as the new group actively debates and selects the best practices from their respective backgrounds.

Keller notes that an engineer who struggles in one environment can suddenly flourish when surrounded by different perspectives that challenge old assumptions. He admits that earlier in his career, he dismissed Digital Equipment Corporation founder Ken Olsen’s philosophy, but decades of management experience proved it right:

> “I used to—Ken Olsen at Digital said there's no bad employees, there's just bad employee-job matches. When I was younger I thought that was stupid, but I work with more people, I've seen it happen so many bloody times that you know, I've even fired people who went on to be really successful because they weren't doing a good job because they were stuck and emotionally they were committed to something that wasn't working.” — Jim Keller

```mermaid flowchart TD accTitle: Team Formation Approaches accDescr: Contrasting the approach of importing a cloned team versus composing a diverse team or unlocking existing talent.

subgraph AntiPattern["The Entourage Trap"] A["Leader arrives at new company"] --> B["Imports 20 former colleagues"] B --> C["Reproduces prior environment & local minimum"] C --> D["Alienates existing organization"] end

subgraph BestPractice["Adaptive Composition"] E["Evaluate context"] --> F{"Team exists?"} F -->|"Yes (e.g. AMD)"| G["Carve the marble: reorganize & redeploy internal talent"] F -->|"No (e.g. Tesla)"| H["Hire mix of trusted peers & external outsiders"] G --> I["High-trust, adaptive culture"] H --> J["Synthesize best practices across backgrounds"] end ```

---

[47:45](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2865s) Culture, Trust, and the Poison of Office Politics

Ian asks whether hiring should deliberately push against a company's existing culture or conform to it. Keller explains that it depends entirely on the operational phase. When an organization needs radical innovation, bringing in people who push against the grain is mandatory. However, if a complex project is already executing smoothly, injecting agitators will only create friction and derail delivery. The best engineers are adaptable: they can integrate seamlessly into a running project to push it across the finish line, while quietly building relationships and social capital so that they have the internal support to execute a pivot on the subsequent cycle.

At the core of high-functioning engineering organizations is unshakeable mutual trust. Keller illustrates this with a vivid hypothetical: if a stranger tells you to jump off a bridge, you refuse; but if a teammate who has bled with you through hard battles says the jump is going to hurt but you will survive, you leap without hesitating. When political operators enter the picture, that trust evaporates. Keller defines organizational politics as individuals manipulating the working environment for personal status rather than the project's success.

> “And teams that trust each other are way more effective than ones that have to do everything with contracts, negotiation, and politics.” — Jim Keller

Keller argues that political manipulators simply have to be removed immediately. The sole exception is when an executive is political but ties their political survival directly to flawless operational execution; even then, random internal politicking across lower ranks creates toxic drag and massive organizational stress.

---

[49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) Advice for Early-Career Engineers: The Tension Between Breadth and Depth

Ian asks whether early- and mid-career engineers should rotate regularly between projects to keep from stagnating in a narrow specialty. Keller agrees that career growth requires exposure to steep learning curves, but warns that rapid movement can backfire if handled improperly.

> “You learn fastest when you're doing something new working for somebody that knows way more than you.” — Jim Keller

If an early-career engineer realizes they are no longer learning or that their immediate leadership provides no inspiration, Keller recommends seeking a change. However, there is a dangerous creative tension between versatility and specialization. Keller cautions that he has seen engineers bounce across three or four different teams in rapid succession under the pretext of accumulating broad experience, only to emerge possessing deep expertise in absolutely nothing. In those instances, an engineer would have been far better served by staying put on a single challenging problem long enough to master fundamental principles deeply before attempting to generalize.

---

[50:22](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3022s) Jim Keller's Mentors: From Family Dynamics to the Legends at DEC

Ian asks Keller about the mentors who shaped his early career, inquiring about the leaders, architects, and thinkers he looked up to. Keller traces the origin of his mindset directly to his parents. His father was a professional engineer, while his mother possessed exceptional verbal and linguistic intelligence, later starting a career as a therapist. Because Keller struggled with dyslexia and could not read easily as a child, he assumed he took after his engineer father; over time, he realized his underlying cognitive style was much closer to his mother's analytical and interpersonal nature.

When Keller entered the tech industry at Digital Equipment Corporation (DEC), he found himself working directly under legendary computer architect Bob Stewart. Stewart was a powerhouse who designed landmark minicomputers and systems, including the PDP-11/44, the PDP-11/70, the VAX-11/780, and the DEC Computer Interconnect (CI) bus.

> “Somebody said every project he ever worked on earned a billion dollars, back when that was a huge number.” — Jim Keller

Surrounding Stewart was an extraordinary cohort of architects and researchers across DEC and its Western and Systems Research Labs (WRL/SRC). Keller had the opportunity to interact with and learn from pioneers like Butler Lampson, Chuck Thacker, and Nancy Kronenberg, who served as a formative mentor to him when he was just starting out in engineering.

- Bob Stewart's portfolio included foundational DEC architectures: the PDP-11/44, PDP-11/70, VAX-11/780, and the Computer Interconnect (CI) architecture. - DEC research environments exposed Keller directly to computer science legends, including Butler Lampson, Chuck Thacker, and Nancy Kronenberg.

[52:03](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3123s) Early Career Obliviousness and Arguing with Gordon Bell

Reflecting on his earliest years in the computer industry, Jim Keller recalls working alongside legendary figures, including one of the chief architects behind the VMS operating system at Digital Equipment Corporation (DEC). Looking back on whether he was intimidated by or idolized these luminaries, Keller confesses that he was simply oblivious to who they were at the time. During his very first week at DEC, new hires were being trained on a schematic drawing tool called Valid Logic Systems—a precursor to the Mentor Graphics era of electronic design automation.

In the middle of the training session, a man walked into the room, began asking questions, and lectured the group on hierarchical design. Unaware of the speaker's identity, Keller immediately began challenging him, breaking down why parts of hierarchical design were reasonable and why other parts were completely stupid. The two engaged in an intense hour-long debate. Once the man walked out, someone informed Keller that his debate partner was Gordon Bell, the legendary computer architect and Vice President of R&D at DEC. Keller replied, “Who's that?” When told Bell was DEC's head of engineering, Keller retorted: “Well, he's wrong about half the stuff he just said. I hope I straightened it out.” Attributing that boldness to a possible lack of serotonin activation rather than intentional bravado, Keller notes that it was more of a personal blind spot than a deliberate virtue.

Asked by Ian Cutress whether he has matured at all since those days, Keller laughs and remarks that he hasn't matured “a bit,” before admitting that his perspective on people has fundamentally evolved. Early in his career, he found himself getting nervous when giving talks and was frustrated that colleagues wouldn't simply do the right thing without coaxing. Over time, Keller realized that understanding how people think, what motivates them, and how to debug team dynamics is both crucial and satisfying. He also learned to reframe nervous energy into excitement, recalling how he felt zero dread when walking out in front of 2,000 people at an Intel conference. His passion for computer architecture remains as intoxicating as ever; when a friend’s wife once asked what they put in the water because engineers talk of nothing but computers, Keller's view was simple: building machines that change the world is immensely fun.

- Gordon Bell debated Keller for an hour on hierarchical design during Keller's first week at DEC, entirely unaware that the new hire had no idea who he was. - Valid Logic Systems was the CAD/drawing environment Keller trained on before the dominance of Mentor Graphics tools. - “Well, he's wrong about half the stuff he just said,” said Jim Keller after finding out the person he argued with was Gordon Bell.

---

[54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) Reading Thousands of Books and the Engineering Value of Shakespeare

Cutress notes that Keller seems to spend considerable effort studying the human condition and how people operate rather than just mouthing off at senior executives. Keller explains that books provide an unmatched return on investment: an author spends 20 years living, synthesizes their best ideas with passion, and a reader can effortlessly find the top titles on Amazon. While people often search for a short list of three or four life-altering books, Keller argues that it is the sheer volume that matters: reading a single book might occasionally spark change, but reading a thousand books is guaranteed to transform one's life.

Keller highlights that classic literature offers profound lessons for corporate environments. Reading Shakespeare or Niccolò Machiavelli reveals timeless dynamics of human nature: palace politics, devious actors, hardworking minions carrying the load, and the occasional hero stepping forward to save the day. Those patterns unfolded 500 years ago, and they play out inside modern corporate America every single day. Keller points out that anyone managing technical organizations without studying those fundamental dynamics is operating blind.

Before stepping into his first major management executive role, Keller recognized he needed a systematic framework for organizational thinking. He reached out to Venkatesh Rao, the author of the *Ribbonfarm* blog, using a "consult with me / buy me a coffee" link on the site. Keller and Rao spent hours talking before Keller joined AMD, and Rao supplied him with a tailored reading curriculum on organizational structure. Keller dutifully worked through the entire list. When he arrived in the corporate world, he discovered that while he had assumed every executive diligently studied management literature, almost none of them did: most managers read superficial books like *Good to Great*, which offer pleasant anecdotes but little structural depth. In Keller's assessment, a manager seeking real insight would learn far more about organizational behavior by reading Carl Jung than mainstream business bestsellers.

```mermaid flowchart TD accTitle: Value of Reading for Technical Leadership accDescr: Flow showing how historical human patterns inform corporate engineering management.

subgraph Literature ["Human Experience Literature"] A["Classical Literature<br/>(Shakespeare, Machiavelli)"] B["Psychology & Systems<br/>(Carl Jung, Venkatesh Rao)"] end

subgraph CorePatterns ["Timeless Social Patterns"] C["Power politics & devious actors"] D["Minions executing daily work"] E["Occasional hero saving the project"] end

subgraph Application ["Corporate America"] F["Debugging team friction"] G["Engineering management & alignment"] end

A --> C A --> D A --> E B --> F C & D & E --> G F --> G ```

- Venkatesh Rao of the *Ribbonfarm* blog provided Keller with an executive reading curriculum prior to Keller's leadership tenure at AMD. - “Reading the thousand books will change your life, that's for damn sure,” said Jim Keller regarding the compounding impact of wide reading. - “You'd be better off reading Carl Jung than Good to Great if you want to understand management,” said Jim Keller.

---

[57:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3436s) Reading Breadth, Passive Book Clubs, and Social Media Attention Spans

Keller recounts his journey as a reader, noting that he did not properly learn to read until fourth grade. However, because his parents belonged to a book club, by seventh or eighth grade he had devoured virtually every title in the family house. His early favorites included contemporary fiction writers like John Updike and John Barth. He was especially struck by the science fiction of Doris Lessing, whose novels functioned as deep psychological inquiries that expanded his thinking during formative years.

Over the last decade, his reading habits shifted from fiction toward history, anthropology, psychology, and mysticism. Cutress mentions that listeners frequently ask about Keller's reading habits, especially after Keller stated on Lex Fridman's podcast that he used to read two books a week, with many fans wishing Keller would host a "passive Jim Keller book club" on Twitter. Keller responds that while he reads continuously, his current intake consists of blog posts, technical essays, and disparate material. Moreover, he admits he lacks the sustained attention span required for social media: if he set up a public book-recommendation feed, he would inevitably abandon it for weeks at a time.

- Keller struggled to read until the fourth grade before clearing out his parents' library by middle school. - Influential authors from Keller's youth include John Updike, John Barth, and Doris Lessing's psychological science fiction series. - Though he historically read two complete books a week, his current intake leans heavily toward online essays, blogs, and multidisciplinary non-fiction.

---

[59:22](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3562s) Information Absorption, Meditation, and Prepping Dreams to Solve Problems

Cutress asks how Keller prevents his mind from wandering when consuming information and how he ensures he actually retains technical and conceptual material. Keller laughs, replying that he does not worry about retention at all. Unlike readers who laboriously highlight, annotate, and test their recall, Keller reads purely for interest and ideas. He notes that the commercial publishing model forces authors to write 250-page books regardless of whether they have 50 pages of substance or 500 pages of deep thought. Readers often encounter a brilliant 50-page thesis followed by 200 pages of filler written just to satisfy publisher length requirements.

Keller relies on a subconscious assimilation process rather than memorization. He meditates regularly, reflecting quietly on whatever problems or concepts occupy his thoughts. He believes human memory is not an indexable database where every fact and source citation can be retrieved on command; instead, compelling ideas absorb into the subconscious and reshape the reader's underlying personality and problem-solving intuition:

> “Your brain is this kind of weird thing: you don't actually have access to all the ideas and thoughts and things you've read, but your personality seems to be well informed by it. And I trust that process, so I don't worry that I can't remember somebody's name, because their idea may have changed who I was and I don't remember which book it came from.”

Beyond passive absorption, Keller deliberately uses his sleep cycles for technical problem-solving. Before falling asleep, he consciously directs his mind toward a specific engineering bottleneck or conceptual puzzle, effectively loading it into his subconscious. He finds that his mind will either directly work on the issue during dreams or discard the surface-level distraction to reveal the deeper, underlying problem he actually needed to address.

- Keller rejects manual highlighting and memorization drills, viewing the commercial 250-page publishing standard as largely padded. - Regular meditation serves as his filter for digesting concepts and integrating them into his overall thought architecture. - Keller deliberately primes his dreams prior to sleep by mentally reviewing difficult architectural problems, allowing subconscious processing to tackle the roadblock overnight.

[01:01:58](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3718s) Work-Life Balance, Sleep, and Time Allocation

The discussion turns to daily schedules, sleep habits, and managing workload when facing critical deadlines. While some executives claim to require only four hours of sleep a night, Jim Keller prefers seven. Calculating his daily priorities, Keller jokes that an ideal day would require around 34 hours to comfortably accommodate everything he likes doing: working out, spending time with his kids, sleeping, eating, reading, and working. He describes work as the unusual variable because it possesses an infinite capacity to consume more time than intended. Although he genuinely loves the process of engineering, he finds it a constant discipline to avoid letting work crowd out everything else.

Ian Cutress asks what gets sacrificed first when tight product deadlines loom, noting that time-to-market has been a central pressure across Keller's career. Surprisingly, Keller responds that exercise does not get cut; rather, his core management tactic is aggressive delegation. Once he finds his workload overflowing in a specific area, he identifies someone who possesses more enthusiasm for that task and transfers ownership. Keller explains that he personally prefers tackling unsolved problems rather than micromanaging execution.

```mermaid flowchart TD accTitle: Jim Keller Work Delegation Strategy accDescr: Flowchart illustrating Keller's workload management approach of delegating routine execution to focus on unsolved problems.

subgraph Capacity["Workload Threshold"] A["Unsolved Technical Problems"] --> B{"Workload Exceeds Capacity?"} end

subgraph Execution["Delegation & Focus"] B -->|"Yes"| C["Identify Teammate with High Enthusiasm"] C --> D["Delegate Presentations & Iterative Tasks"] D --> E["Preserve Time for Exercise, Family & High-Level Architecture"] B -->|"No"| F["Drive Core Technical Breakthroughs"] end ```

Keller jokes about his tenure at Tesla: “I was the laziest person at Tesla, as best I could tell.” While Tesla had an intense culture where employees often worked twelve-hour days to visibly demonstrate commitment, Keller worked roughly 9:00 AM to 7:00 PM. He protected his personal routine, running at lunch and utilizing a weightlifting room located at the Deer Creek facility next to the machine shop. Similarly, at large organizations like AMD and Intel, Keller relied on having strong staff members. Whenever administrative burdens like presentation preparation began consuming too much bandwidth, he reassigned the projects to colleagues eager for the opportunity and took time off.

[01:03:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3824s) The Value of Public Talks, Media, and Clarifying Ideas

Cutress inquires why Keller commits time to press interviews and marketing appearances, questioning whether such activities take time away from technical work and amount to "just talk." Keller firmly rejects this notion: “It's not just talk, you know I worked on some really interesting stuff, so I like to talk about it.” He illustrates how external communications serve internal corporate goals. While at Intel, Keller observed that many internal engineers were demoralized by the widespread narrative that Moore's Law had ended. Keller believed Moore's Law was very much alive and felt it was unacceptable for the primary semiconductor manufacturer to concede defeat on its core competency. By discussing the viability of Moore's Law in public interviews, those perspectives were amplified across the industry and echoed back into Intel, successfully shifting internal morale. He found he could influence more engineers inside Intel through external talks than through internal channels alone.

Beyond corporate messaging, Keller values the intellectual rigor demanded by explaining complex engineering concepts. Engaging with passionate journalists and analysts forces him to structure and clarify his own thoughts. Keller explains that a person only truly understands a concept when they can articulate it plainly; attempting to explain an idea often exposes hidden gaps in logic. Public speaking compels him to eliminate unnecessary noise, distill concepts to their fundamentals, and test the strength of his ideas.

- External interviews act as a lever to shape internal engineering sentiment at scale. - Structuring ideas for external audiences forces engineers to strip out false assumptions and fluff. - Keller's core motivation across all these engagements remains direct: “I had a mission to, you know, build faster computers—that's what I like to do.”

[01:05:29](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3929s) Visualization Superpowers, Dyslexia, and Grit

Cutress brings up the famous dictum—often attributed to Richard Feynman or Carl Sagan—that an inability to explain a concept to a first-year college student proves one does not truly understand it. Keller agrees that Feynman was a master of exposition in works like the *Feynman Lectures on Physics*, yet notes an ironic caveat: Feynman's intuitive grasp of mathematics was so extraordinary that his idea of a "simple" step often relied on leaps of logic that no one else in the room could follow, such as calculating complex orbital geometries in five effortless mental steps.

Turning to his own internal cognitive process, Keller shares how he conceptualizes engineering problems: “If I had one super power, it's like I feel like I can visualize how computer actually runs.” When designing architecture or developing performance models, he visualizes the end-to-end operation of the processor in his mind before transcribing it into code. He attributes this visualization capability to a blend of innate wiring, deliberate practice, and a coping mechanism developed from an adult diagnosis of dyslexia.

Discussing nature versus nurture, Keller downplays raw innate intelligence. He points out that exceptionally gifted individuals often struggle later in life because early tasks came too easily, preventing them from developing the work ethic required for complex setbacks. Keller remarks: “So I'm not that smart, definitely, so persistence and, you know, what they call grit is super useful.” Semiconductor design requires endless cycles of subtle optimization and iteration, demanding engineers who refuse to give up when designs hit obstacles. He warns young engineers against pursuing paths dictated by parental or societal expectations—such as entering management for vanity rather than passion—noting that chasing someone else's dream destroys the intrinsic drive required to master difficult technical domains.

[01:08:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4132s) Mentoring Through High Standards and Accountability

When asked if he plans to formalize his leadership role into something like a "Jim Keller School of Semiconductor Design," Keller chuckles and emphasizes that his primary driver has always been execution rather than academic instruction. His focus is on tangible, high-stakes targets: “I'm mostly mission-driven, like we're gonna build Zen, we're gonna build Autopilot.”

When building teams to execute those missions, Keller evaluates his people closely to understand what holds them back. When addressing underperformance, his direct intervention is often forceful. Keller reflects with amusement on how subordinates perceive this interaction: “People later on told me that I was mentoring them, and I'm thinking, I thought I was kicking your ass.”

Keller’s advice often extends beyond schematic design into lifestyle fundamentals, such as urging team members to fix their diet and physical health when he notices they lack energy. When addressing career plateaus, Keller diagnoses whether an engineer is genuinely mismatched with their tasks or simply obsessed with corporate ladder-climbing. He argues that political jockeying is counterproductive: “The best way to have status is to do something great and everybody thinks you're great; having status by trying to claw your way up is terrible because everybody thinks you're a climber.” True mentorship, in his view, flows directly out of keeping teams focused entirely on solving massive, consequential problems.

[01:11:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4266s) Mentoring Through Missions and Personal Debugging

Jim Keller explains that true mentoring cannot happen in an abstract vacuum. When people ask him simply to “mentor” them, he struggles with the lack of context: “I have a hard time doing that just quote mentoring people because what's the mission?” If someone comes asking to get better without an anchor, it quickly falls apart into irrelevant requests like wanting to play the violin better. Instead, effective growth happens when tied directly to an ambitious goal, such as building the world's fastest autopilot processor.

Once everyone is aligned around a mission, Keller notes that technical roadblocks are rarely the primary hurdle. Most of the friction is deeply personal. Engineers bring their entire lives to work, dealing with physical health issues, relationship troubles, parenting stress, and stalled careers. For a massive chip project to succeed, leaders must take these personal struggles seriously, even when engineers hide their real concerns behind “no-fly zones” or recite safe problems they assume management wants to hear. Once you help individuals work through those underlying issues, the project accelerates, and only then do they look back and consider you a mentor.

```mermaid flowchart TD accTitle: Jim Keller's Mission-Driven Mentorship Flow accDescr: A flow illustrating how setting a clear technical mission reveals personal roadblocks that, once resolved, lead to project success and perceived mentorship.

subgraph Mission ["The Mission"] A["Define Ambitious Goal<br/>(e.g., Fastest Autopilot Chip)"] end

subgraph Discovery ["Uncovering Obstacles"] A --> B["Identify Project Impediments"] B --> C["Personal & Workplace Roadblocks<br/>(Health, Career Stall, Family)"] end

subgraph Resolution ["Resolution & Impact"] C --> D["Debug Real Problems & Clear Blockers"] D --> E["Project Delivery & Perceived Mentorship"] end ```

[01:13:03](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4383s) Proudest Career Moments and Turning Zen Around

When Dr. Ian Cutress asks Keller whether he has a specific proudest moment, project, or accolade in his career, Keller shares that his best memories stem from moments of collaborative breakthrough. He recalls working with Becky Loop at Intel, where they were wrestling with complex quality issues across multiple architectural layers. Frustrated by the confusing data, Keller felt an immense rush of excitement when Loop walked in one day with a single visual diagram that completely clarified the situation and established a clear path to resolution.

This leads Keller to reminisce about the Tesla autopilot chip and the creation of AMD’s Zen architecture. At the time, the broader industry had written off AMD, believing the company simply could not design competitive microprocessors anymore: “Everybody thought the AMD team couldn't shoot straight and now I was very intrigued with the possibility of building a really great computer with the team everybody thought was you know out of it.” Keller emphasizes that the core team responsible for Zen—veterans like Mike Clark, Leslie Barnes, and Suzanne Plummer—were seasoned company lifers with 25 to 30 years of tenure who had already proven their ability on earlier projects.

The turnaround required honest self-assessment, clear goal setting, and confronting deep organizational defeatism. Keller recalls an iconic turning point when Suzanne Plummer informed him that the Zen team had lost faith in their ability to pull off the project:

- Keller immediately drove to the airport in California to take the first flight out, meeting the team in Austin the following morning at 8:00 AM. - He insisted on a large room equipped with abundant whiteboard space to confront roughly 30 frustrated engineers head-on. - Over two exhaustive days, the team documented every single perceived roadblock on the boards. Keller handed over the markers whenever someone knew how to tackle an issue, transforming the meeting from a defensive standoff into active problem-solving. - Mike Clark played a vital role in reinforcing confidence by declaring that every single issue listed on the boards was solvable. - Keller emphasizes that convincing a team requires relentless repetition: “How often do you have to go convince somebody? As many times as necessary.”

[01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) Silent Heroes and Learning to Play the Corporate Game

Ian asks whether there are unsung “silent heroes” in the tech world who never receive adequate credit for their achievements. Keller responds immediately that this describes the vast majority of working engineers. While high-powered corporate lawyers easily bill $800 an hour in Silicon Valley, exceptionally talented engineers often just want to keep their heads down, write clean RTL, eliminate every bug, and deliver flawless designs—such as an engineer taking immense personal pride in quietly shipping their eighth-generation memory controller without errors.

Because conscientious engineers are overwhelmingly introverted, they rarely promote themselves. Keller reflects on his own transformation, noting that he had to consciously adopt extroverted behaviors if he wanted the scope and resources to build truly massive computing projects: “I decided I wanted to build bigger projects and to do that you have to pretend to be an extrovert and you have to promote yourself.” He explains that senior decision-makers rarely take the time to audit technical code to find the most capable architect; they simply defer to whoever is the most visible, confident, and talked about. For an engineer aiming to rise above a principal engineer title into director-level management and executive ranks, learning the political and psychological dynamics of the corporate ecosystem is mandatory. Keller recommends studying foundational texts on human nature and power politics—such as William Shakespeare, Carl Jung, and Niccolò Machiavelli—to understand how that stratum of an organization actually operates. As the conversation wraps, Ian transitions toward Keller's perspective on the rivalry between industry titans like Intel, AMD, and Apple.

[01:20:04](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4804s) Intel vs AMD vs Apple: Corporate Cultures and Public Interfaces

Jim reflects on having worked across many major semiconductor companies, noting that he genuinely enjoyed his time at all of them. Today, his focus is drawn toward the emerging wave of AI startups and the broader revolution taking place in computing architectures. At the corporate level, companies driven by stock prices and boards will naturally fight their market battles, but Jim emphasizes that his personal connection remains with the engineers who do the actual work.

```mermaid flowchart TD accTitle: Tech Giants Operating Models Comparison accDescr: Contrasts Apple's insular consumer-box model with Intel and AMD's open component-ecosystem approach.

subgraph Apple["Apple: Vertically Integrated & Insular"] A1["Consumer Touchpoint: Aluminum / Glass Box"] A2["Operates like a 'Secret Society'"] A3["Great engineers, but isolated from wider technical world"] end

subgraph ComponentMakers["Intel & AMD: Open Component Ecosystem"] B1["Sell foundational components across diverse products"] B2["Tangible public engineering touchpoint (PCIe lanes, perf, bugs)"] B3["Directly impact broad developer and enthusiast communities"] end ```

When comparing corporate cultures, Jim contrasts Apple's approach with that of Intel and AMD. Apple maintains a notoriously insular posture toward the rest of the industry, presenting its work to users through sleek aluminum or glass enclosures. Jim observes that while Apple's engineers are exceptionally talented, their internal secrecy cuts them off from wider participation in the broader technical community. By contrast, Intel and AMD operate as component suppliers whose products power a vast spectrum of devices built by other companies. As a result, the engineering work done at Intel and AMD interfaces with the outside world far more directly; engineers and enthusiasts engage closely with tangible metrics such as architectural performance, PCIe lane configurations, and errata.

> “Intel and AMD sell components that go into many people's products so their interface to the public is more, you know, tangible in terms of the what the engineers do.” — Jim Keller

---

[01:21:40](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4900s) AI-Driven Chip Design and the Evolution of Unfathomable Systems

Ian asks whether electronic design automation (EDA) tools and emerging AI techniques will eventually design complex, multi-million-transistor microprocessors that are entirely unfathomable to human engineers. Jim points out that contemporary cutting-edge microprocessors from AMD, Intel, and Apple are already so complex that no single human can comprehend every detail. Nevertheless, an engineer can still inspect individual register-transfer level (RTL) code or standard cell libraries and deduce their function. Trained neural networks represent a completely different paradigm: when looking at a trained weight such as `0.0015843`, a human cannot simply explain why that precise value produces the correct outcome.

To illustrate this transition in human understanding, Jim references how the philosophy of science has evolved over history, drawing directly on concepts highlighted by Stephen Wolfram:

| Epoch | Scientific Paradigm | Nature of Understanding | |:--- |:--- |:--- | | **Classical Antiquity** | Physics by Explanation (Aristotle) | Qualitative narrative descriptions of nature (often fundamentally wrong). | | **Scientific Revolution** | Physics by Equation (Newton, Copernicus) | Elegant, intelligible mathematical formulas modeling observable phenomena. | | **Algorithmic Era** | Physics by Program (Wolfram) | Complex algorithmic systems that cannot be collapsed into single concise formulas. | | **Modern AI Era** | Physics / Design by Machine Learning | Empirical black boxes whose internal parameters lack intelligible human equations. |

Jim explores the cascading implications for future chip design. Today, AI networks are trained using small computing engines delivering several teraflops. If AI systems design future microprocessors, human engineers might inspect the resulting circuit and fail to comprehend not just the weights, but the underlying arithmetic representations and physical layouts. In that world, engineers will operate at even higher abstraction layers, designing the overarching human experience while leaving the microscopic implementations to black-box machine models.

> “Physics, there was physics by explanation, that was Aristotle, you know, 1,500 years, right? He was wrong about a whole bunch of stuff. And then there was physics by equation, like Newton, Copernicus, you know, people like that. And he says, you know, Stephen Wolfram said, now there's going to be physics by program, right? There's very few programs that are you can write in one equation, programs are complicated. And he says, why isn't physics like that? Well, you know, in computing world now we have program by AI, which has no intelligible equations in it or statements, so why isn't physics going to do the same thing?” — Jim Keller

---

[01:26:14](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5174s) Hardware Security: Side-Channel Attacks and Software Fallibility

Addressing the surge in microarchitectural side-channel vulnerabilities, Ian asks whether Jim adopts a proactive or reactive stance toward hardware security. Jim clarifies that market demand dictates design priorities, noting that true security is only prioritized when stakeholders actively care about protecting specific assets. Historically, operating systems relied on virtual memory boundaries to separate processes, but system software inevitably grew so tangled that attackers could trick the supervisor code into bypassing those safeguards.

```mermaid flowchart LR accTitle: Hardware vs Software Security Boundaries accDescr: Progression from fragile software-only verification to strict hardware isolation boundaries.

subgraph SW["Software-Enforced Boundaries"] S1["Virtual Memory & OS Isolation"] S2["Software grows in complexity"] S3["Vulnerabilities & gaps introduced"] S1 --> S2 --> S3 end

subgraph HW["Hardware-Enforced Boundaries"] H1["Strict Hardware Memory Isolation"] H2["OS cannot inspect user data"] H3["Immutable physical air-gaps"] end

S3 -.->|"Requires migration to"| HW ```

Jim places little confidence in purely software-based security, remarking that complex code continually violates its own foundational premises over time. The hardware overhead required to implement secure boundaries is generally modest; the real challenge lies in designing clear threat models. While global digital security often relies de facto on security through obscurity—most individuals are simply not high-value targets among billions—robust compute systems require hard hardware isolation barriers where even the host operating system cannot inspect protected user data. Beyond silicon-level protections, the highest tiers of operational security continue to rely on physical air-gapping and physical guards.

> “Every once in a while somebody will say something like, ‘Well, this is secure because the software does X,’ and I always think, ‘Yeah, just wait 10 minutes and the software will get more complicated, which will introduce a gap in it.’” — Jim Keller

- **Nature of Side-Channel Patches:** Most discovered microarchitectural side-channel leaks turned out to be relatively straightforward to mitigate in hardware once identified. - **Architectural Shift:** Emerging system architectures prioritize mutual distrust, enforcing hardware boundaries where the hypervisor or OS is explicitly barred from viewing workload contents. - **Physical Isolation:** Ultimate compute security remains air-gapped infrastructure protected by firewalls, physical perimeter defenses, and armed guards.

---

[01:29:09](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5349s) The Ethics of General-Purpose Computing

Ian asks whether Jim weighs the ethical ramifications and potential downstream misuses of the silicon he creates, comparing purpose-built automotive silicon like Tesla's autonomous driving chips to general-purpose microprocessors sold widely across global industries.

Jim responds that general-purpose computing is inherently agnostic: once an architecture is released into the world, it can be applied toward virtually any task. Because designers cannot control every end use, evaluating the ethics of building silicon comes down to weighing aggregate outcomes. In Jim's assessment, the broad societal net positive created by expanding computational power substantially outweighs the inevitable negative misuses.

> “The funny thing about general-purpose computing is it can really be used for anything. And so the ethics is more a net good better than the net bad, and you know, for the most part I think the net good is better than the possible downsides.” — Jim Keller

[01:29:53](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5393s) Ethics of AI and Decentralized Compute

Jim Keller addresses the growing societal anxiety surrounding artificial intelligence ethics, acknowledging that algorithmic capabilities have evolved far faster than human philosophical frameworks. Current systems already exhibit a startling ability to parse what individuals think, desire, and do, leaving the ethics debate trailing behind. Keller explains that one of his core motivations for engineering lower-cost, highly programmable AI silicon—and engaging with an extensive roster of AI software startups—is to ensure AI computing resources are broadly distributed rather than monopolized. In his view, putting hardware into many hands creates a protective equilibrium rather than an entrenched monopoly:

> “And the question is you know how many people have it have that and one reason to build let's say you know lower cost AI and programmable AI is you know I hope and we're talking to quite a large number of AI software startups that you know AI hardware and computing is in more people's hands because then you have a little mutual standoff situation as opposed to one winner take all but you know the modern tech world this has been sort of a winners take all but there's actually you know literally several dozen very large companies that have you know let's say competitive relationship with each other so that's kind of complicated so I think about it some.”

Keller concludes that while he does not claim to have definitive solutions to the ethical dilemma, technological advances have historically yielded net-positive results for society, and broadening access to powerful compute remains the safest path forward.

[01:31:27](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5487s) Elon Musk, Neuralink, and the Psychology of Cryptocurrency

Ian Cutress shifts the conversation to Keller’s history of working alongside prominent figures like Steve Jobs and Elon Musk. Ian notes Keller's appearance alongside Lex Fridman at a Neuralink demonstration the prior year, asking about his relationship with Musk and Musk’s vocal advocacy for cryptocurrency. Keller clarifies that he attended the Neuralink event because he was invited by members of their development engineering team whom he knew, emphasizing that his relationship with Musk was purely professional during his tenure at Tesla rather than personal, and that they have not spoken recently.

When asked about the computational demands of cryptocurrency—especially pouring energy into an asset without obvious intrinsic utility—Keller expresses indifference toward crypto mechanics, instead framing it as a fascinating manifestation of human group psychology:

> “I mean humans are really weird where they can put value in something like gold or money or cryptocurrency and you know that's a shared belief contract and what it's based on the best I can tell hasn't mattered much.”

For Keller, shared belief contracts are the actual driving force behind currencies, political movements, technology adoption, corporate cultures, and personal philosophy: - Without a coherent shared group belief, engineering teams cannot build complex systems or get anything done. - Crypto enthusiasts prize the perception that the currency operates outside central government control, though Keller remains agnostic on whether that is true. - He views cryptocurrency not as a fundamental technological revolution, but as a symptom and arbitrary case study of how powerfully human group beliefs shape reality.

[01:33:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5627s) Computing Beyond Silicon: Biology, Optics, and Quantum

Looking beyond the 50-year reign of silicon microprocessors, Ian asks whether Keller contemplates what happens when the industry inevitably encounters theoretical physics limits. Keller traces the long technological arc of computing devices to illustrate how humanity continually leaps paradigms when old substrates exhaust their potential:

```mermaid flowchart LR accTitle: Evolution of Computing Substrates accDescr: A sequence tracing computing technologies from historical mechanical systems to potential future biological and quantum architectures.

subgraph Historical["Historical Eras"] direction LR A["Abacuses"] --> B["Mechanical Relays"] B --> C["Vacuum Tubes"] end

subgraph SolidState["Solid-State Silicon"] direction LR D["Discrete Transistors"] --> E["Integrated Circuits"] E --> F["Modern Multi-Gate FETs"] end

subgraph Frontier["Future Frontiers"] direction LR G["Optical Switching"] H["Biological Assembly"] I["Neutral-Atom Quantum"] end

Historical --> SolidState SolidState --> Frontier ```

Keller points to several emerging domains that could supplement or replace traditional semiconductor approaches: - **Silicon Photonics and Optics:** Keller observes that researchers routing light through polysilicon to perform optical switching have been making real, tangible strides, even if the field has famously been regarded as “ten years away for twenty years.” - **Biological Economics:** Keller highlights biology's staggering thermodynamic and capital efficiency compared to semiconductor fabrication plants:

> “The economics of biology it's like 100 million times cheaper to make a complicated molecule than it is to make a transistor like that the economics are amazing like once you have something that can recon replicate proteins like I know a company that makes proteins for a living and we did the math and it was literally a hundred million times less capital per molecule than we spend on transistors.”

- **Self-Assembly vs. Lithography:** While planar lithography prints transistors into exceptionally sophisticated, rigid arrays, biological organisms assemble complex proteins organically. Echoing Richard Feynman's famous adage that “there's plenty of room at the bottom,” Keller sees massive untapped opportunity in guiding chemical organization. - **Quantum Systems:** Keller recalls speaking with founders of a neutral-atom quantum computing startup who used optical laser arrays to cool atoms and trap them into rigid two-dimensional grids. - **AI-Guided Atomic Engineering:** Keller suggests that mastering the next level of physical architectures may require modern AI computation itself to discover and direct the precise arrangement of atoms.

The interview concludes on a warm note as Cutress thanks Keller for his extensive time, noting he still had 20 questions left on his list, and wishes Keller success in his role as CTO of Tenstorrent.

## Notable quotes > [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) You'd be better off reading Carl Jung than Good to Great if you want to understand management. — Jim Keller

> [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Eighty percent of the execution is like six instructions: load, store, add, subtract, compare, and branch. — Jim Keller

> [47:45](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2865s) And teams that trust each other are way more effective than ones that have to do everything with contracts, negotiation, and politics. — Jim Keller

> [49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) You learn fastest when you're doing something new working for somebody that knows way more than you. — Jim Keller

> [01:08:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4132s) The best way to have status is to do something great and everybody thinks you're great; having status by trying to claw your way up is terrible because everybody thinks you're a climber. — Jim Keller

> [01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) I decided I wanted to build bigger projects and to do that you have to pretend to be an extrovert and you have to promote yourself. — Jim Keller

## Mentioned Alpha, AMD, AMD64, Apple, Applied Materials, Aristotle, Arm, ASML, Athlon, Autopilot, Becky Loop, Bob Stewart, Bob Swan, Broadcom, Bulldozer, Butler Lampson, Carl Jung, Carl Sagan, Chuck Thacker, Debjit Das Sarma, Digital Equipment Corporation (DEC), Doris Lessing, Elon Musk, Excavator, Full Self-Driving (FSD), Good to Great, Gordon Bell, Harry Fair, Hardware 3, Hurricane, HyperTransport, Ian Cutress, Intel, Isaac Newton, Jaguar, Jay Fleischman, Jim Keller, John Barth, John Updike, K12, K7, K8, Ken Olsen, Leslie Barnes, Lex Fridman, Ljubisa Bajic, Mark Papermaster, Mentor Graphics, Mike Clark, Moore's Law, MOS 6502, Motorola 6800, Nancy Kronenberg, Neuralink, Niccolò Machiavelli, Nicolaus Copernicus, Nvidia, Opteron, P.A. Semi, Pat Gelsinger, PDP-11/44, PDP-11/70, PowerPC, Raja Koduri, Ribbonfarm, Richard Feynman, RISC-V, Samsung, SiByte, Stephen Wolfram, Steve Hale, Steve Jobs, Suzanne Plummer, Tensix, Tenstorrent, Tesla, Thumb, TSMC, Valid Logic Systems, VAX 8800, VAX-11/780, Venkatesh Rao, William Shakespeare, x86, Zen, Zen 2, Zen 3

## Video description Was Jim Keller really 'the father of Zen'? In this wide-reaching interview, Jim talks to Ian about his time at AMD, Intel, and others, along with a variety of management technique advice, how to approach design, the future of Moore's Law, which instruction set matters (x86 vs Arm), but also the intersection between maturity and experience.

Written version of the interview is on AnandTech https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla

Jim Keller is currently CTO of Tenstorrent, a 2016 AI startup that recently secured $200m of Series C funding to go build their 4th/5th generation processors. I recently interviewed CTO Jim and CEO Ljubisa about Tenstorrent as well as the relationship between the two, which comes back to their time at AMD together.

https://www.youtube.com/watch?v=sMvudTBBQNw

0:00 Interview Part 2 0:32 Q1: What Jim Did at AMD 5:16 Q2: Father of Zen? 7:16 Q3: Everything from AMD is out? 8:41 Q4: Zen 3 a rewrite? 9:52 Q5: Is Tenstorrent a Forever Home? 13:21 Q6: What Jim Did at Intel 15:57 Q7: Would Jim Go Back to Intel? 16:38 Q8: Has it ever got boring? 18:24 Q9: Do Engineers Need People Skills? 19:44 Q10: Arm vs x86 vs RISC-V Pt 1 23:42 Q11: The right compute point for AI 25:47 Q12: Adding Vectors to AI 26:48 Q13: Arm vs x86 vs RISC-V Pt 2 29:11 Q14: Too much bloat? 30:24 Q15: Would x86 ever die? 32:33 Q16: Abstraction Layers in Life 37:49 Q17: Is Jim Worried about Moore's Law? 41:55 Q18: Beyond EUV Lithography 44:00 Q19: How to build a team 47:45 Q20: Teams and Company Culture 49:37 Q21: Recommendation for Early Career 50:22 Q22: Jim's Mentors 54:37 Q23: Understanding People 56:05 Q24: Reading more than others 58:33 Q25: Passive Jim Keller bookclub 59:22 Q26: Making sure you absorb information 1:01:43 Q27: Managing time 1:03:44 Q28: Doing interviews, marketing, 'talk' 1:06:12 Q29: Jim's Superpower? Nature vs Nurture? 1:08:52 Q30: How To Mentor People 1:13:03 Q31: Proudest Moments 1:17:21 Q32: Silent Heroes and Self-Promotion 1:19:48 Q33: Intel vs AMD, Intel vs Apple 1:21:40 Q34: AI Enabling Chip Design 1:26:14 Q35: Proactive or Reactive Security 1:29:09 Q36: Ethics of Chips Built 1:31:27 Q37: Elon, Neuralink, Cryptocurrency 1:33:47 Q38: Going Beyond Silicon 1:37:00 Cat Tax

Welcome to the TechTechPotato (c) Dr. Ian Cutress Ramblings about things related to Technology from an analyst

Patreon helps support this channel: https://www.patreon.com/TechTechPotato Also available through Patreon is special 1-on-1 consulting for the financial services industry! Many thanks to our CPU CEO Patrons

Support the channel by hitting that subscribe button, or using our Amazon affiliate link. Please note that TTP may receive a commission if you purchase anything through these links

Intel Core i7-11700K (8C/16T): https://geni.us/SreZM Intel Core i5-11600K (6C/12T): https://geni.us/T4WG Intel Core i5-11400F (6C/12T): https://geni.us/6UISblx

AMD Ryzen 9 5950X (16C/32T): https://geni.us/5950X AMD Ryzen 9 5900X (12C/24T): https://geni.us/5900X AMD Ryzen 7 5800X (8C/16T): https://geni.us/5800X AMD Ryzen 5 5600X (6C/12T): https://geni.us/5600X

Intel Core i9-10900K (10C/20T): https://geni.us/Bench2020-10900k Intel Core i7-10700K (8C/16T): https://geni.us/Bench2020-10700K

AMD Ryzen 9 3950X (16C/32T): https://geni.us/Bench2020-3950x AMD Ryzen 7 3700X (8C/16T): https://geni.us/Bench2020-3700x AMD Ryzen 5 3600 (6C/12T): https://geni.us/d08ThJ4

Follow Ian on Twitter at http://twitter.com/IanCutress Follow TechTechPotato on Twitter at http://twitter.com/TechTechPotato

#techtechpotato #jimkeller #ianinterviews

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

中文简报

吉姆·凯勒拒绝x86霸权,力挺RISC-V用于AI计算 凯勒认为,与物理数据流结构相比,指令集架构带来的效率差异微不足道,并指出随着AI工作负载的扩大,像RISC-V和模块化矩阵单元这样的简化设计将超越传统处理器。 在这场深入对话中,吉姆·凯勒淡化了自己作为“Zen之父”的名声,强调AMD的逆风翻盘主要归功于分布式协作、资深内部工程师以及组织上的从头彻底重置。他深入分析了为什么x86、Arm和RISC-V之间的指令集差异,远不如执行可预测性和内存瓶颈重要,并认为现代计算正在分裂为CPU、GPU和空间AI硬件。结合在DEC、苹果、特斯拉和英特尔数十年的领导经验,凯勒分享了自己如何通过为合适的人匹配合适的问题、剔除搞办公室政治的人以及利用潜意识解决问题来扩展组织。他依然看好摩尔定律,并探讨了未来计算将如何超越传统平面硅片,走向光子学、生物组装以及由AI设计的黑盒处理器。 吉姆·凯勒认为,指令集架构(ISA)对处理器峰值性能的影响极小,因为六条基本指令就占据了80%的执行量,而次优的编码最多只会带来10%到20%的效率损失。 (19:44) 摩尔定律受制于设备制造商与晶圆厂之间的组织脱节,而非硬性物理限制;在关键维度上,大约十个原子的半导体结在理论上仍能正常工作。 (37:49) 受分支预测、内存延迟和稠密矩阵图执行等巨大差异需求的驱动,现代计算已分化为三大不同类别:CPU、GPU和专用AI处理器。 (21:44) 在挽救表现不佳的芯片工程团队时,凯勒主张重组现有的内部人才,而不是引入外部团队;他指出AMD Zen核心的逆转主要就是由公司老将完成的。 (44:00)

Detailed notes — zh

## Background 本内容由科技分析师 Ian Cutress 博士于 2021 年 6 月 21 日在 YouTube 频道 TechTechPotato 发布。视频简介表明这是一场针对传奇芯片架构师 Jim Keller 的深度长篇专访,探讨了他是否真的是“Zen 之父”、在 AMD 与 Intel 的真实工作、管理哲学、摩尔定律的未来、指令集(x86、Arm、RISC-V)竞争以及心智成熟与工程经验的交汇点。 ## TL;DR 在长达一个半小时的访谈中,Jim Keller 详细还原了他在 DEC、AMD、Apple、Tesla、Intel 的关键经历,澄清了外界对其“Zen 之父”以及频繁跳槽的误解,强调大工程突破依赖于严整的抽象层划分而非个人英雄主义。他击碎了指令集架构的神话,指出现代计算的核心瓶颈在于分支可预测性,并阐释了 Tenstorrent 所倡导的空间图计算哲学。此外,Keller 坚信摩尔定律依然活着,并跨界分享了如何运用莎士比亚与心理学化解工程团队内耗、激发组织潜能的管理心法,最后展望了 AI 辅助造芯、硬件安全本质以及超越硅基的生物与量子计算前景。 ## Atmosphere & style 整场对话充满技术极客间的惺惺相惜与举重若轻的幽默感,节奏张弛有度、知无不言。Jim Keller 毫无行业大佬的高傲架子,神态放松,时而自嘲天生患有阅读障碍或调侃自己是特斯拉“最懒员工”,时而以极具穿透力的哲学视角洞察工程本质。观众在聆听时不仅能感受到几十年来半导体史诗级战役的厚重底蕴,更能体会到一种将硬核工程、人性洞察与纯粹直觉融会贯通后的从容与豁达。 ## Bulletin - [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) Jim Keller 击碎了指令集架构(ISA)神话,指出 80% 的真实计算负载仅由 Load、Store、Add、Subtract、Compare 和 Branch 这 6 条核心指令构成,现代处理器性能的真正上限在于可预测性而非指令集本身。 - [37:49](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2269s) 面对摩尔定律走向终结的悲观论调,Keller 强调物理底层探索空间依然巨大,构建非量子效应干扰的可用结型仅需约 10 个原子,行业延误多源于设备制造与工艺集成匹配,而非物理学铁律。 - [23:42](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1422s) 在芯片架构演进上,Tenstorrent 押注空间图计算与大约 4 TOPS 的中等计算核心,以此避免整芯片单体超大矩阵乘法器带来的灾难级走线功耗与跨核能耗开销。 - [01:33:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5627s) 未来的前沿计算正探索硅基之外的路径;Keller 指出复制复杂生物分子的成本比光刻制造晶体管低整整 1 亿倍,生物分子的自组织能力为终极算力突破提供了全新视角。 ## Key takeaways - [01:20](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=80s) 重振 AMD 的核心策略是颠覆路径依赖,将传统的“证明新方案好才用”逆转为“必须证明旧模块足够好否则全部重做”,并为未来五年确立坚实的架构骨架。 - [05:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=316s) Zen 架构并非某一个人的单独神话,Keller 拒绝独揽“Zen 之父”名号,其成功源自奥斯汀、科罗拉多、桑尼维尔及波士顿等跨地域团队的密切工程协同与模块重构。 - [13:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=801s) 在英特尔管理一万人团队期间,Keller 的核心工作是推动设计方法学变革,促使英特尔从传统的全单体芯片设计转向行业通行的现代化 SoC IP 模块化搭积木架构。 - [18:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1104s) 人类大脑的有效社交带宽上限从未提升,因此驾驭亿级门电路复杂度的唯一出路在于严格构建抽象层与接口合约,而非逼迫工程师跨领域沟通。 - [21:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1304s) CPU、GPU 与专用 AI 芯片的算力范式存在根本分歧:CPU 依赖强大的分支预测器应对复杂控制流,GPU 依靠数千并发线程搬运细粒度着色任务,而专用 AI 芯片则专注于高维张量和空间图计算。 - [26:48](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1608s) 指令集具备膨胀宿命周期:x86 与 Arm 因漫长的向后兼容背负了沉重的历史包袱,而学术界推导出的 RISC-V 剥离了历史冗余,成为目前快速打造高性能处理器的最轻盈选择。 - [31:46](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1906s) 工程设计中打破抽象层拉飞线是极其危险的技术妥协,每一次违背接口抽象层边界都会为未来的系统迭代埋下灾难性的技术债务。 - [37:49](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2269s) 半导体产业的核心创新重镇正向上游转移,ASML 与应用材料等设备制造商的突破对先进制程演进的推动作用,甚至大于晶圆代工厂本身。 - [44:01](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2641s) 团队管理的本质是“发掘”而非强行“组建”,成熟大企业内部往往本就埋藏着优秀人才,领导者的核心职责如同米开朗基罗雕刻大理石般剔除多余阻碍并重新部署人员。 - [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) 广泛的多学科阅读对工程管理具有极高价值,莎士比亚、马基雅维利以及荣格的著作所揭示的人性本质,在现代企业政治与团队协作中每天都在重复上演。 - [01:11:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4266s) 真正的技术指导往往需要围绕具体宏大的工程使命展开,管理攻坚中工程师遇到的阻碍四分之三源于个人与心理层面,化解这些障碍往往比单纯纠结技术细节更重要。 - [01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) 技术专家如果渴望主导更大规模的工程项目,就必须主动走出内向舒适区,学会展示和推销自己,以适应更高层级的资源配置与组织运行逻辑。 - [01:21:40](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4900s) 未来由 AI 辅助或自主设计的芯片正在走向人类不可直观解译的“黑盒”阶段,人类工程师将逐步从解读底层 RTL 和标准单元库,跃迁至更高阶的目标定义抽象层。 - [01:26:14](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5174s) 纯软件构建的安全边界终将因代码无限膨胀而失效,建立在底层硅片物理隔离与断网隔离之上的硬件防护,才是化解侧信道等复杂攻击的最有效途径。 - [01:29:53](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5393s) 货币与加密资产的价值底层源自人类的“共同信念契约”,应对 AI 算力垄断风险的最佳方案则是普及低成本可编程硬件以实现技术民主化制衡。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=0s) 开场:回溯 Jim Keller 的传奇履历与二进 AMD 主持人 Ian Cutress 博士介绍了本次采访的嘉宾——传奇芯片架构师 Jim Keller。Jim Keller 当时担任人工智能初创公司 Tenstorrent 的首席技术官(CTO),在此之前曾先后在 DEC、Apple、AMD、Intel、Broadcom、SiByte 以及 Tesla 任职。当 Ian 询问是否有遗漏时,Keller 笑着补充了一句极为关键的经历:“我其实在 AMD 工作过两次(I worked at AMD twice)。” 对话由此切入 Keller 第二次重返 AMD 时的核心阶段。当时 AMD 凭借 Zen 架构和后续产品逐步收复失地、抢占市场份额,而大众普遍将 Zen、SkyBridge 平台的突破归功于他。然而,外界对于他在这一系列项目中的具体分工一直众说纷纭:一部分人认为他深度主导了 Zen、Zen 2、Zen 3 的高层微架构设计;另一部分人则认为他主要负责高层组织架构搭建与签字批准,实际研发精力主要放在了基于 Arm 架构的 SkyBridge 和 K12 项目上,同时兼顾 Infinity Fabric 总线等关键基础技术的推动。面对这些疑问,Keller 详细梳理了当时 AMD 内部真实的技术与管理格局。 ### [01:20](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=80s) 力挽狂澜:执掌 AMD 研发团队与彻底革新的技术哲学 Keller 回忆,在他重返 AMD 时,公司的处理器主力是 Bulldozer(推土机)和 Jaguar(美洲豹)。这两套架构虽然各自具备一些“迷人的特性(charming features)”,但商业表现非常惨淡,产品路线图也缺乏进取心,导致 AMD 正在被竞争对手 Intel 越拉越远。Keller 强调,对于落后者而言,如果无法加速追赶反而在继续掉队,后果将是致命的。 为了打破僵局,Keller 出任 AMD CPU 团队的副总裁。刚入职时团队大约有 500 人,而在随后的三年内,SoC 团队、Fabric(总线互连)团队以及多个 IP 团队陆续划归他的管理管辖之下,团队规模迅速膨胀至 2,400 到 2,500 人。虽然他直接管理着由十余位资深总监(Senior Directors)与资深研究员(Senior Fellows)组成的核心管理层,但他明确表示自己本质上依然是一名计算机架构师,而非纯粹的职业经理人: > “我是一名计算机架构师,其实并不算真正意义上的管理者。(I'm a computer architect, not really a manager.)” 之所以主动争取这个当时自己职业生涯中最大的管理职位,是因为 Keller 深刻认识到:如果只作为一个在旁边提建议的纯架构师,就不可避免地要日复一日地跟主管副总裁争论某人是否胜任、某项技术决策是否正确;唯有掌握直接的组织与决策权,才能推动大刀阔斧的底层变革。他向当时 AMD 的首席技术官 Mark Papermaster 阐述了自己的这一管理构想,并获得了全力支持。 不过 Keller 也指出,仅靠行政权力发号施令无法解决问题,工程师只有被愿景所激励才能全力以赴。当时团队普遍存在严重的路径依赖,许多人受制于上一次设计的惯性,认为很多旧规则不可动摇。而 Keller 进驻 AMD 时采取的核心预设极其激进: > “我的看法是,当时的情况已经糟糕到几乎所有的东西都必须彻底改变。(My view was things were so bad that almost everything had to change.)” 在这种思维指导下,团队的技术论证逻辑被彻底倒转:过去团队倾向于要求“证明新方案足够优秀才采用”,而 Keller 则立下规矩——任何人必须先证明“旧模块足够好”,否则一律推倒重做。他在技术大方向上有着清晰的蓝图,并迅速与公司内 Mike Clark、Leslie Barnes、Jay Fleischman、Debjit 等一大批顶尖工程师达成共识,共同推动了 Zen 微架构、Arm 内核分支(K12)、二者融合的后续演化方案、全新 SoC 设计方法学以及底层的 IP 重构。 ```mermaid flowchart TD accTitle: Jim Keller 在 AMD 的管理与技术推进架构 accDescr: 展示 Keller 统领 2500 人团队并推动设计方法学、微架构与跨地域协同的流向图。 subgraph MGMT["组织管理与理念重塑"] A["顶层领导<br/>Jim Keller 与 15 人高管/Fellow 团队"] B["颠覆路径依赖<br/>默认推翻旧设计:需证明旧模块可用"] end subgraph SITES["跨地域研发协同分布"] C1["Austin & India<br/>SoC 团队与前端核心执行"] C2["Colorado<br/>浮点运算 (FP) 与高速缓存 (Cache)"] C3["Sunnyvale<br/>Arm (K12) 前端设计"] C4["Boston<br/>Excavator 收尾与物理实现"] end subgraph PROJS["技术演进落地"] D1["Zen 架构 (x86)<br/>大骨架基础结构"] D2["K12 / SkyBridge (Arm)"] D3["SoC 15 & Infinity Fabric<br/>互连总线规范"] end A --> B B --> SITES SITES --> PROJS ``` ### [05:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=316s) “Zen 之父”的称谓与跨地域研发协作的真相 谈及行业内广泛将他冠以“Zen 之父(Father of Zen)”的称号,Keller 幽默地反问自己是不是更像“叔叔之一(one of the uncles)”。他明确拒绝将 Zen 的巨大成就归为自己一人独揽,并引用格言指出:“成功有成千上万个创造者,而失败往往只有一个替罪羊(Success has a lot of authors, failure has one)。” Zen 的诞生背后是一场高难度的全球协同战役: - 方法学(Methodology)团队遍布全球; - SoC 研发由奥斯汀(Austin)与印度两地协同推进; - 浮点运算单元(Floating Point)与高速缓存(Cache)架构由科罗拉多(Colorado)团队打造; - 核心执行单元与前端由奥斯汀团队负责; - Arm 核心的前端研发则设在加州桑尼维尔(Sunnyvale)。 Keller 当时每日与负责核心前端的 Suzanne、Steve Hale 以及科罗拉多团队紧密沟通,并对主架构师 Mike Clark 的高超水平给予了极高评价。在研发中途,为了给 Zen 项目腾挪核心精力,管理层进行了高度承压的组织变阵,将挖掘机架构(Excavator)的设计收尾与物理实现工作整体移交给了波士顿的 Harry Fair 团队。Keller 总结道,自己在这段历程中扮演的角色是“煽动者(instigator)、首席催化剂(chief nudge)、部分架构师以及变革型领导者”,这不仅是一次技术的跨越,更是一场充满深厚革命情谊的团队合力作战。 ### [07:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=436s) 从 Zen 1 到 Zen 3:长线架构骨架与代码复用实情 针对外界关心的“当前 AMD 产品线是否仍受其当时工作影响”这一问题,Keller 详细解释了处理器迭代的长期规律。当团队设计一款全新的计算机体系(如 Zen)并配套打造名为“SoC 15”的互联总线标准时,本质上是在规划一张覆盖未来五年的产品路线图: > “当你让一台计算机变得更快时,只有两种途径:要么让基础骨架变得更大,要么微调特性。(When you make a computer faster, there's two ways to do it: you make the fundamental structure bigger, or you tweak features.)” Keller 指出,当年团队在 Apple 设计首个自研大核心时同样采用了打造“一副强健骨架(big bones)”的策略。Zen 在确立了极其扎实的底层基础骨架之后,后续数代产品只需在此基础上按部就班地进行特性扩展与性能优化。 对于业界盛传“Zen 3 属于推倒重写(Rewrite)”的说法,Keller 从硬件工程的底层实际进行了解析:即使在 Zen 1 构想之初确立了从零起步的纯净高层架构,底层的具体 RTL 代码实现依然吸纳了大量来自 Bulldozer 和 Jaguar 的既有可用模块,经过调整后嵌合进新的骨架中。硬件工程师极擅长在合适场景下复用成熟代码。因此,外界所谓的“重写”,在实际代码层面通常仍有 20% 到 80% 是继承或微调自上一代成果。业界所说的微架构大改或重写,真正的本质是纠正和重构了顶层的组织结构,而非将数以百万计的底层代码逐行全部重写。 ### [09:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=592s) 职业生涯轨迹:Tenstorrent 会是最终归宿吗? 采访话题随后转向 Keller 频频变动雇主的职业生涯。如今他与 AMD 时期的老友 Ljubisa Bajic 在 AI 芯片公司 Tenstorrent 共事,Ian 抛出了一个单刀直入的问题:频繁辗转于各大巨头与初创公司寻找新挑战的 Jim Keller,是否会将 Tenstorrent 视为自己职业生涯的“终身归宿(forever home)”? Keller 并没有直接给出非黑即白的结论,而是回顾了自己漫长而多维度的职业生涯。他首先澄清,自己并非一开始就是频繁跳槽的“流浪工程师”——他在 DEC(数字设备公司)整整工作了 15 年。在 DEC 的这 15 年实际上相当于两段截然不同的职业生涯: - 前期在 DEC 中端计算组(Mid-range Group),使用 ECL(发射极耦合逻辑)器件打造如电冰箱般巨大的中型计算机系统; - 后期加入 Alpha 芯片团队,转向超大规模微处理器的研发。当时打造的 Alpha 处理器拥有在当年被视作不可思议的规格——300 平方毫米的巨大芯片面积以及 50 瓦的惊人功耗,给当时的行业带来了极大的技术震撼。 DEC 时代之后,正值互联网浪潮爆发的前夕,Keller 第一次加入 AMD。在那段旋风般的岁月里,他与团队在短短几年内开创性地主导了 HyperTransport 总线协议与双路服务器架构的设计,随即便卷入了半导体产业随后一轮又一轮的浪潮之中。 ### [11:04](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=664s) 职业生涯轨迹:从 PA Semi、Apple、Tesla 到 Tenstorrent Jim Keller 回顾了自己多年来在各大科技巨头之间的职业跳跃,澄清外界对自己“频繁跳槽”的印象。当年在互联网狂潮的带动下,他加入了初创公司 SiByte,该公司随后被 Broadcom 收购,他在那里一共工作了四年并推出了数代产品。随后他去了 PA Semi,团队打造出了一款优秀的产品,但公司出于某些考虑似乎并不急于对外销售,或是盘算着将整家公司卖给苹果(Apple)。于是 Jim Keller 索性直接跳槽去了苹果,不久后苹果果然整体收购了 PA Semi,两个团队重新汇合。在 PA Semi 和苹果的岁月加起来长达七年,因此他认为自己根本算不上频繁换坑。在这之后,他转战 AMD 度过了一段充满乐趣的时光,紧接着又加入特斯拉(Tesla),主导打造了 Hardware 3(全自动驾驶计算机)。 在特斯拉的经历被 Jim 称为不可思议的奇迹——团队从零起步,仅仅耗时 18 个月就做出了芯片并直接装入汽车上路实测,这种开发速度在半导体行业几乎前所未有。这项产品获得了巨大的商业成功,特斯拉在过去一年内就制造了上百万套该系统。至于随后的英特尔(Intel)之旅,则是一场完全不同节奏的“旋风式历险”。面对外界认为他“跳进跳出”的调侃,Jim 坦言自己在每家公司都玩得非常尽兴,而且绝大多数时候都能圆满达成最初设定的目标,交付出具备长远价值的产品。对于自己的定位,他有着极其清醒的自我认知:“我喜欢要么是一张白纸,要么是一场彻底的灾难。”(“I like either a clean piece of paper or a complete disaster,” said Jim.)他强调自己绝不是那种守着成熟产线进行细枝末节微调的运维型经理(operational manager)。如今他在 Tenstorrent 担任 CTO 兼总裁,既有巨大的经济利益绑定,也有对并肩作战的朋友们的深厚承诺。AI 赛道正处于大爆发阶段,这正是一张全新的“白纸”,他明确表示自己打算在这里长留。 - **SiByte / Broadcom**:任职 4 年,推出多代网络与处理器产品。 - **PA Semi 与 Apple**:两段经历无缝衔接,合计达 7 年。 - **Tesla Hardware 3**:从立项白纸到装车路测仅耗时 18 个月,2020 年产量突破 100 万套。 - **Tenstorrent 角色**:担任 CTO 兼总裁,属于长期战略投入而非短期过渡。 --- ### [13:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=801s) 在 Intel 的真实角色:万人团队、SoC IP 架构与方法学变革 当 Ian Cutress 问及他在英特尔受保密协议限制之下的真实工作内容,以及那究竟是一场“从零开始的再造”还是修补工作时,Jim 揭开了这家半导体巨擘内部工程管理的冰山一角。Jim 当时的正式职务是英特尔硅工程集团(Silicon Engineering Group)的高级副总裁,麾下管理着多达一万名工程师,直接下属清一色是副总裁(VP)与资深院士(Senior Fellow)。在任何一个时间节点上,团队内部都有 60 到 70 个 SoC 项目正处于不同的生命周期中——涵盖了从早期架构设计、原型制作、流片调试到最终规模量产的整个流程,组织规模极其庞大且异构。 Jim 坦言,他原本以为去英特尔是为了打造一堆前沿的新技术,但真正入职后才发现,绝大部分精力不得不放在推动整个组织的“方法学变革”(methodology transformation)上。在 Jim 加入的前两年,英特尔试图从历史悠久的“全单体式芯片设计”(monolithic view)转向行业通行的“SoC IP 积木式组装构架”(SoC IP view),但这一转型推进得极不顺利。英特尔直接把过去优秀的客户端和服务器单体芯片机械地切碎成各个小模块,但这种简单粗暴的拆分必然导致系统失调——拆分之后必须从底层重新构建这些 IP 模块以及与之配套的设计方法学。面对每天要赶多达 14 场会议的高压节奏,当被问及“开这么多会究竟如何做成实事”时,Jim 幽默地回答说,作为高管自己根本不负责具体执行,而是负责评估走势、校准大方向、做出关键研判,并通过组织和人事变动来确保团队知道往哪里走:“了解你要去哪里,然后建立一个懂得如何达成目标的组织,这是抵达终点的关键所在。”(“The key thing about getting somewhere is knowing where you're going and then put an organization in place that knows how to do that,” said Jim.)在那段日子里,他几乎没有敲过几行芯片代码,但发了无数条推动变革的短信。 ```mermaid flowchart TD accTitle: Intel Design Methodology Transformation accDescr: Diagram illustrating Jim Keller's efforts at Intel shifting from monolithic chip design to modern SoC IP methodology. subgraph Legacy["传统模式 (Legacy)"] A["单体架构设计 (Monolithic)"] --> B["机械式硬拆切片"] end subgraph Problem["转型困境 (Bottlenecks)"] B --> C["IP 质量与密度失衡"] B --> D["传统 CAD 工具与流程脱节"] end subgraph KellerDrive["方法学重构 (Jim Keller's Drive)"] C & D --> E["重构 SoC IP 底层设计"] E --> F["部署全新 CAD 工具链"] E --> G["统一 IP 库表征与工艺协同"] end ``` --- ### [15:57](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=957s) Pat Gelsinger 回归与半导体行业四十年不变的本质 关于英特尔换帅迎回具有深厚技术工程背景的 Pat Gelsinger、以及如果机会合适 Jim 是否愿意重返英特尔的问题,Jim 给出了坦率而克制的回答。他表示自己目前在 Tenstorrent 的工作极其充实,身处爆发式增长的前沿赛道,因此根本没有离开的打算。但他由衷地为英特尔感到高兴,认为董事会选择 Pat 是一个非常正确的决定。Pat 展现出了对英特尔的极度热爱与使命感,而且过去战绩斐然,必将为公司重新注入技术驱动的专注度;同时他也提到,自己此前与前任 CEO Bob Swan 的合作也相当愉快。 回顾自己横跨高性能计算(HPC)、低功耗嵌入式设备再到如今 AI 专用加速芯片的漫长职业生涯,Ian 好奇他是否曾对芯片设计感到厌倦。Jim 斩钉截铁地回答“绝不”。他指出,半导体这个领域看似每隔几年就天翻地覆,但在物理和逻辑底层却从未改变过分毫——无论技术名词怎么包装,计算机归根结底就是把数字 0 和 1 加在一起。然而,构建这些运算的基础单元规模却经历了翻天覆地的跃迁:早年他参与开发经典的 VAX 8800 小型机时,整块芯片是基于仅包含 200 个门电路(gates)的门阵列搭建起来的;而在如今 Tenstorrent 的芯片架构中,最基础的 Tensix 运算核心单核算力就高达每秒 4 万亿次操作(4 TOPS),一颗芯片上集成了整整 100 个这样的核心。 - **计算积木的演进对比**:从 VAX 8800 时期的单片 200 个门,跃迁至现代 AI 芯片单个核心 4 TOPS 算力、百核集成的超大规模。 - **抽象层驱动演进**:如果缺乏设计工具(CAD)的指数级进化和抽象层次的不断提升,人类根本不可能驾驭这种复杂度。 - **年轻与成熟的心态转变**:年轻时的 Jim 总以为必须凡事亲力亲为、像个疯子一样拼命通宵写代码;随着履历增长,他才领悟到如何通过组织协调、倾听他人与运用人际技巧来实现更大的技术突破。 --- ### [18:24](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1104s) 工程师的人际沟通极限与组织工具 随着芯片设计跨越工艺制程、软硬件协同、微架构等多个高度分离的抽象层,针对“现代工程师是否比过去更需要人际交往技巧”的疑问,Jim 提出了一个冷酷而发人深省的底层事实。他指出,人类大脑的生物学算力从古至今根本没有发生任何进化:“人并不会变得更聪明,所以指望人们能同时跨越更多领域去工作纯粹是痴人说梦。”(“People aren't getting any smarter, right? So people can't work across more things, that's just that's dumb,” said Jim.) 为了印证这一点,他对比了两个时代的工程团队规模。当年打造 VAX 8800 的设计团队大约有 150 名工程师;数十年后,苹果打造 Hurricane 核心(苹果早期自主设计的第二代大型定制 CPU 核心)时,核心架构团队同样只有 150 人左右。这几十年间,外部条件发生了剧变:现代团队拥有数以千计的高性能服务器集群进行并行逻辑仿真,自动化 EDA 工具可以轻松对 200 万门电路进行自动布局布线,而不再是早期的 200 个门。然而,单名工程师在日常工作中所能有效沟通的人际上限从未改变——如果强行要求一名工程师每天与超过 5 个人进行深度技术交流与协作,对方的大脑就会彻底崩溃。因此,半导体行业发展的精髓从不是逼迫工程师成为社交全才,而是必须开发出更强大的抽象工具并搭建起合理的组织架构,让人类在维持极低的人际沟通带宽下,依然能够协同构建起超越想象的庞大系统。 --- ### [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) 指令集神话的破灭:x86、Arm 与 RISC-V 的核心真相 在关于处理器指令集架构(ISA)的激烈论战——特别是 Arm、x86 与 RISC-V 的阵营之争中,Jim 给出了业内最具颠覆性的见解,直接击碎了外界对指令集的过度神化。当 Ian 求证他过去是否说过“大部分计算仅由几十条操作码完成,因此指令集根本无所谓”时,Jim 笑着纠正道,现实甚至比这个说法更加残酷:在现代真实的计算负载中,80% 的指令执行仅仅由区区 6 条基础指令构成: $$\text{核心基础指令} = \{\text{Load},\; \text{Store},\; \text{Add},\; \text{Subtract},\; \text{Compare},\; \text{Branch}\}$$ 即便是在运行 Perl 这类偏高级脚本语言的特定场景下,调用(Call)与返回(Return)的频率可能会略微凸显,但也完全无法改变底层基本盘。Jim 明确断言,指令集设计对处理器性能的影响其实微乎其微,即便某款指令集由于缺失某些特定指令而吃亏,性能差距顶多也就只有 10% 到 20%。过去芯片业界长期存在一个误区,认为 x86 这种变长指令集(variable-length instructions)在前端译码时难度极大,会成为无法克服的功耗与性能瓶颈;但事实证明,现代微架构工程师早已攻克了这一难关——业界通过在硬件中引入极为庞大高效的分支与指令位置预测表(predictors),就能极其精准地提前预判出每条指令的边界与位置。 Jim 进一步剖析了固定长度指令集(Fixed-length ISA)的心理错觉。定长指令在设计初学者玩具级的小型处理器时确实显得优雅且容易处理,但在设计当今现代高性能大核时,指令译码预测器所占用的芯片硅片面积已经微不足道,根本不可能对全局性能起到主导作用。在 RISC 架构诞生之初,当时的 x86 处理器芯片面积有三分之一甚至一半都被用于存储微代码的 ROM 所霸占,RISC 阵营理直气壮地宣扬自己完全不需要微码 ROM,因而能将宝贵的面积转化为运算性能。然而时至今日,得益于先进工艺制程的演进,微码 ROM 在芯片面积中的占比早已小到拿显微镜都难以发现,甚至连加法器(adder)都小到忽略不计。他总结道,真正决定当代计算机性能天花板的根本不是指令集的花样:“限制计算机性能的核心瓶颈在于可预测性。”(“What limits computer performance is predictability,” said Jim.)处理器能否在深层流水线中精准预测分支走向与数据流向,才是决胜性能的核心战场。 ### [21:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1304s) CPU、GPU 与专用 AI 引擎的本质分歧 谈及现代微架构的设计取向时,Jim Keller 指出,指令可预测性、分支预测能力以及数据局部性是 CPU 性能的核心支柱。现代的分支预测器性能极高,其硅片面积甚至远远超过了加法器本身。这正是 CPU 与 GPU 或专用 AI 引擎产生哲学分野的地方:GPU 阵营会宣称自己不需要分支预测器,因为其底层采用极大规模的并行架构,芯片面积几乎全被算术逻辑单元(加法器、乘法器)占据;但正如 Jim 所言:“如果那是你要面对的问题,这确实成立;但它们在运行 C 程序时就烂透了(they're crap at running C programs)。” GPU 本质上是为处理像素着色器(shader)程序而诞生的产物。面对屏幕上动辄 800 万个像素点,顶级 GPU 往往通过调度约 6,000 个并发线程来分摊负载,每个线程在单帧内执行数千条着色指令。Jim 用了一个生动的比喻来形容这种模式:GPU 就像“一支搬运沙粒的蚂蚁大军(an army of ants carrying around grains of sand)”,其面对的子任务规模天然极小且分布海量。相反,真正的超大规模 AI 计算机依靠极大的矩阵乘法单元和相对较少的线程数来处理吞吐,因为 AI 问题本身在维度上是极其庞大的。 因此,计算界存在三种泾渭分明的硬件范式:CPU、GPU 和专用 AI 芯片。NVIDIA 在其中扮演了某种折中或过渡角色(tweener),试图借由 GPU 架构来兼揽并增强 AI 工作负载,尽管成效显著,但硬件架构也变得异常繁复。这与历史上通用 CPU 看到 GPU 的向量优势后纷纷集成向量单元(如 AVX)如出一辙:当向量负载较轻时,CPU 的内置单元非常趁手;可一旦面对真正的密集型吞吐,专用硬件方案依然是更优解。 ```mermaid flowchart TD accTitle: 三种计算范式的架构与负载特征对比 accDescr: 展示CPU、GPU与专用AI芯片在核心瓶颈、执行特点及典型负载上的不同取向。 subgraph CPU["通用 CPU"] C1["强分支预测器 + 乱序调度"] --> C2["低线程数 / 极深流水线"] C2 --> C3["擅长:复杂控制流与 C 语言逻辑"] end subgraph GPU["图形 GPU"] G1["海量 ALU,几乎无预测器"] --> G2["数千并发线程 (蚂蚁大军)"] G2 --> G3["擅长:细粒度并行 (如像素着色)"] end subgraph AI["专用 AI 计算引擎"] A1["超大矩阵乘法单元"] --> A2["更少线程数,极高数据吞吐"] A3["图执行与空间数据流"] --> A2 A2 --> A4["擅长:高维张量与网络图运算"] end ``` ### [23:42](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1422s) 从标量到图计算:Tenstorrent 的空间计算哲学 数学计算单元随着晶体管预算的增长经历了持续演化。Jim 梳理了这段从极简到庞杂的历史路径:早期的晶体管只够实现最基础的标量运算(例如 $a = b + c \times d$);随后晶体管密度增加,硬件能够在一个时钟周期内向量化执行整个方程;再往后,整片硬件矩阵乘法器成为了可能。然而,无限制扩大矩阵单元会遭遇严重的物理瓶颈——横跨超大矩阵乘法器传输信号所消耗的功耗极高,导致整芯片单核架构变得得不偿失。 Tenstorrent 的设计理念在于寻找计算粒度的甜蜜点(sweet spot):构建阵列化、中等尺寸的处理核,既不像 GPU 线程那样过于微小,也不像单体超大矩阵那样带来灾难级的跨核能耗。在这个语境下,一个“中等核”的处理能力大约在 4 TOPS 左右,这让经历过早期计算时代的 Jim 感慨不已。当大算子被切碎并映射到芯片阵列上时,整个 AI 模型的本质便是一张巨大的计算图,大图被层层因式分解为子图,硬件核心通过片上网络进行高效的数据流调度。这种范式被称作图计算或空间计算(spatial compute)。 Tenstorrent 在下一代图计算核心中紧密集成了通用向量引擎。这是因为在真实的 AI 工作流中,算子图执行的间歇往往需要执行一段普通的 C 语言逻辑或轻量标量计算。如果将通用计算和图计算核心紧密耦合在同一片上系统(SoC),不仅访问延迟极低,芯片间往返搬运数据的功耗也能得到严格控制。 - 算力粒度演变:标量(Scalar) $\rightarrow$ 向量(Vector) $\rightarrow$ 矩阵(Matrix) $\rightarrow$ 空间图计算(Spatial/Graph)。 - 能耗权衡准则:整颗芯片只做一个超大矩阵乘法器是极其愚蠢的,片上走线传输功耗会吞噬所有能效收益。 - 异构协同价值:在 AI 加速图与通用 C 代码逻辑之间实现芯片级超低延迟协同,是计算机体系结构当下的前沿研究领域。 ### [26:48](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1608s) 指令集的膨胀周期:x86、Arm 到 RISC-V 的历史宿命 在对比主流 CPU 指令集架构(ISA)时,Jim Keller 直言自己对这场争论并非完全无所谓,而是看透了背后的演进周期。在 x86 诞生之初,它的架构非常简洁清晰,并在当时与 6800、6502 等 8 位处理器同台竞技。当年 Intel 出于商业模式需要将 x86 授权给多家公司,这一相对开放的策略让其生态迅速铺开。但随着历代演进,x86 陆续堆砌了 16 位、32 位、虚拟内存、虚拟化支持、硬件安全、64 位以及纷繁复杂的向量扩展,指令集不可避免地因向后兼容而背上了沉重的历史包袱。 同样的周期在 Arm 身上重演了一遍。Arm 最初以纯粹、清爽的 32 位 RISC 面世,相较于彼时臃肿的 x86 极具构建优势;但随着时间推移,Arm 先后引入了 16 位 Thumb 模式、极其糟糕的 IT(If-Then)条件指令、带有重叠寄存器堆的奇特浮点向量扩展,再到后来的 64 位转换和各类安全启动特权级,复杂度呈指数级上升。相比之下,RISC-V 如今充当了那个崭新的竞争者。它没有历史包袱,由学术界构思推导,没有商业利益集团塞入垃圾指令的恶习,正处于复杂度生命周期的早期红利阶段。 对于架构师而言,如果目标是快速且高效地造出一颗现代高性能处理器,RISC-V 无疑是最轻盈的选择。正如 Jim 所断言:“如果我现在要非常迅速地打造一台计算机,而且希望它跑得飞快,RISC-V 是最容易、也是最简单的一个架构(RISC-V is the easiest one, it's the simplest one)。”它精准涵盖了现代编译优化最核心的指令集子集,剥离了一切冗余的历史垃圾。 ### [29:11](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1751s) 复杂度诅咒与模块化解耦 任何经受长期迭代的指令集都会遭遇边际收益递减规律的惩罚。工程师在设计时往往陷入两难:新增的十几个功能每一个单拎出来都能提升特定性能,但所有功能相互交叉的交互复杂度(interaction complexity)却呈爆炸式增长。营销团队和保守客户往往会强硬要求“保留全部旧特性,不准删除任何东西”;与此同时,他们却私下对仅具备旧系统 70% 功能但轻巧无包袱的新架构跃跃欲试。复杂系统的交互开销最终会严重拖慢流水线,使更精简的设计在实际执行中轻松胜出。 面对这种局面,架构师并非只能坐以待毙。现代芯片设计早已不再像几十年前那样——前级取指、分派、执行和访存之间被上百条与时钟相位死死绑定的杂乱飞线牵扯在一起;取而代之的是严苛的解耦协议和模块化抽象。 为了处理历史包袱同时保住核心性能,现代处理器往往将旧指令模式边缘化。对于低频过时的遗留特性,完全可以通过微码、软件仿真或独立的隔离逻辑单元低速运行,从而避免污染主流水线。在物理结构上,现代超级标量 CPU 内部早已不再是一整个不可分割的庞然大物,而是通过清晰的指令边界与“握手-确认(ACK)”协议相互连接,其形态实质上更接近八台分工明确的微型计算机(取指机、分派机、整型执行机等)协同运作的网络。 ### [031:46] 抽象层违规与工程代价 Jim Keller 借浮点运算单元的解耦设计,引申出芯片架构的核心原则。他指出,如果接口规范得当,工程师可以随时替换底层的浮点计算部件,而根本不需要触碰系统的其他模块。这本质上并非指令集架构(ISA)层面的束缚,而是源于最初设定的设计准则,以及在推进过程中能否自始至终恪守该准则。 工程实践中最致命的陷阱往往源于妥协与走捷径。工程师在遇到难题时,极易产生“只要在两个模块之间临时拉五根飞线就能立刻解决”的冲动。然而每一次打破抽象层边界,都会为未来的自己埋下技术债务。Jim 坦言这种教训他经历过无数次:“Every time you violate the abstraction layer, you've created a problem for future Jim.” 随着修补与规避措施不断累积,原本清晰优雅的设计终将被这些临时拼接彻底拖垮。 --- ### [032:33] 抽象层哲学的形成:从 DEC EV6 到 AMD K7 与 HyperTransport ```mermaid flowchart TD accTitle: 芯片设计方法学演进路径 accDescr: 展示从 DEC EV6 的全定制晶体管级混乱,到 AMD K7 标准单元库抽象,再到 HyperTransport 虚拟通道总线解耦的演进过程。 subgraph EV6["DEC Alpha EV6 (全定制设计)"] A["晶体管级自研 (22种触发器)"] --> B["乱序执行短流水线"] B --> C["S2K 总线 (复杂事务硬编码)"] end subgraph Transition["抽象思维转变"] C -->|"Kurosh Kowshik 指导: 引入虚拟通道"| D["HyperTransport 协议"] end subgraph Modern["AMD K7 / K8 (分层抽象方法学)"] D --> E["标准单元库 (仅大/小两种触发器)"] E --> F["架构 / 微架构 / RTL / 门级 分工明确"] end ``` Ian Cutress 询问 Jim Keller,这种贯穿其工程生涯乃至生活认知的“抽象层”哲学究竟是在何时形成的。Jim 回顾了他在 DEC(数字设备公司,Digital Equipment Corporation)参与 Alpha 21264(EV6)处理器开发的经历。当时 EV6 由他与 Dirk Meyer 共同担任主架构师,采用高度定制化的设计方法学。整个项目充斥着底层晶体管层面的混乱——团队内部甚至允许工程师自行设计触发器,导致库里存在多达 22 种不同的触发器。当外人询问 DEC 的器件库有哪些元素时,Jim 甚至自嘲回答:“Both of them: N-devices and P-devices.”(两种都有:NMOS 和 PMOS)。 1998 年 Jim 转入 AMD 负责 K7 项目,亲历了严谨分层带来的生产力飞跃。AMD 当时采用标准单元库方法,全库仅收录两款标准触发器(一大一小),在晶体管物理实现与逻辑设计之间建立起明确的抽象墙,在自动布局布线(Place and Route)技术尚不成熟的年代大幅提升了迭代效率。 在系统互连层面,EV6 遗留的总线设计(即后来授权给 AMD 的 S2K 总线)原本充满了繁冗复杂的硬编码事务指令。DEC 研发实验室的同事 Kurosh Kowshik(后加入 Google 成为安全专家)听完 Jim 的介绍后直接摇头直言:“Jim, that's not the way you do this.” Kurosh 向他传授了虚拟通道(Virtual Channels)及独立信息抽象通道的通信架构原理。这次被 Jim 戏称为“教育研讨会兼狠狠上一课”的交流,催生了后来的 HyperTransport 总线。从此,Jim 坚定了分层抽象信念,认识到必须通过严整的接口合约隔离复杂度,防止单一部件的实现侵入上层架构。 --- ### [036:32] 人类组织极限与 Zen 团队的分工契约 Jim Keller 将抽象层理论自然延伸到了组织管理与团队协作规模上。他指出人类大脑存在生理认知边界:个体能维持亲密互动的小圈子仅有 10 到 20 人,组织良好时能勉强掌握 50 到 100 人的网络,一旦团队总人数突破 100 人,边界外的人员在心理上都会被视作“半陌生人”。 如果强行将数百人堆砌在同一个缺乏切分的架构项目中,整体研发效率不仅不会提升,反而会急剧下降。因此,管理规模化系统的唯一解法就是通过抽象层将团队切开:“If you want to build something bigger and more complicated, you better solve the abstraction layers, because people aren't smarter.” - **团队认知瓶颈**:单一大团队超过 100 人即进入协调内耗期,必须在体系中划分至少两层抽象边界。 - **Zen 架构团队结构**:在打造 AMD Zen 微架构时,核心团队约有 200 人,Jim 将其明确对半切分——100 人专职负责前端(Front-end),100 人专职负责后端(Back-end)。 - **接口契约执行**:前后端团队之间仅凭严格定义的接口规范协作,双方无需为了底层实现细节反复拉扯跨界沟通,保障了各自架构的高效推进。 --- ### [037:49] 摩尔定律未死:设备制造商、EUV 与物理极限 针对外界关于摩尔定律走向终结的悲观论调,以及部分人士认为他对工艺进化“漠不关心”的猜想,Jim Keller 予以明确反驳。他强调自己对半导体制造细节了如指掌,态度是“极度主动”(super proactive)而非消极被动。 公众往往将某些特定企业的节点延期与底层物理极限混为一谈。例如 Intel 在 10 纳米节点陷入泥潭时,舆论纷纷高呼摩尔定律已死;但与此同时,台积电(TSMC)的制程路线图却按部就班推进。台积电成功的原因在于其策略紧密贴合了极紫外光刻(EUV)机台的演进节奏,擅长利用微调与“半代步进”策略平滑过渡(如 7 纳米初版采用非 EUV,随后的 7nm+ 导入 EUV,5 纳米进一步扩大应用,再到 5nm+ 优化)。 ```mermaid flowchart LR accTitle: 半导体制造分工协同模型 accDescr: 展示半导体设备制造商与晶圆代工厂之间的技术创新支撑关系。 subgraph Equipment["底层创新源泉 (工具制造商)"] A["ASML<br/>(EUV / 光刻机台)"] B["Applied Materials<br/>(薄膜沉积 / 刻蚀设备)"] end subgraph Foundries["工艺集成工匠 (晶圆制造厂)"] C["TSMC / Intel / Samsung<br/>(工艺集成、材料配比、结构堆叠)"] end subgraph Output["物理实现"] D["先进制程芯片<br/>(仍远未触及原子理论极限)"] end Equipment -->|"提供先进光刻与刻蚀工具"| Foundries Foundries -->|"利用精密工具制造"| Output ``` Jim 强调,半导体行业的创新核心重心往往不在代工厂本身,而在应用材料(Applied Materials)和 ASML 这类上游设备制造商手里。业界早期曾长期怀疑 EUV 机台能否投入量产,而如今 ASML 的市值已达到 Intel 的两倍,到 2023 年仅台积电一家采购的 EUV 机器就将达到约 150 台之多。 对于纳米尺度的极限,Jim 引用物理学家理查德·费曼(Richard Feynman)的名言强调底部的探索空间依然广阔:“There's lots of room at the bottom.” 从原子尺度换算,目前晶体管内部跨越的原子数量依然相当可观,而理论上构建一个不受剧烈量子效应干扰的可用结型(junction)仅需要大约 10 个原子。眼下工艺面临的种种延误与挫折,根本原因在于设备供应商与工艺集成工程师在复杂工序协作上的工程匹配难度,而非物理学定律设置的不可逾越之墙。未来即便推进到 X 射线光刻(X-ray lithography)等全新阶段,行业也必将继续向前开拓。 ### [42:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2526s) 光刻演进:从 EUV 多重曝光到 X 射线光刻 Ian Cutress 询问,既然高数值孔径极紫外光刻(High-NA EUV)即将面世,那么更激进的技术——例如 X 射线光刻(X-ray lithography)——会在何时商用?Jim Keller 直言,每当新半导体技术问世时,厂商往往只在极少数关键层试探性使用;例如 EUV 最初引入 DRAM 制造时,仅仅用于一道或两道光刻工序。谈及更进一步的光刻时间节点,Keller 预估:“我正试着回忆,大概在 2023 或 2024 年,它其实没那么遥远。”这意味着业内早已搭建测试机台,研发人员也已实际展开验证与摸索。 随着光源波长从传统光学紫外光迈向 EUV,波长缩减了约十倍。此前业界在深紫外光时代所发明的多重图案化(multi-patterning)以及复杂的干涉补偿技术,如今在 EUV 上也将故技重施。Keller 指出,EUV 进入 3nm 制程后预计也会采用多重曝光技术,结合材料纯度的严苛控制与防止形变的精细温控,物理层面的微缩远未停滞。Keller 乐观地表示,全球有成千上万顶尖人才正投身于这一链条中,每十个人的团队就能贡献一项创新,“有足够充沛的创新带宽”推动工艺继续向前。 - EUV 相比传统深紫外(DUV)光学光刻实现了约 10 倍的波长缩短。 - 早期将 EUV 引入 DRAM 生产时,仅试探性用于 1 至 2 个关键层(critical stops)。 - 预计 3nm 制程阶段,EUV 也会引入多重曝光(multi-patterning)方案。 ```mermaid flowchart LR accTitle: 光刻演进流程 accDescr: 展示从 DUV 到高数值孔径 EUV 乃至 X 射线光刻的技术递进阶段 subgraph DUV["深紫外 (DUV) 阶段"] A["DUV 光学光刻"] --> B["多重图案化与干涉补偿"] end subgraph EUV_Phase["极紫外 (EUV) 阶段"] B --> C["EUV 单次曝光直接成型"] C --> D["EUV 多重曝光 (3nm 制程)"] D --> E["高数值孔径 (High-NA) EUV"] end subgraph Beyond["前沿探索阶段"] E --> F["X 射线光刻早期验证"] end ``` --- ### [44:01](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2641s) 打造团队的艺术:雕琢大理石与跳出局部最优 针对 Ian Cutress 提出的“业界领袖跳槽时常拉走整建制团队,你如何组建团队”这一问题,Jim Keller 提出了一个核心命题:你究竟是在“组建”(building)团队,还是在“发掘”(finding)团队?他以威尼斯的美术馆和米开朗基罗的巨石雕像作比喻——二十英尺见方的巨大大理石块就伫立在那里,米开朗基罗能看出里面的雕像早已存在,“问题在于剔除多余的大理石”。对于大型成熟企业,Keller 直言:“如果你走进一家拥有一千名员工的公司,我敢向你保证,那里肯定有一支优秀的团队,你根本不必去招人。”他在 AMD 时几乎没有额外对外招募,只是把现成的人员重新调整和调配部署。相反,进入特斯拉时,由于此前完全没有造芯团队,他才不得不从零搭建,先物色熟人,再逐步招募新面孔。 ```mermaid flowchart TD accTitle: 团队搭建策略对比 accDescr: 对比发掘既有团队与跨组织组建新团队的不同路径与效果 subgraph Finding["发掘既有团队 (如 AMD)"] A1["已有庞大组织"] --> A2["识别潜在大理石/人才"] A2 --> A3["重新调配与部署岗位"] A3 --> A4["激发既有员工潜能"] end subgraph Composing["组建全新混合团队 (如 Tesla)"] B1["零基础起步"] --> B2["招募已知熟人与外部新人"] B2 --> B3["打破局部最优思想"] B3 --> B4["博采众长形成全新合力"] end ``` Keller 强烈反对领导者跳槽时带上一整个二十人原班人马去全盘复制旧事物。在他看来,二十人足够复制以前的一切,但也会让新人产生排斥感,阻碍创新;而组建新团队的最佳状态是吸收具有不同思维方式的人,从而打破思维定式(local minimum)。Keller 甚至借用 DEC 创始人肯·奥尔森(Ken Olsen)的观点指出,“没有糟糕的员工,只有员工与岗位不匹配”。他早年觉得这话愚蠢,后来发现确实如此——他曾解雇过一些表现不佳的人,但那些人换了环境后大获成功,因为他们原先只是在情感上执着于行不通的死路,环境的转换恰恰解放了他们。 > “如果你走进一家拥有一千名员工的公司,我敢向你保证,那里肯定有一支优秀的团队,你根本不必去招人。”(Jim Keller) > “数字设备公司(DEC)的肯·奥尔森曾说过:‘没有糟糕的员工,只有糟糕的员工与岗位匹配。’我年轻时觉得这话简直蠢透了,但随着共事的人越来越多,我亲眼见过太多次这种情况了。”(Jim Keller) - **大理石隐喻**:优秀团队往往本就埋藏在庞大企业内部,领导者的关键职责在于“剔除多余的大理石”,调整人员岗位。 - **反对照搬班底**:直接带 20 人的旧部虽能复制老业务,却容易固化在局部最优解,排斥新思路。 - **组合多样性**:从十个优秀团队中各抽调一人组建新团队,往往比原班人马更强,因为大家会重新筛选并碰撞出最优方案。 --- ### [47:45](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2865s) 企业文化、人际信任与清除“办公室政治” 在谈到招聘时是该顺应公司文化还是逆流而上时,Jim Keller 阐明必须视具体任务而定。如果目标是颠覆性的创新,就必须引入敢于逆流而上的变革者;但若项目本身正处于高效推进中,强行塞进煽动者只会拖慢整体节奏。卓越的工程师具备极高的人际敏锐度,他们懂得在当前项目中服从大局、埋头推进并建立内部网络与信任,待到下一个契机来临时再发起方向调整。 Keller 特别强调了“信任”对团队效率的决定性作用。如果一个毫无交情的人让你跳桥,你绝不可能答应;但如果大家共同经历过风雨,对方说“相信我,跳下去你会没事的,过程很痛苦但结果会很好”,团队就会毫不犹豫地执行。充满信任的团队效率极高,而缺乏信任的组织则必须依赖繁琐的合同、讨价还价与政治斡旋。针对职场政治,Keller 给出了极其犀利的评判:那些为了个人利益操控组织环境搞政治的人必须被开除;唯独当这种人是项目最高负责人且能稳定交出卓越成果时,大家才会默认其政治手腕来自业绩底气,但基层员工无端搞政治只会制造海量内耗。 > “充满相互信任的团队,其效率要远远高于那些凡事都得靠合同、谈判和政治手段来解决的团队。”(Jim Keller) - **创新与稳固的项目诉求不同**:重大创新需要打破常规的挑战者,而平稳推进的优质项目则需要避免无意义的干扰。 - **信任能够消除摩擦**:建立在共同奋斗史上的信任,能让团队面对极端技术挑战时步调一致,免去官僚流程。 - **对政治手腕的容忍度**:操控环境谋私利的人应被坚决清理,除非是凭借交付成果树立权威的高级主管,否则基层政治斗争只会制造巨大压力。 --- ### [49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) 职业生涯探索:在深耕专业与开拓眼界之间权衡 Ian Cutress 询问初涉职场或处于中期的工程师是否应该频繁跳槽换项目以避免陷入瓶颈。Jim Keller 给出了一套平衡原则:当你在做全新的事情,且顶头上司的见识与水平远超你时,你的成长速度是最快的。如果初入职场发现学不到东西,上级也毫无启发意义,那么确实应该尽早换环境。 然而,Keller 也警告不可盲目跳槽。他见过不少年轻人为了所谓“积累多重经验”连续跳槽三次,结果样样通、样样松,最终一事无成。这类人如果当初能耐下心在某个领域扎实深耕、钻研透彻,职业发展反而会好得多。职业生涯必须在“快速跳槽吸收新知”与“深度扎根某一专业”两股力量之间保持良性的创造性张力(creative tension)。 > “当你在做全新的事情,而且为之工作的上司比你懂得多得多时,你的学习速度是最快的。”(Jim Keller) - **更换项目的标准**:当无法获得技术新知,且导师/领导者不再具有启发性时,应当果断寻求变动。 - **过度跳槽的陷阱**:频繁横向跳动易导致无法建立核心硬核技术能力,导致高不成低不就。 --- ### [50:22](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3022s) 早年导师与 DEC 黄金时代的群星闪耀 回顾早期影响自己的导师与楷模,Jim Keller 首先提到了原生家庭的深远影响。他的父亲是一名严谨的工程师,母亲则极具语言和逻辑天赋。Keller 透露自己天生患有阅读障碍(dyslexic),幼年几乎无法正常阅读;他小时候一直以为自己像工程师父亲,直到成年后才意识到自己在智力架构和思考习惯上其实更接近后来成为心理治疗师的母亲,兼具工程实践与人文逻辑两方面特质。 进入数字设备公司(DEC)后,Keller 迎来了职业生涯的黄金领路人。他的直接主管是传奇计算机体系结构大师鲍勃·斯图尔特(Bob Stewart)——斯图尔特主持设计了 PDP-11/44、PDP-11/70、VAX-11/780 以及 CI 总线互连架构。Keller 回忆当时业内有一句评价:斯图尔特参与过的每个项目,在那个时代都创造了超过十亿美元的收入。除了斯图尔特,DEC 体系下群星闪耀,Keller 在 DEC 研究实验室结识了巴特勒·兰普森(Butler Lampson)、查克·萨克尔(Chuck Thacker)等图灵奖得主及体系结构泰斗,并在年轻时期得到了南希·克罗宁伯格(Nancy Kronenberg)等前辈导师的手把手指导。 - **家庭基因启迪**:兼具工程师父亲的实践视角与治疗师母亲的语言逻辑,尽管克服了严重的阅读障碍症。 - **传奇架构师鲍勃·斯图尔特**:Keller 在 DEC 的直接主管,主导 PDP-11/44、PDP-11/70、VAX-11/780 和 CI 互连总线,以“每个项目产生十亿美元”著称。 - **DEC 研究实验室的学术圈子**:早年有幸与 Butler Lampson、Chuck Thacker、Nancy Kronenberg 等大师共事并深受其架构哲学熏陶。 ### [52:03](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3123s) 初入 DEC 与当面反驳 Gordon Bell 的轶事 Jim Keller 回忆起自己在 DEC(Digital Equipment Corporation)工作的第一周。当时他正接受一种名为 Valid 的原理图绘制系统培训,该技术早于 Mentor Graphics 时代。一位长者走进培训室,开始向他们提问并阐述分层设计(Hierarchical Design)的理念。年轻的 Jim Keller 毫不客气地当面指出,这种架构设计一部分是好主意,但另一部分则“纯属愚蠢”。 两人就此唇枪舌剑地争论了近一个小时。直到对方离开后,旁边的同事才目瞪口呆地告诉他:“那是 Gordon Bell(DEC 传奇工程副总裁、小型机先驱)。”Jim 听后一脸茫然地问那是谁,同事答道:“他就是整个 DEC 的缔造者。”Jim 当时的第一反应却是:“好吧,他刚才说的话有一半都是错的,希望我已经帮他纠正过来了。” Jim 调侃自己这种不知天高地厚的性格:“我想我只是血清素激活水平低之类的,这更像是我自己的心理问题,而不是什么特质。”面对主持人 Ian Cutress 询问他这些年来是否有所“成熟”,Jim 幽默地反驳道: > “一点都没有,难道那才是好玩的地方吗?”——Jim Keller 不过,他也承认自己在心智上确实发生了改变。年轻时登台演讲会紧张,也总觉得身边的同事只要把事情做对就行了;而如今,他对“人们在想什么、为什么要这么想”产生了极大的兴趣。他把紧张转化为乐趣,例如在英特尔面对 2,000 名员工登台发言时,不仅不再恐惧,反而感到异常兴奋。但他对计算机设计的狂热始终未变,正如他朋友的妻子所吐槽的:“他们在水里加了什么药?你们这些人聚在一起除了电脑什么都不聊!” --- ### [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) 深度阅读与莎士比亚的管理学启示 谈到如何理解他人与人性,Jim 将其归功于大量的跨学科阅读。他指出,书籍是一种极其高效的信息压缩形式:“某人历经 20 年的沉淀,充满激情地写下他们最顶级的思想”,而且人们还能在亚马逊上轻易筛选出最好的作品。Jim 强调,读三四本书很难改变命运,但广泛阅读数千本书绝对能重塑一个人的认知模式。 > “读四本书就想改变人生很难,因为有时一本书确实能改变你;但读一千本书一定会改变你的人生,这是毫无疑问的。”——Jim Keller 在工程团队管理中,经典文学和人文著作展现出了惊人的实用价值: - **莎士比亚与马基雅维利**:书中关于权力斗争、阴谋诡计、默默干活的下属以及力挽狂澜的英雄人物的故事,在 500 年前是这样上演的,“而在现代美国企业里,每个星期的每一天都在重复上演”。 - **卡尔·荣格(Carl Jung)**:比起市面上流行的《从优秀到卓越》(*Good to Great*)等商业管理畅销书,Jim 认为深入研读荣格的心理学著作对于理解团队管理更有帮助。 - **与 Venkat Rao 的交流**:在接任 AMD 高级管理岗位之前,Jim 曾通过博客 Ribbonfarm 联系到作者 Venkatesh Rao 并聘请其提供咨询。按照 Rao 给的书单,Jim 狂啃了 20 多本管理学著作。后来他发现,大部分技术经理人可能一本都没读过,读过 20 本书的他已经比行业平均水平多读了整整 19 本半。 ```mermaid flowchart LR accTitle: Jim Keller 从阅读到团队管理的认知转化路径 accDescr: 展示 Jim Keller 如何通过广泛阅读历史、心理学和经典文学,提炼人性洞察并将其运用到现代芯片工程管理与团队调试中。 subgraph Literature ["多学科阅读输入"] A["经典文学与历史<br/>(莎士比亚 / 马基雅维利)"] B["心理学与思想深度<br/>(卡尔·荣格 / 哲学)"] C["系统化管理理论<br/>(Venkat Rao 推荐书单)"] end subgraph Insight ["认知沉淀与心智模型"] D["理解企业政治机制<br/>权力演化与微观动机"] E["透视人性与思维模型<br/>洞察为何人会如此思考"] end subgraph Application ["工程管理实践"] F["调试团队成员心理<br/>(Debug People)"] G["化解阻力并驱动<br/>顶尖芯片团队协作"] end A --> D B --> E C --> D D --> F E --> F F --> G ``` --- ### [57:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3436s) 阅读谱系与“被动的 Jim Keller 读书俱乐部” 谈及阅读经历,Jim 坦言自己小学四年级才真正学会阅读,但到了七八年级,他就已经把家里的藏书扫荡一空。他的父母参加了读书俱乐部,家中藏有大量约翰·厄普代克(John Updike)和约翰·巴思(John Barth)的作品。其中,诺贝尔文学奖得主多丽丝·莱辛(Doris Lessing)融合了心理探索的科幻小说系列,曾在他年轻时带来巨大的思想震撼。如今,他的涉猎范围涵盖历史、人类学、心理学、神秘主义等各种非虚构领域。 Ian 提到 Jim 之前在 Lex Fridman 的播客中曾提及自己一周读两本书,观众甚至提议他开设一个“被动的 Jim Keller 读书俱乐部”(Passive Jim Keller Book Club),在 Twitter 上分享书单。对此,Jim 笑着表示自己的注意力机制不适合玩社交媒体: - 他现在虽然仍保持庞大的阅读量,但更多转向了深度博客和前沿长文; - 他的注意力跨度很难适应社交网络的碎片化互动,经常一连几周把社交账号忘得一干二净; - 如果真的开推特推书,很可能长期断更而虎头蛇尾。 --- ### [59:22](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3562s) 吸收知识的哲学与“梦境预处理”问题解决法 针对“如何在阅读中避免分心、确保彻底吸收知识”的疑问,Jim 的回答出人意料:他完全不在乎能不能记住具体内容。他从不在书上做大量批注或强行记忆,因为很多出版物受限于 250 页的行业规则,往往前 50 页讲透了核心理念,后 200 页全是无意义的充数内容。 > “大脑是个奇特的东西,你无法随时调出读过的所有想法和琐碎细节,但你的整个人格却会被它们充分浸润和塑造。我相信这个沉淀的过程。”——Jim Keller Jim 总结了一套结合冥想与梦境的独特思维加工机制: - **无意识浸润**:即使想不起作者的名字或具体的出处,但书中的核心思想已经改变了你看待世界的方式。 - **冥想内省**:他保持规律的冥想习惯,在静思中让刚吸收的知识与当下正在思考的工程技术难题自然融合。 - **睡前梦境定向(Dream Prepping)**:在入睡之前,他会主动在大脑中调出当前攻关的技术难题。入睡后,大脑常常会在梦境中继续对该问题进行非线性的推演与重构;有时梦境会绕过表层障碍,直接指向真正需要解决的核心矛盾。 ### [01:01:58](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3718s) 时间管理与在特斯拉的“偷懒”哲学 谈到日常作息与时间分配,Jim Keller 笑着表示别人也许一晚只需要睡四个小时,但他喜欢睡满七个小时。他曾算过一笔账,发现自己理想中的一天其实需要 34 个小时:因为他喜欢锻炼身体、陪伴孩子打闹、睡觉、享受美食、全身心工作,还喜欢阅读。工作是一件奇妙的事情,它能轻易吞噬掉比你原本预期多得多的时间,但由于他本身也极度热爱工作,因此如何压制工作对生活的过度侵蚀反倒成了一种挑战。 ```mermaid flowchart TD accTitle: Jim Keller 任务分流与委托逻辑 accDescr: 当待办任务堆积时寻找更有热情的人接手,自己专注于未解决的难题。 A["工作量过载 / 出现重复性任务"] --> B{"寻找对该任务更有热情的团队成员"} B -->|"委派任务与授权"| C["团队成员接手并获得历练"] B -->|"抽身出来"| D["自身专注于未解决的根本难题"] C --> E["整体效率提升 / 项目按时推进"] D --> E ``` 当被问及面临严苛的项目截止日期(Time-to-market)时会先牺牲什么,Jim Keller 透露在过去大约六年的时间里,他最关键的应对策略并不是硬扛,而是任务委派: - 一旦在某个领域感到待办事项堆积如山,他会立刻去寻找一个比他更想做这件事的人,并彻底放手交给对方。 - 自己的精力应当只聚焦在攻克那些“尚未解决的难题”上。 - 他打趣称自己是“特斯拉最懒的员工”。在特斯拉那种流行“一天死磕 12 个小时只为显得在努力工作”的文化下,他每天通常只从早上 9 点工作到晚上 7 点。 - 他会在午休时去跑步,并在特斯拉鹿溪(Deer Creek)园区紧邻大型机加工车间的举重房里举铁一小时,随后从容进餐。 - 在 AMD 和英特尔这样庞大的组织中,当意识到自己耗费了过多时间在做演示 PPT 或陷入某些琐碎细节时,他会迅速挑选有干劲的下属接管,然后自己安心去休假。 ### [01:03:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3824s) 公开演讲与公关采访的真正价值 对于分析师 Ian Cutress 提出的是否会觉得公关采访、市场营销和行业对话只是“浪费时间的闲聊”这一问题,Jim Keller 给予了坚决的否定。他认为公开表达绝非空谈,其核心价值在于理清逻辑与向内传导影响力: > “I reached more people inside Intel by doing external talks.” —— Jim Keller 在英特尔任职期间,内部几乎所有工程师都认定摩尔定律(Moore's Law)已经走向终结。Jim Keller 感到不可思议:英特尔本身就是由摩尔定律定义的基石公司,如果核心驱动力已死,组织势必陷入巨大泥潭;而他坚信摩尔定律依然活着。通过接受外界采访和进行公开演讲,外部媒体与分析师将他的观点放大并展开激烈辩论,这种舆论声浪随后倒灌回英特尔内部,反而促使他在公司内部触达了远比常规内部会议更多的人,从而有效重塑了工程师们的信念。 此外,公开表达也是一种思维提纯工具。与深刻思考的技术观察者交流能带来强大的刺激,因为“如果你能把一件事解释得极度透彻,你才算真正懂它”。许多时候人以为自己掌握了,一开口却磕磕绊绊;准备一场看似简洁的公开演讲极其困难,演讲者必须经历梳理观点、重新组织逻辑并彻底“剔除废话”的过程。 面对费曼(Richard Feynman)或萨根(Carl Sagan)提出的“若无法向大一新生讲明白,就证明未真正理解”的理论,Jim Keller 笑着评价道,费曼虽然极其擅长物理教学,但费曼的困扰在于其数学直觉过于天才,以至于费曼眼中的“简单”在别人看来往往非同寻常。费曼常常用三五个直觉跃迁就完成了一套天体轨道几何的计算,并兴奋地感慨过程有多简易,可全场通常只有费曼一个人觉得简单。 ### [01:06:12](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3972s) 超能力、视觉化思考与毅力胜于天赋 当被问及芯片设计是否依赖在脑海中具象化电路时,Jim Keller 承认自己完全是一个“视觉型思考者”。他总结自己唯一的超能力,就是能够在脑海中清晰地看到一台计算机究竟是如何运行的。在进行架构性能建模时,整套复杂的系统结构已经在他的头脑中完整铺开并实时运转,他要做的仅仅是将其用代码顺畅地敲出来。 ```mermaid flowchart LR accTitle: 卓越工程能力构成要素 accDescr: 天赋结合视觉思维、毅力以及对自驱热情的追寻。 subgraph Mindset["认知特质"] A["视觉化直觉<br>(可视化电脑运行)"] B["阅读障碍补偿<br>(后天构建的思维模式)"] end subgraph Execution["执行核心"] C["毅力与坚韧(Grit)<br>(经历细微迭代不放弃)"] D["纯粹的自我热情<br>(拒绝迎合他人期望)"] end Mindset --> E["攻克深层工程混乱"] Execution --> E ``` 在探讨这种能力是“先天造就(Nature)还是后天培养(Nurture)”时,Jim Keller 提到了他成年较晚时期才被正式确诊的阅读障碍(Dyslexia): - 这一特质部分是天生的,部分是后天补偿性训练的结果,阅读障碍反向促使他建立了强大的纯视觉感知模型。 - 极度聪明的天才往往因为一切来得太容易,未经历严苛的挫败,因而在职业生涯中很难走得长远;而他认为自己并没有那么聪明,因此“坚韧”(Grit)与持久的恒心才是最关键的武器。 - 芯片设计充满了复杂的微调和混乱的中间态,必须具备足够的信念,在无数次细微的工程迭代中忍耐推进,才能拨开迷雾抵达彼岸。 - 仅有天赋而不懂如何吃苦的人,往往止步于做那些显而易见的浅层工作;而缺乏热情的人则更难以维持这种耐力。他常常告诫迷茫的年轻人:不要因为父母或外界的期许去违心做经理,追逐别人的梦想意味着你永远不会投入真正的能量,最终只会让自己陷入艰难的恶性循环。 ### [01:08:52](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4132s) 导师机制与使命驱动的团队培养 关于是否会创办类似“Jim Keller 半导体设计学校”来正式培养后辈,Jim Keller 表示自己从来不是一个刻意设定教学计划的传统导师。他所做的一切,核心全是由“使命”(Mission-driven)驱动的——例如团队的目标就是去搞定 Zen 架构,或者彻底做出特斯拉 Autopilot 自动驾驶芯片。 > “People later on told me that I was mentoring them and I'm thinking, I thought I was kicking your ass.” —— Jim Keller 在带领团队的过程中,Jim Keller 的管理与培养呈现出鲜明的个人风格: - **直击痛点的管理**:一旦成员向他汇报,他会迅速评估对方的真实状态。对表现优异者充分信任,对出现重大卡点者则采取极其直接犀利的指引;许多下属在多年后感激他的“悉心指导”,他却调侃自己当时只是在严厉地踢他们的屁股督促干活。 - **关注身心能量**:他甚至会毫不客气地直接干预员工的健康、体态或饮食习惯。他认为如果一个人看起来对生活毫无活力,就绝不可能在工作中爆发创造力,而改善身体状态往往能带来立竿见影的精气神提升。 - **戒除名利攀爬心态**:他极其反感为了职级地位(Status)而拼命向上钻营的向上爬者(Climber)。他明确指出,获取地位最健康、最体面的唯一方式就是踏踏实实做出伟大的成果,让所有人发自内心地敬佩;靠投机钻营上位不仅令人厌恶,而且往往暴露了一个人缺乏依靠硬核实力做成事情的自信。 - **纯粹的成就感**:对他而言,所有严格要求的初衷都是为了把复杂庞大的工程做成,带领团队冲破混乱达成看似不可能的目标,这正是他工作中最感欣慰的事。 ### [01:11:06](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4266s) 所谓导师:解决个人障碍比解决技术难题更重要 Jim Keller 探讨了指导(mentoring)的本质。他认为脱离具体任务的“纯指导”极其困难——如果有人跑来找你说“我想变得更优秀”,你根本无法下手,因为你不知道他想在什么方面优秀;如果你说“我想把小提琴拉得更好”,而这恰恰是对方不擅长的领域,指导就失去了依托。但如果明确树立一个具体而宏大的目标,例如“我们要打造全球最快的自动驾驶芯片”,那么团队中的每个人就必须为了这个目标去提升自我。 在追逐目标的过程中,工程师遇到的障碍往往不是纯技术问题。Jim Keller 发现:“结果表明,他们四分之三的问题其实是个人层面的,而不是技术层面的。”工程师面临的现实问题清单极其冗长:健康问题、父母与童年创伤、伴侣家庭矛盾、职场人际摩擦以及职业停滞等。管理者必须认真对待这些看似细碎的个人问题,因为每个人都把自己的烦恼看得很重。 人们面对提问时,往往不会立刻吐露真正的核心症结。有些人会列举出自认为管理者想听到的五大问题,或者干脆对核心问题设立“禁飞区”,闭口不谈最深的痛处。作为领导者,如果能帮助他们排查并化解这些阻碍工作的个人包袱,项目的推进就会顺畅许多;在此之后,员工才会由衷认可你的帮助,并把你称为“导师”。 - 目标驱动成长:只有在具体项目的共同目标下,个人提升和指导才能真正落地。 - 个人问题重于技术障碍:生活、家庭和职业焦虑往往直接拖累工程研发进度。 - 沟通中的“禁飞区”:员工常掩饰真实困难,领导者需要有耐心去洞察和拆解。 ### [01:13:03](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4383s) 职业生涯的骄傲时刻:微小突破与团队潜能的释放 当被问及职业生涯中最骄傲的时刻时,Jim Keller 表示这种瞬间有很多。他特别提到了在英特尔与 Becky Loop 合作的经历:当时他们正在排查复杂的芯片质量问题,数据层层叠叠,局面令人沮丧。直到有一天,Becky 拿着一张构思极其清晰完美的图表走进展室,彻底穿透了迷雾,让人直接看到了解决问题的清晰路径。对 Jim 而言,见证他人迎来这种豁然开朗的“顿悟时刻”,其成就感甚至超过了宏大里程碑本身。 ```mermaid flowchart TD accTitle: Zen 架构研发破局流程 accDescr: 展示 Zen 团队从最初丧失信心、面对面排查阻碍,到最终齐心协力重构产品并取得成功的全过程。 subgraph Problem["初期困境"] A["团队信心丧失<br/>外界看衰 AMD CPU 实力"] end subgraph Breakthrough["现场攻坚"] B["全员白板会议<br/>列出全部技术死结与质疑"] C["一线骨干接棒推导<br/>逐一探讨解决方案"] end subgraph Execution["重构与交付"] D["梳理人才与重新组织架构"] E["持续反复对齐愿景与信念"] F["Zen 架构成功面世"] end A --> B B --> C C --> D D --> E E --> F ``` 随后话题转向了特斯拉 Autopilot 芯片和 AMD Zen 架构的辉煌胜利。Jim Keller 回忆,在 Zen 研发初期,外界普遍认为 AMD 团队已经彻底掉队,无法造出顶尖的 CPU。然而,构建 Zen 的核心骨干——例如 Mike Clark、Leslie 以及 Suzanne Plummer 等人——实际上已经在 AMD 扎根了 25 到 30 年,拥有极其扎实的历史积淀与成功经验。他们缺少的不是技术底蕴,而是清晰的目标和合理的组织结构。 - 目标重构:明确核心性能指标,并重新整合团队资源以确保指标达成。 - 人才挽留与倾听:重点倾听那些因长期受挫而心灰意冷的资深骨干的心声。 ### [01:15:17](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4517s) 闭门两天白板攻坚:Zen 团队逆风翻盘的转折点 在 Zen 项目推进的最艰难阶段,Suzanne Plummer 给在加州的 Jim Keller 打电话直言:“Zen 团队的人根本不相信自己能做成这件事。”Jim 随即回应道:“太好了,我这就开车去机场,明早 8 点见,准备一间有大量白板的大会议室。”次日清晨,会议室里坐满了大约 30 位满腹怨气、准备列举所有失败理由的资深工程师。 Jim Keller 没有反驳,而是把他们提出的每一个无法逾越的难题全部抄在白板上,整整花了两天时间与大家共同推演解决。最初的场面犹如一场群臣围攻的防守战,但随着讨论深入,工程师们纷纷走上前台。当有人提出某个环节不可行时,另一位工程师就会站出来说“我知道怎么修”,Jim 便立刻把白板笔递给对方,让他们在白板上推导细节。团队表现出了惊人的坦诚,毫无保留地把所有潜在地雷摊开在桌面上,而不是藏着掖着来考验领导。 当时首席架构师 Mike Clark 也在场,展现出了迎难而上的极强担当,认为所有技术障碍均可攻克。尽管开完会大家如释重负,但两天后由于旧习惯作祟,疑虑又会卷土重来。Jim 强调,带领团队重塑信念需要“在必要时重复解释无数次”。Zen 最终能够大获成功,归功于整个核心领导团队的坚守与投入,而非领导者一人的场外督促。 > “在 Zen 团队中,由于他们经历了太多许诺能解决问题却最终落空的研发项目,大家甚至认为我不过是又一个夸夸其谈的骗子。但我从不吹嘘,坦诚告诉他们哪些能做、哪些我也不确定。” —— Jim Keller ### [01:17:21](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4641s) 沉默的工程英雄与技术人员的“外倾化”修炼 谈及芯片行业中那些未曾获得应有赞誉的“隐形英雄”,Jim Keller 感叹道:“绝大多数工程师都是如此,这样的人实在太多了,令人难以置信。”与硅谷动辄收费每小时 800 美元的律师相比,许多才华横溢的技术专家只求不被打扰,默默埋头深耕。Jim 遇到过许多在岗位上兢兢业业的工程师,例如有人自豪地宣告这是自己设计的第八代内存控制器,其 RTL 代码极为纯净,注释详尽规范,没有任何逻辑漏洞。然而,这些秉持严谨和尽责态度的工程师大多性格内向,天然缺乏自我推销的意愿。 针对 Ian Cutress 提出的“是否也是从内向被迫学会外向”的提问,Jim Keller 坦言自己之所以学会表现得像个外向者,是因为他渴望操盘更大规模的工程项目: > “我决定去构建更大的工程项目,而要做到这一点,你必须假装自己是一个外向的人,并且学会推销自己。因为在决策层中,有大批人不会花精力去调查谁才是最优秀的架构师,他们只会去选大家公认的最佳人选、声音最大的人或是表面看起来最能干的人。” —— Jim Keller Jim Keller 总结道,一旦工程师想要打破职业天花板、晋升到主任工程师(Principal Engineer)及总监以上级别,就必须理解更高管理层的人际运行规则。在那个层级,有些天赋极高或擅长自我包装的人甚至不需要付出太多辛劳就能步步高升。技术人员要想在更高维度拥有话语权,就必须掌握跨界沟通与政治生态的运作方式,这并不是什么不可逾越的秘密,通过阅读莎士比亚(Shakespeare)的戏剧、荣格(Carl Jung)的心理学著作以及马基雅维利(Machiavelli)的理论,就能从中领悟大量关于人性与权力的运作规律。随后,访谈切入公众极为关切的巨头竞争话题,即英特尔、AMD 与苹果之间的多方角力。 ### [01:20:04](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4804s) 科技巨头的生态差异:苹果的封闭与 Intel/AMD 的开放 回顾自己在多家芯片巨头的职业生涯,Jim Keller 表示他非常享受在这些地方工作的经历。但对他而言,技术浪潮始终在向前涌动,他目前更着迷于 AI 初创公司以及下一代计算革命。谈及大公司的商业竞争,Keller 表现得十分超然:大企业有着自己的股价、董事会和产品路线图,它们自会去市场上拼杀,而他真正牵挂的是那些并肩作战过的工程师们。至于这些巨头下一步会做什么,他并不花太多心思去揣测,时间自然会揭晓答案。 在谈到苹果(Apple)与其他半导体厂商的区别时,Keller 指出苹果一直以来都极其闭合与内省,其面对公众的触点往往只是一个铝合金或玻璃外壳的精美盒子。他形容苹果“一直有点像个秘密会社”(“Apple's always been kind of a secret society”)。虽然苹果内部的工程师极其优秀,但他认为这种封闭文化让工程师们错失了参与更广泛技术社区与外部世界互动的机会。相比之下,Intel 和 AMD 制造并向广泛客户销售通用零部件,它们的产品要经受外界严格的性能实测、PCIe 通道数量对比以及 Bug 检验。因此,这些公司的工程师工作对整个技术生态的影响更为直接且触手可及。 - 苹果模式:以高度保密和垂直整合的终端消费电子产品为中心,工程师文化偏向内部封闭。 - Intel 与 AMD 模式:直接交付芯片组件,规格公开透明,工程师与公众及开发者社区的技术触点更广泛。 --- ### [01:21:40](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=4900s) AI 赋能芯片设计与人类不可理解的计算黑盒 针对 Ian Cutress 提出的疑问——未来的 AI 模型是否会设计出拥有数百万乃至数十亿晶体管、且复杂到人类工程师完全无法理解的专用芯片,Keller 给出了深入的剖析。他指出,目前顶级 AMD、Intel 或苹果芯片的复杂性对于任何单个个体来说,其实已经到了几乎无法完全掌握的程度;但两者存在本质区别:人类工程师逐层向下钻研时,依然能读懂 RTL 代码,看懂标准单元库(Cell Libraries)的逻辑。然而在深度神经网络中,如果去追问一个浮点权重为何恰好被训练成 `0.0015843`,人类是无法给出直观逻辑解释的。 Keller 借用了 Stephen Wolfram 对科学范式演进的论述,描绘了人类认知与计算工具的代际变迁: ```mermaid flowchart TD accTitle: 科学范式与计算抽象层的演进 accDescr: 展示从亚里士多德的解释物理学到牛顿的方程物理学,再到现代程序物理学以及 AI 黑盒计算的演进脉络。 subgraph Classical["科学范式的演进"] A["解释物理学<br/>(亚里士多德: 纯文字解释与直觉)"] --> B["方程物理学<br/>(牛顿/哥白尼: 紧凑精确的数学公式)"] B --> C["程序物理学<br/>(现代复杂系统: 难以用单一方程表达的代码模拟)"] end subgraph Modern["计算抽象层的演进"] D["底层物理实现<br/>(晶体管与手工电路图)"] --> E["高阶语言与 RTL<br/>(逻辑可读代码与标准单元库)"] E --> F["AI 驱动的设计与权重<br/>(不可解译的黑盒计算网络)"] end C -.-> F ``` Keller 认为,传统物理学通过观测落体加速度等现象并做曲线拟合,最终总结出简洁优美的方程式;即使到相对论的时空弯曲和量子力学的几率波,底层仍然是可理解的数学方程。然而,当今的机器学习直接将输入映射到输出,中间则是一个完全不透明的黑盒,其中根本不存在人类可读的物理方程。 > “就像斯蒂芬·沃尔夫勒姆(Stephen Wolfram)说过的非常有意思的话:最初是‘通过解释来构建的物理学’,那是亚里士多德,延续了 1500 年,结果他在一大堆事情上都搞错了;然后是‘通过方程来构建的物理学’,比如牛顿和哥白尼;而沃尔夫勒姆说,现在即将进入‘通过程序来构建的物理学’。”——Jim Keller Keller 预测,未来 AI 计算机可能会设计出下一代 AI 计算引擎,届时人类不仅不理解权重背后的物理意义,甚至连底层的数学架构或电路拓扑都无法参透。人类工程师的角色将退居到更高阶的抽象层,去定义系统目标与人类交互体验,正如昔日的芯片设计者从摆弄单个晶体管跃迁到了编写高级语言代码一样。 --- ### [01:26:14](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5174s) 硬件安全哲学:侧信道攻击与软件虚妄的安全边界 谈及近年来频发的 CPU 侧信道漏洞(Side-Channel Attacks)以及针对现代高性能处理器的各类攻击,Ian 询问 Keller 在做硅片设计时究竟采取主动预防还是被动响应的姿态。Keller 坦率地回答,芯片市场本身在定义安全需求,而安全领域最讽刺的一点在于:“只有当有人真正在乎它时,它才需要变得安全”(“it only has to be secure if somebody cares about it”)。 Keller 梳理了计算机安全防护的发展困境:早期操作系统依赖虚拟内存机制隔离不同进程,但由于操作系统本身的底层代码量极其庞大且复杂,攻击者总能诱使操作系统做出意外行为。这使得整个行业不得不从“依赖正确编写的软件来实现安全”,转向在硬件中强制构建硬性隔离屏障。现代处理器正在努力实现操作系统与用户数据之间的双向不可见,但每一次在硬件里塞入额外的安全边界,都在显著增加系统的整体复杂度。 > “每当有人说出‘这个系统是安全的,因为软件做了某某处理’时,我总会想:‘是啊,那就等上 10 分钟吧,软件马上就会变得更复杂,进而钻出新的漏洞来。’所以系统中必须存在实实在在的硬件物理边界。”——Jim Keller Keller 进一步指出了现实世界中安全的相对性与讽刺意味: - **隐蔽式安全(Security by Obscurity)的普遍性**:全球绝大多数人之所以安全,并非因为系统不可攻破,而是因为没有任何人对破解某个特定普通人的设备感兴趣。 - **硬件防护的开销**:在硅片上添加安全机制本身的面积和功耗开销通常很低,真正的难点在于前期的架构权衡与决策制定。 - **对“纯软件安全”的彻底怀疑**:由于软件会随着业务迭代无限膨胀,它最终一定会击穿最初的安全假设。最绝对的安全往往属于物理离线系统(Air-gapped Systems)——完全不与任何外界网络通信,任何黑客手段在此失效,唯一的破解途径只剩物理接触与门口的荷枪实弹。 --- ### [01:29:09](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5349s) 通用计算的伦理:净效益与潜在代价的权衡 当被问及此前为特斯拉(Tesla)打造专用自动驾驶芯片、以及在各大芯片厂商研发面向广泛场景的芯片时,是否会深入考量自己亲手设计的硅片会被用于何种用途及其背后的伦理道德风险,Keller 从通用计算处理器的根本属性给出了自己的回应。 他指出,通用计算(General Purpose Computing)最奇特也最本质的特征,在于它可以被用来运行任何可能的程序,承载人类几乎所有的行为。因此,芯片架构师无法穷尽每一个具体的终端使用场景,对其技术伦理的评判最终必须归结为一个宏观层面的大局衡量:“伦理的本质在于其带来的总体净收益是否大于总体净危害”(“the ethics is more a net good better than the net bad”)。Keller 坚定地表示,就绝大多数技术演进而言,芯片所释放的正面社会价值与生产力提升,远远胜过它可能带来的负面影响与潜在风险。 ### [01:29:53](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5393s) 人工智能的伦理困境与算力民主化 谈及芯片与技术对社会的影响,Jim Keller 坦言,公众对人工智能(AI)的发展确实抱有极大的担忧,业界也掀起了一股围绕“AI 伦理”的广泛讨论。在他看来,当前的 AI 能力发展极其迅速,其演进速度已经远远把人类关于伦理道德的深化思考甩在身后。现代 AI 系统能够洞察人类的想法、需求以及行为轨迹,其能力边界已经到了令人不安的地步。 Jim Keller 认为,打破技术垄断的关键在于研发低成本、可编程的 AI 硬件。如果算力资源被极少数寡头掌控,容易形成“赢家通吃”(winner-take-all)的极端局面;而通过让 AI 算力与硬件普及到更多软件初创企业和普通人手中,就能形成一种彼此制衡的“相互对峙”(mutual standoff)态势。谈及当前的技术走向,Jim Keller 总结道:“到目前为止,整体收益还是正向的,让技术掌握在更多人手中,总比集中在少数人手里要好,但我们还得看看事情最终会如何发展。” - **AI 伦理滞后**:现有 AI 算力与算法对人类行为、偏好与思维的洞察能力,已经大幅超出伦理规则的构建速度。 - **算力民主化**:Tenstorrent 与多家 AI 软件初创公司展开合作,致力于压低算力门槛,避免技术被极个别巨头彻底垄断。 - **产业竞争格局**:尽管现代科技领域具有“赢家通吃”的倾向,但目前市场上仍有数十家超大型科技企业处于激烈的竞争与制衡状态之中。 --- ### [01:31:27](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5487s) 与马斯克的关系及对加密货币本质的剖析 Ian Cutress 提到 Jim Keller 曾与 Steve Jobs 和 Elon Musk 等多位科技巨头共事,并指出在 2020 年的 Neuralink 发布会上,Jim Keller 与 Lex Fridman 一同出席,询问他目前是否仍与 Elon Musk 保持密切联系。Jim Keller 澄清说,自己当时是受 Neuralink 团队中一位工程师的私人邀请前去交流,自己与该研发团队很熟,现场讨论也非常尽兴;但在日常生活中,他目前与 Elon Musk 并没有太多联络,过去在特斯拉期间两人主要也是专注于工作的纯职业合作关系。 针对 Elon Musk 对加密货币(Cryptocurrency)的热捧以及加密资产消耗巨额算力却缺乏内在价值的争议,Jim Keller 表达了冷峻的客观态度。他认为人类是一种奇特的生物,无论黄金、法定货币还是加密货币,其价值完全建立在一种“共同信念的契约”(shared belief contract)之上。加密货币支持者所标榜的去中心化与脱离政府控制,在 Jim Keller 看来只是这种群体心理现象的又一个案例。 > “群体信念极其强大,它们能掀起货币狂潮,显然也能推动政治、催生企业、孕育技术、哲学乃至自我实现等等。因此这是个极其有趣的议题,但我对加密货币的技术细节并不太关心,除非把它看作群体信念心理现象的一种外在表现。” —— Jim Keller ```mermaid flowchart TD accTitle: 群体信念驱动价值机制 accDescr: 展示群体信念如何跨越不同载体赋予价值并在社会各个领域催生深远影响 subgraph BeliefCore["核心机制"] A["人类共同信念契约<br/>(Shared Belief Contract)"] end subgraph Manifestations["价值表现载体"] B["传统等价物<br/>(黄金 / 法定货币)"] C["新兴数字资产<br/>(加密货币)"] end subgraph Impacts["外溢驱动领域"] D["政治格局变迁"] E["商业与前沿技术驱动"] F["哲学与自我实现"] end A --> B A --> C A --> D A --> E A --> F ``` --- ### [01:33:47](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5627s) 超越硅基:光学、生物制造与量子极限的未来计算 针对人类在硅基半导体上耕耘超过 50 年后是否会撞上理论极限的问题,Jim Keller 满怀热情地回顾了计算载体的演进史:人类的计算设备最早始于算盘,随后历经机械继电器、真空电子管、晶体管,再到复杂的集成电路。当前的硅晶体管工艺已经演进到极为不可思议的高阶状态,但计算的物理可能性远不止于此。 在超越传统硅基的探索方向上,Jim Keller 点评了三大前沿领域: 1. **硅光子与光学计算**:研究人员已能通过多晶硅引导光路实现关键的信号切换。尽管业内过去一直戏称光学计算“永远还要再等十年”,但近期的实际进展正在加快。 2. **生物与分子计算**:生物学的制造成本优势极其悬殊。根据 Jim Keller 与一家蛋白质合成公司的精确测算,复制复杂生物分子的资金消耗比制造一颗半导体晶体管低约一亿倍(100,000,000 倍)。虽然现阶段芯片的光刻工艺拥有极高密度的严密空间互连排布,但生物系统具备惊人的“自组织”(self-organizing)能力,能精确引导蛋白质定位。 3. **量子计算**:物理学底层蕴藏着浩瀚的探索空间,正如理查德·费曼(Richard Feynman)所言“底层还有大把空间”(There's Plenty of Room at the Bottom)。Jim Keller 提到近期与一家量子计算初创团队的交流,对方正在尝试利用激光冷却并稳定原子,将其束缚在二维网格中充当量子比特。 Jim Keller 指出,未来甚至可能需要借助 AI 级的高阶算力,才能反向指导人类在原子尺度上进行重组与编程,从而打破现有的物理层限制。 - **微观成本差异**:生物复制蛋白质分子的单分子资产投入,比光刻制造晶体管的资金成本低整整 8 个数量级(约 1 亿倍)。 - **底层架构演进**:计算设备经历了“算盘 $\rightarrow$ 机械继电器 $\rightarrow$ 电子管 $\rightarrow$ 晶体管 $\rightarrow$ 超级集成电路”,硅基之后存在光子、量子态及生物分子等多元路径。 --- ### [01:36:31](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=5791s) 尾声与致谢 在访谈的最后,Ian Cutress 对 Jim Keller 抽出大量时间进行深度对话表达了诚挚感谢。Ian 笑着提到自己手头其实还准备了足足 20 个追问,可惜受限于时间无法一一探讨。Ian 再次向 Jim Keller 送上祝福,祝愿他在 Tenstorrent 的全新征程中取得突破,并期待看到该团队未来推出的全新芯片架构。Jim Keller 也高兴地向 Ian 道别,整场深度访谈在轻松愉悦的氛围中圆满收尾。 ## Notable quotes > [31:46](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1906s) Every time you violate the abstraction layer, you've created a problem for future Jim. — Jim Keller > [36:32](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2192s) If you want to build something bigger and more complicated, you better solve the abstraction layers, because people aren't smarter. — Jim Keller > [47:45](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2865s) 充满相互信任的团队,其效率要远远高于那些凡事都得靠合同、谈判和政治手段来解决的团队。 — Jim Keller > [07:16](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=436s) When you make a computer faster, there's two ways to do it: you make the fundamental structure bigger, or you tweak features. — Jim Keller > [19:44](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=1184s) What limits computer performance is predictability — Jim Keller > [49:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2977s) 当你在做全新的事情,而且为之工作的上司比你懂得多得多时,你的学习速度是最快的。 — Jim Keller > [54:37](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=3277s) 读四本书就想改变人生很难,因为有时一本书确实能改变你;但读一千本书一定会改变你的人生,这是毫无疑问的。 — Jim Keller > [44:01](https://www.youtube.com/watch?v=AFVDZeg4RVY&t=2641s) 如果你走进一家拥有一千名员工的公司,我敢向你保证,那里肯定有一支优秀的团队,你根本不必去招人。 — Jim Keller ## Mentioned Jim Keller, Ian Cutress, AMD, Intel, Apple, Tesla, Tenstorrent, DEC, Broadcom, SiByte, PA Semi, Zen, Zen 2, Zen 3, K12, SkyBridge, Bulldozer, Jaguar, Excavator, Infinity Fabric, HyperTransport, Mike Clark, Leslie Barnes, Jay Fleischman, Mark Papermaster, Suzanne Plummer, Steve Hale, Harry Fair, Ljubisa Bajic, Hardware 3, Pat Gelsinger, Bob Swan, VAX 8800, Hurricane, x86, Arm, RISC-V, AVX, NVIDIA, EV6, Dirk Meyer, Kurosh Kowshik, ASML, Applied Materials, TSMC, Samsung, Richard Feynman, Ken Olsen, Bob Stewart, Butler Lampson, Chuck Thacker, Nancy Kronenberg, Gordon Bell, Carl Jung, Venkatesh Rao, Doris Lessing, Becky Loop, Stephen Wolfram, Elon Musk, Steve Jobs, Neuralink, Lex Fridman ## Video description Was Jim Keller really 'the father of Zen'? In this wide-reaching interview, Jim talks to Ian about his time at AMD, Intel, and others, along with a variety of management technique advice, how to approach design, the future of Moore's Law, which instruction set matters (x86 vs Arm), but also the intersection between maturity and experience. Written version of the interview is on AnandTech https://www.anandtech.com/show/16762/an-anandtech-interview-with-jim-keller-laziest-person-at-tesla Jim Keller is currently CTO of Tenstorrent, a 2016 AI startup that recently secured $200m of Series C funding to go build their 4th/5th generation processors. I recently interviewed CTO Jim and CEO Ljubisa about Tenstorrent as well as the relationship between the two, which comes back to their time at AMD together. https://www.youtube.com/watch?v=sMvudTBBQNw 0:00 Interview Part 2 0:32 Q1: What Jim Did at AMD 5:16 Q2: Father of Zen? 7:16 Q3: Everything from AMD is out? 8:41 Q4: Zen 3 a rewrite? 9:52 Q5: Is Tenstorrent a Forever Home? 13:21 Q6: What Jim Did at Intel 15:57 Q7: Would Jim Go Back to Intel? 16:38 Q8: Has it ever got boring? 18:24 Q9: Do Engineers Need People Skills? 19:44 Q10: Arm vs x86 vs RISC-V Pt 1 23:42 Q11: The right compute point for AI 25:47 Q12: Adding Vectors to AI 26:48 Q13: Arm vs x86 vs RISC-V Pt 2 29:11 Q14: Too much bloat? 30:24 Q15: Would x86 ever die? 32:33 Q16: Abstraction Layers in Life 37:49 Q17: Is Jim Worried about Moore's Law? 41:55 Q18: Beyond EUV Lithography 44:00 Q19: How to build a team 47:45 Q20: Teams and Company Culture 49:37 Q21: Recommendation for Early Career 50:22 Q22: Jim's Mentors 54:37 Q23: Understanding People 56:05 Q24: Reading more than others 58:33 Q25: Passive Jim Keller bookclub 59:22 Q26: Making sure you absorb information 1:01:43 Q27: Managing time 1:03:44 Q28: Doing interviews, marketing, 'talk' 1:06:12 Q29: Jim's Superpower? Nature vs Nurture? 1:08:52 Q30: How To Mentor People 1:13:03 Q31: Proudest Moments 1:17:21 Q32: Silent Heroes and Self-Promotion 1:19:48 Q33: Intel vs AMD, Intel vs Apple 1:21:40 Q34: AI Enabling Chip Design 1:26:14 Q35: Proactive or Reactive Security 1:29:09 Q36: Ethics of Chips Built 1:31:27 Q37: Elon, Neuralink, Cryptocurrency 1:33:47 Q38: Going Beyond Silicon 1:37:00 Cat Tax Welcome to the TechTechPotato (c) Dr. Ian Cutress Ramblings about things related to Technology from an analyst Patreon helps support this channel: https://www.patreon.com/TechTechPotato Also available through Patreon is special 1-on-1 consulting for the financial services industry! Many thanks to our CPU CEO Patrons Support the channel by hitting that subscribe button, or using our Amazon affiliate link. Please note that TTP may receive a commission if you purchase anything through these links Intel Core i7-11700K (8C/16T): https://geni.us/SreZM Intel Core i5-11600K (6C/12T): https://geni.us/T4WG Intel Core i5-11400F (6C/12T): https://geni.us/6UISblx AMD Ryzen 9 5950X (16C/32T): https://geni.us/5950X AMD Ryzen 9 5900X (12C/24T): https://geni.us/5900X AMD Ryzen 7 5800X (8C/16T): https://geni.us/5800X AMD Ryzen 5 5600X (6C/12T): https://geni.us/5600X Intel Core i9-10900K (10C/20T): https://geni.us/Bench2020-10900k Intel Core i7-10700K (8C/16T): https://geni.us/Bench2020-10700K AMD Ryzen 9 3950X (16C/32T): https://geni.us/Bench2020-3950x AMD Ryzen 7 3700X (8C/16T): https://geni.us/Bench2020-3700x AMD Ryzen 5 3600 (6C/12T): https://geni.us/d08ThJ4 Follow Ian on Twitter at http://twitter.com/IanCutress Follow TechTechPotato on Twitter at http://twitter.com/TechTechPotato #techtechpotato #jimkeller #ianinterviews [Source](https://www.youtube.com/watch?v=AFVDZeg4RVY)

Source quotes

[31:46] Jim Keller: Every time you violate the abstraction layer, you've created a problem for future Jim. [36:32] Jim Keller: If you want to build something bigger and more complicated, you better solve the abstraction layers, because people aren't smarter. [47:45] Jim Keller: 充满相互信任的团队,其效率要远远高于那些凡事都得靠合同、谈判和政治手段来解决的团队。 [7:16] Jim Keller: When you make a computer faster, there's two ways to do it: you make the fundamental structure bigger, or you tweak features. [19:44] Jim Keller: What limits computer performance is predictability [49:37] Jim Keller: 当你在做全新的事情,而且为之工作的上司比你懂得多得多时,你的学习速度是最快的。 [54:37] Jim Keller: 读四本书就想改变人生很难,因为有时一本书确实能改变你;但读一千本书一定会改变你的人生,这是毫无疑问的。 [44:01] Jim Keller: 如果你走进一家拥有一千名员工的公司,我敢向你保证,那里肯定有一支优秀的团队,你根本不必去招人。

Source quotes

[54:37] Jim Keller: You'd be better off reading Carl Jung than Good to Great if you want to understand management. [19:44] Jim Keller: Eighty percent of the execution is like six instructions: load, store, add, subtract, compare, and branch. [47:45] Jim Keller: And teams that trust each other are way more effective than ones that have to do everything with contracts, negotiation, and politics. [49:37] Jim Keller: You learn fastest when you're doing something new working for somebody that knows way more than you. [68:52] Jim Keller: The best way to have status is to do something great and everybody thinks you're great; having status by trying to claw your way up is terrible because everybody thinks you're a climber. [77:21] Jim Keller: I decided I wanted to build bigger projects and to do that you have to pretend to be an extrovert and you have to promote yourself.

Original transcript

[0:00] hi everyone you join me on a very [0:02] special occasion this is part two of our [0:04] interview series with [0:05] jim keller he is currently cto of a new [0:08] ai company called tens torrent [0:10] but in the past he's worked at dec apple [0:13] amd intel uh broadcom cybite tesla [0:18] jim am i missing anything there uh i [0:20] worked at amd twice [0:22] oh yes that's true so [0:25] don't know what to make of that i think [0:28] i have a couple of questions [0:29] uh for you about that it's uh i wanna [0:32] actually let's start with that that's a [0:34] good place to start right it's [0:36] um a lot of audience a lot of my [0:38] audience at least know you from your [0:39] work [0:40] um at amd on the zen the sky bridge [0:44] platform and you know now amd's gaining [0:46] market share with their product line and [0:48] you're off on to bigger and better [0:50] things but there's been a lot of [0:51] confusion as to your exact role [0:53] at amd during that project you know some [0:56] people believe you're integral in [0:58] nailing down [0:59] zens and twos and three high level micro [1:01] architecture [1:03] others believe you put people in place [1:05] signed off at high level [1:06] then focused on the armed version the [1:08] sky bridge k12 [1:10] so can you give a any clarity as to your [1:12] role there you know how deep you went [1:14] with zen versus k-12 or your involvement [1:16] in things like infinity fabric [1:20] yeah it's uh well it was it was a [1:22] complicated project right because [1:25] amd when i joined they had bulldozer and [1:26] jaguar and they both had [1:28] you know some charming features but they [1:30] weren't successful in the market [1:32] and the road maps weren't aggressive [1:35] they were falling behind intel and so [1:38] that's not a good thing to do if you're [1:40] already behind then you better be [1:41] catching up not falling behind [1:44] so i took the role i was president of [1:47] the cpu team [1:48] which i think when i joined was 500 [1:49] people [1:51] and then over the next three years you [1:54] know the soc team the fabric team [1:56] some ip teams joined my my little gang [1:59] i think when i left it was 25 2 400 [2:03] people [2:03] i was told so it was you know so i was a [2:06] vp [2:07] with you know a staff right so i had [2:09] senior directors reporting to me and [2:11] senior fellows and my staff was like 15 [2:14] people [2:16] so i was i was hardly writing rtl [2:19] well that's you know that said um [2:23] but we had a whole bunch of things so [2:26] like i'm a computer architect not really [2:28] a manager [2:28] um i i wanted the management [2:32] role which was the biggest management [2:34] role i'd had at the time [2:36] i'd been you know the vp of a startup [2:38] but that was 50 people and we all got [2:39] along and [2:40] so this was a fairly different play for [2:44] me [2:45] but i knew that the technical changes we [2:47] had to make [2:48] would be involved in getting people [2:49] aligned to it and i didn't want to be [2:52] the architect on the side arguing with [2:53] the vp about why somebody [2:55] could or couldn't do the job or why this [2:57] was the right or wrong decision [2:59] so mark papermaster i told him my theory [3:03] and he said [3:03] okay you know we'll give it a try [3:06] and uh it worked pretty good because [3:09] then i had [3:10] let's say direct authority [3:13] as it were but people don't really do [3:15] what they're told to do right [3:17] they're do they do what they're inspired [3:19] to do [3:20] right and so you have to lay out a plan [3:22] and [3:23] part of it was finding out like who are [3:25] the right people you know to do [3:27] different things and [3:28] sometimes somebody's really good but [3:29] their ideas like people get very [3:31] invested in what they did last time or [3:33] they believe things can't be changed [3:36] and i would say my my view was [3:40] things were so bad that almost [3:42] everything had to change [3:44] and so i i went in that with that as a [3:47] default thing [3:49] does that make sense now it wasn't that [3:51] we didn't find a whole bunch of stuff [3:53] that was good to use but [3:55] you know you had to prove that the old [3:56] thing was good as opposed to prove the [3:58] new thing was [3:59] was good so we changed that mindset [4:03] architecturally i had a pretty good idea [4:06] what i wanted to build [4:07] and why and i found people inside the [4:10] company mike clark leslie barnes [4:13] j fleischmann there are quite a few [4:16] debjit [4:17] now there's quite a few really great [4:19] people [4:20] that once we described what we wanted to [4:22] do they're like yeah we want to do that [4:24] and like architecturally [4:28] i had some input there was often [4:30] decisions analysis [4:33] uh people had different opinions i was [4:35] fairly [4:36] hands-on doing that but again i wasn't [4:39] doing block diagrams writing rtl [4:42] and uh i had yeah we had multiple [4:45] projects going on you know with zen [4:47] there was the the arm the arm cousin of [4:50] that [4:51] the follow-on that integrated them both [4:53] there was some new ssc methodology [4:56] but we we we did more than just cpu [4:59] design we did methodology design [5:01] ip refactoring uh [5:05] very large organizational changes [5:08] and i was like hands on top to bottom [5:13] with all that stuff does that make sense [5:17] sure it's uh a few people consider you [5:19] the father of zen [5:21] do you think you ascribe to that that [5:24] position or should that go to somebody [5:25] else [5:26] yeah or one of the uncles you know you [5:28] know [5:30] there was a relationship a lot of really [5:32] great people on zen [5:34] so and it was built you know there was a [5:36] methodology team that was worldwide the [5:39] soc team was [5:40] partly in austin and partly in india [5:44] the floating point in cash was done in [5:46] colorado the [5:47] core execution front end was in austin [5:50] the armed front end was in sunnyvale [5:54] we had good technical leaders [5:57] you know i was in daily communication [5:59] for a while with suzanne and steve hale [6:01] who [6:01] who kind of built the front end of this [6:03] encore and the colorado team so [6:06] like there was a really good people mike [6:08] clark's a great architect [6:10] um yeah so we had a lot of fun [6:14] and uh you know success success has a [6:16] lot of authors failures as one so that [6:18] was the success so let's [6:20] and then some other you know team [6:22] stepped up we uh [6:24] moved excavator to the boston team where [6:27] they took over the finishing the design [6:28] and the physical stuff [6:30] harry fair and his guys did a great job [6:31] on that um so there was some fairly [6:35] stressful organizational changes that we [6:37] did [6:38] going through that and you know the team [6:40] all came together so [6:42] yeah i think there was uh there was a [6:44] lot of camaraderie in it [6:46] so i don't claim to be the [6:49] i was brought you know the instigator [6:50] and the chief nudge [6:53] and you know part architect part you [6:55] know it's a [6:57] transformational leader and it was fun [7:02] was everything that you did during that [7:04] time [7:08] sorry go ahead no you have [7:11] there's a little bit of a lag between [7:12] here and yeah whatever country you're in [7:15] right now [7:17] i was going to say was so is everything [7:19] that you worked on now [7:20] out amd or is there still you know kind [7:22] of road map stuff still to come out do [7:24] you think from the ideas [7:26] that you helped propagate so [7:30] when you build a new computer and zen [7:33] was a new computer [7:34] there was already work underway on what [7:37] they called sock 15 which is the new [7:39] fabric and bus [7:41] you build in basically a road map [7:44] right yeah so i was thinking about you [7:46] know what are we going to do for five [7:48] years [7:49] like chip after chip and you know we did [7:52] this at apple too when we [7:54] built the first big chord apple we built [7:56] big bones [7:57] right so you can't when you make a [8:00] computer faster is two ways to do it you [8:02] make the [8:03] fundamental structure bigger or you [8:05] tweak features [8:07] and zen had a big structure and then [8:10] there was obvious things to do [8:12] for several generations of follow-up [8:15] and and they've they've been following [8:17] through on that [8:19] so at some point you'll have to do [8:21] another big [8:22] you know rewrite and change i don't know [8:25] if they started that yet [8:27] um what we had planned for architectural [8:30] performance improvements were fairly [8:31] large [8:32] over a couple of years and they seemed [8:35] to be doing a great job [8:36] executing to that but yeah i've been out [8:39] there for a while four or five years [8:40] though [8:41] yeah yeah it's it's i think they they [8:44] said that zen three the last one that [8:45] just came out was a rewrite [8:47] so i think some people are thinking that [8:49] that was still under [8:50] your direction yeah it's hard to say you [8:54] know [8:54] like even when we did zen like we did a [8:57] clunk [8:58] from scratch design clean design at the [9:00] top [9:01] but then when they built it there was a [9:03] whole bunch of pieces of rtl that came [9:05] from bulldozer and jaguar which were [9:06] perfectly good [9:08] they just had to be modified and built [9:10] into the new zen structure [9:12] so so hardware guys are super good at [9:14] using code [9:15] when it's boots them and so when they [9:18] say they did a big rewrite [9:21] you know they probably took some pieces [9:22] and you know re-architected them at the [9:24] top but when they built the code [9:27] you know it wouldn't surprise me [9:28] somewhere between 20 and 80 [9:30] of the code was the same stuff or mildly [9:33] modified [9:34] but that's that's pretty normal the key [9:37] is to get the structure right [9:40] and then reuse code as needed as opposed [9:42] to taking something that's complicated [9:45] and [9:45] trying to tweak it to get somewhere so [9:48] if they did a rewrite they probably [9:49] meant they fixed the structure so i mean [9:53] moving on from that you're you're [9:54] several companies on you're now a [9:56] company called tens torrent um with with [9:59] an old friend of the bishop basic [10:01] um but you've been jumping from company [10:04] to company each company [10:06] you know for for basically your whole [10:08] career you're always finding [10:09] another project another opportunity [10:11] another angle [10:13] not to be too blunt but is tense torrent [10:15] gonna be a forever home [10:18] well first you know i was a digital for [10:20] 15 years [10:22] right now yeah that was two different [10:24] careers because [10:25] i was in the mid-range group where we [10:27] built computers out of echo [10:28] ucl you know they were [10:30] refrigerator-sized boxes and i was in [10:32] the [10:33] alpha team where we built little [10:35] microprocessor little teeny things [10:37] right which at the time we thought were [10:39] huge you know 300 square millimeters at [10:41] 50 watts just blew everybody's mind [10:44] and so i was there for a while um [10:47] i went to amd right during the internet [10:50] rush and we did a whole bunch of stuff [10:53] in a couple years you know we started [10:55] out there on [10:56] hyper transport two-piece servers [10:59] like it was kind of a whirlwind of a [11:01] place [11:02] but you know i got sucked up or caught [11:04] up in the enthusiasm of the internet and [11:06] i went to scibite [11:08] which got bought by broadcom and i was [11:09] there for four years total [11:12] and we delivered several generations of [11:14] products and then it was [11:15] at pa semi and uh we delivered a great [11:19] product [11:20] um but they didn't really want to sell [11:23] the product for some reason [11:24] or they thought they were going to sell [11:25] it to apple so i actually went to apple [11:27] and then apple [11:28] bought pa sent me and then i worked [11:30] without teams i was you know between [11:32] pa semi and apple that was seven years [11:35] so i don't really feel like that was [11:37] jumping around too much then i jumped to [11:39] amd [11:41] i guess and that was fun for a while [11:44] and uh then i went to tesla where we [11:46] delivered hardware three [11:48] so that was you know kind of phenomenal [11:51] standing start to driving the car in 18 [11:53] months i don't think that's ever been [11:54] done before [11:56] and that product shipped really [11:57] successfully they sold they built a [11:58] million of them last year [12:00] um in tesla and then you know intel was [12:04] a different kind of whirlwind [12:06] so now you could say i jumped in and [12:08] jumped out but [12:10] i i sure had a lot of fun with him [12:13] so so yeah i've been around a little bit [12:17] um i like to think i mostly get done [12:20] what i set out to accomplish [12:22] you know my success right there is [12:24] pretty high [12:26] in terms of you know delivering products [12:28] that you know have lasting [12:30] value i'm not the guy to tweak things in [12:34] production [12:35] i like either a clean piece of paper or [12:37] a complete disaster [12:39] you know that seems to be the the things [12:42] i do best at [12:44] it's good to know yourself i'm not an [12:46] operational manager [12:48] um so tense torrent is is more the clean [12:52] piece of paper ai space is exploding [12:55] the company itself is already many years [12:57] old um [12:58] but we're building a new generation of [13:00] parts and and going to market and [13:02] starting to sell stuff [13:05] uh i'm cto and president i have a big [13:09] stake in the company both [13:10] you know financially and and also [13:13] i say uh commitment wise to my friends [13:16] there [13:18] so i plan on being here for a while [13:21] but uh that sounds good uh if if i can [13:24] just cycle back one [13:26] um i know it's still kind of fresh so [13:28] i'm not sure what kind of ndas you're [13:29] still under [13:31] um but your work at intel was that more [13:34] sort of a clean slate [13:35] or can you sort of go into any detail [13:37] about what you did there [13:39] you know beyond the sort of pr stuff [13:41] that we've all had [13:42] i can't talk too much obviously the the [13:45] role i had was senior vice president of [13:47] silicon [13:48] engineering group and the team was 10 [13:50] 000 people [13:51] so they're doing so many different [13:52] things it's just amazing it was [13:54] something like [13:55] 60 or 70 socs in flight at time [13:58] literally from you know design to you [14:01] know [14:01] prototyping debugging and production so [14:04] it was a fairly diverse group [14:06] and there my staff was you know vice [14:08] presidents and senior fellows [14:10] so it was a big organizational thing [14:13] i had thought i was going there because [14:15] there was a bunch of new technology to [14:17] go build [14:18] i spent most of my time working with the [14:21] team about [14:22] both organizational methodology [14:24] transformation [14:25] like new cad tools new methodologies new [14:28] ways to build chips [14:29] a couple years before i joined they [14:30] started what's called the [14:32] you know socip view of building chips [14:35] versus intel's historic monolithic view [14:38] and that to be honest wasn't going well [14:42] because they took the monolithic chips [14:44] like they built great client and server [14:45] parts [14:46] and broke it into pieces but you can't [14:49] just break it into pieces you have to [14:50] actually rebuild those pieces [14:52] and some of the methodology goes with it [14:55] and [14:56] yeah we we found a bunch of people were [14:58] really excited about working on that [15:00] you know i spent a lot of time on you [15:02] know quality ip quality density [15:04] libraries characterization process [15:06] technology [15:08] like you name it it was my my days were [15:11] kind of wild [15:12] like some days i have 14 different [15:14] meetings in one day [15:16] you know just be click click click click [15:18] because there's so many things going on [15:20] all those meetings how did you get [15:21] anything done i don't get anything done [15:23] like i told you i was i was the senior [15:25] vice president [15:27] you know it's like evaluation set [15:28] direction make judgment calls [15:31] uh you know let's say try some [15:34] organizational change people change [15:37] and you know that adds up after a while [15:40] you know the key thing about getting [15:41] somewhere is knowing where you're going [15:42] and then put an organization in place [15:44] that knows how to do that [15:46] and that takes a lot of work yeah so i [15:48] didn't write much [15:49] code but i did send a lot of text [15:52] messages [15:54] that kind of code right i mean [15:58] intel now has a new sort of uh [16:00] engineering focus ceo and pat gil singer [16:02] would you ever consider going back if [16:04] the right opportunity came up [16:07] i don't know i have a really fun job [16:10] and a really you know explosive growth [16:12] market [16:13] so i wish him the best you know i think [16:16] i i think it was a good choice i hope [16:18] it's a good choice uh we'll we'll see [16:20] what happens [16:21] he definitely cares a lot about intel [16:23] and he's had real success in the past so [16:26] he's definitely going to bring a lot [16:27] more technical focus [16:29] to the the company um but i like working [16:33] with bob swan just fine so he was [16:35] you know we'll see what happens [16:39] i mean if i go through your career it's [16:41] you've kind of you know gone between [16:43] high performance computing and [16:45] you know low powered efficient computing [16:48] and now you're in this sort of [16:49] world of you know ai acceleration [16:52] um has it ever got boring [16:56] no no it's really weird well [16:59] it's changing it's changed so much and [17:01] at some level it doesn't change at all [17:03] like computers at the bottom they just [17:05] you know you add ones and zeros together [17:07] you know it's like it's pretty easy zero [17:09] one one zero [17:10] one one one zero zero it's it's not that [17:13] complicated but [17:15] you know i work on the vex 8800 where we [17:17] built it out of gatorades that had [17:19] 200 or gates of each chip like [17:22] 200 right and now when [17:26] at 10 store like our little computers [17:28] are we call them tencit cores are four [17:30] trillion operations a second per core [17:33] and there's a hundred of them [17:35] so like the building block shifted from [17:37] you know [17:38] 200 gates to four terraps so that's kind [17:42] of that's kind of a wild transformation [17:44] and then the tools are way better than [17:46] they used to be like what you can do now [17:48] like you can't build more complicated [17:49] things unless you know the abstraction [17:51] levels change and the tools change [17:53] and there's been so many changes on that [17:55] kind of stuff and [17:57] when i was a kid i used to think i had [17:58] to do everything myself and you know i [18:01] worked like a maniac and coded all the [18:03] time and [18:04] and now i am you know i know how to work [18:06] with people and organizations and [18:07] listen you know stuff like that you know [18:10] people skills [18:13] like i probably get a pretty uneven [18:15] scorecard on the people skills but [18:18] um i do have a few and uh that's [18:21] interesting [18:24] would you say that engineers need more [18:26] people skills these days because [18:28] everything's complex everything's got [18:30] separate abstract layers and if you want [18:31] to work between them and [18:35] yeah now so here's the here's the [18:37] fundamental truth [18:39] people aren't getting any smarter right [18:42] so [18:43] people can't work across more things [18:45] that's just that's dumb [18:47] right you do have to build [18:50] tools and organizations that support [18:52] people's ability to do complicated [18:54] things [18:55] right so like like it's interesting the [18:59] vax 8800 team was like 150 people [19:02] and the team that built uh first [19:04] processor at apple [19:06] hurricane that was in the a but the the [19:09] first big processor i guess the second [19:11] custom apple core um was 150 people [19:16] now the cat tools were unbelievably [19:18] better we used [19:20] thousands of computers to do simulations [19:23] we had tools that could place and route [19:24] 2 million gates versus [19:26] 200 you know so some things changed [19:29] radically but [19:30] the number of people an engineer talked [19:33] to in a given day didn't change at all [19:36] like if you have an engineer talk to [19:37] more than five people a day they'll lose [19:39] their minds [19:40] you know so they you know some things [19:42] are really constant [19:44] in terms of that constant idea [19:47] you've you've spoken about um cpu [19:51] instruction sets [19:52] in the past um and one of the biggest [19:55] requests for this interview i got was [19:57] around your opinion about [19:58] cpu instruction sets um you know [20:01] specifically how we deal with [20:02] fundamental limits on them how we pivot [20:04] to better ones [20:06] you know and what's your skin in the [20:08] game in terms of your arm versus x86 [20:10] versus risk five [20:11] i think at one point you said most [20:14] compute happens on a couple of dozen [20:15] opcodes so [20:16] iso doesn't matter am i remembering that [20:19] correctly it's a very sad story [20:21] yeah yeah yeah yeah no it's not even a [20:23] couple of dozen eighty percent of the [20:24] execution is like six instructions [20:27] you know load store add subtract compare [20:29] and branch [20:30] you pretty much covered it you know if [20:32] you're writing in [20:34] you know pearl or something you know [20:36] maybe maybe call and return are more [20:38] important than [20:38] compare and branch but you know [20:42] instruction sets only matter a little [20:43] bit [20:45] right you can lose 10 or 20 because [20:47] you're missing instructions or [20:49] you know for a while we thought variable [20:51] length instructions were really hard to [20:53] decode [20:54] but we keep figuring out how to do that [20:56] you basically predict where all the [20:57] instructions are in tables and once you [20:59] have good predictors you can predict [21:01] that stuff well enough [21:02] so fixed length instructions seem really [21:04] nice when you're building little baby [21:06] computers but [21:07] you're building like a really big [21:08] computer the predictor to figure out [21:10] where all the instructions are [21:12] isn't dominating the die so it doesn't [21:15] doesn't matter [21:16] that much and when risk first came out [21:19] an x86 was half microcode so if you look [21:22] at the die [21:23] half the chip was a rom there may be a [21:25] third or something [21:27] and the risk guys could say there's no [21:28] rom and a wrist chap so we get more [21:30] performance [21:31] but now the rom is so small you can't [21:32] find it actually the adder is so small [21:35] you can hardly find it [21:37] right so what limits computer [21:40] performance is predictability [21:43] and the two big ones are you know [21:44] instruction predictability and [21:46] branch predictability and and data [21:48] locality [21:50] and now the new predictors are really [21:52] good at that [21:54] they're big like the predictors are way [21:56] bigger than the adder [21:58] right and that's where the you get into [22:00] the the cpu versus like gpu or ai [22:03] engine debate yeah like the gpu guys [22:05] will say look there's no branch [22:07] predictor because we do everything in [22:08] parallel [22:10] so the chip is way more adders and [22:12] subtractors [22:14] and that's true if that's the problem [22:15] you have but they're they're crap at [22:17] running c [22:17] programs yeah it's yeah it's about [22:20] crafting the software or the compile [22:22] time right [22:23] if you can do that well then and then [22:25] gpus were built to run [22:27] shader programs on pixels so you're [22:29] given like eight million pixels and so [22:32] you know the big gpus now have six [22:34] thousand threads [22:35] so you can cover all the pixels with [22:37] each one of them running you know a [22:38] thousand [22:39] programs per per frame but it's sort of [22:42] like [22:44] you know an army of ants carrying around [22:46] grains of sand [22:48] whereas big ai computers they have [22:50] really big [22:51] matrix multipliers and like a much [22:54] smaller number of threads essentially [22:56] that do a lot more math because the [22:58] problem is inherently big [23:00] whereas whereas you know the shader [23:03] problem was the problems were inherently [23:04] small because there were so many pixels [23:07] so there's genuinely three different [23:10] kinds of computers [23:11] cpus gpus and ai and then nvidia is kind [23:15] of doing the tweener thing where they're [23:16] using a gpu to run ai [23:18] and they're trying to enhance it and [23:20] some of that's obviously working [23:22] pretty well and some of it's obviously [23:23] fairly complicated [23:25] and so it's an interesting and this [23:28] happens a lot like [23:29] like general purpose cpus when they saw [23:31] the vector performance of gpus added [23:33] vector units [23:34] and sometimes that was great because you [23:35] only had a little bit of vector [23:36] computing to do [23:38] but if you had a lot a gpu might be a [23:40] better solution [23:42] it's i think you've said you said before [23:44] that going beyond the sort of matrix you [23:47] end up with your sort of massive graph [23:49] structures especially for ai and ml and [23:51] the whole point about tens torrent is [23:53] it's a graph compiler and a graph [23:55] compute engine not just a simple matrix [23:57] multiply [23:59] yep yeah so there's you know [24:03] from from old math now i'm a [24:05] mathematician so mathematicians are [24:07] going to cringe a little bit but [24:08] you know there was scalar math like a [24:10] equal b plus c times d [24:13] right and when you had a small number of [24:14] transistors that's the all the math you [24:16] could do yeah now we got more [24:18] transistors and you could say hey i can [24:20] do a vector of those [24:22] like an equation properly in a step and [24:25] then we got more transistors we could do [24:27] a matrix [24:28] like multiply right and then as we got [24:31] more [24:32] transistors you sort of wanted to take [24:35] those big operations and break them up [24:37] because [24:38] if you make your matrix multiplier too [24:39] big the power of just getting across [24:41] it's a waste of energy so you want you [24:44] find you want to build [24:45] this optimal size block it's not too [24:47] small like a [24:48] like a thread and a gpu but it's not too [24:51] big like [24:52] covering the whole chip with one matrix [24:53] multiplier would be a really dumb [24:55] idea from a power idea so then you get [24:58] this array of [24:59] medium sized processors where medium is [25:01] something like four tera ops [25:04] like that's which is hilarious to me by [25:06] the way because i remember [25:08] when that was a really big number [25:11] and once you break that up now you have [25:13] to take the big operations [25:15] and map them to the array of processors [25:18] and ai looks like a graph of very big [25:22] operations [25:22] it's still a graph and then the big [25:25] operations are factored down into [25:27] smaller graphs [25:29] now you got to lay that out on the chip [25:30] with lots of processors and have the [25:32] data flow around it [25:34] and that seems to be a very different [25:36] kind of computing than running a vector [25:38] or matrix program [25:39] so let's call it you know scalar vector [25:42] matrix roger and i used to call it [25:43] spatial [25:44] i would say graph would probably be a [25:45] better word [25:47] and then uh correct me if i'm wrong but [25:49] you're putting in vector engines into [25:51] your graph [25:52] chord next-gen so it's becoming this [25:55] general purpose cpus [25:57] that have vector engines on them yeah [25:59] and that turns out to be [26:00] um when you're running ai programs [26:04] there's some general purpose computing [26:05] you just want [26:07] and then there's sometimes in the graph [26:08] where you want to run a c program on the [26:10] result of a [26:12] ai operation and having that stuff be [26:15] tightly coupled is nice [26:16] actually on the same chipset the latency [26:18] is super low and the power to get back [26:20] and forth [26:21] is reasonable so yeah we're we're [26:24] working on an interesting roadmap for [26:26] that [26:27] and by the way that's that's a little [26:28] computer architecture architecture [26:30] research [26:31] area like what's the right everybody has [26:33] this idea what's the right mix with [26:35] you know accelerated computing and [26:37] general purpose computing and [26:38] how are people using it and how do you [26:41] build it in a way programmers can [26:42] actually use it [26:44] right that's that's the trick which [26:46] we're working on [26:48] so many people are asking you what do [26:50] you think about arm versus x86 [26:52] you know which one has the legs which [26:54] one you know as to performance [26:56] do you do you care much um [27:00] i care a little like here's what [27:02] happened so when x86 first came out it [27:04] was super simple and clean [27:06] right and then at the time there was [27:08] multiple 8-bit architectures x86 the 80 [27:11] 6800 6502 [27:13] i programmed probably all of them way [27:16] back in the day [27:17] and then x86 oddly enough was the open [27:20] open version right they they licensed [27:23] that to seven different companies [27:25] and then that gave people opportunity to [27:28] put in tape but [27:29] intel surprisingly was both licensed it [27:32] in one [27:32] long run but then they went to 16 bits [27:35] and 32 bits and then [27:37] they added virtual memory virtualization [27:39] security [27:40] 64 bits and then more features so what [27:44] happens to an architecture is [27:45] as you add stuff you know you keep the [27:48] old stuff so it's compatible [27:50] so when arm first came out it was a [27:52] clean 32-bit computer [27:55] and compared to x86 it just looked like [27:57] you know [27:58] way simpler and easier to build but then [28:01] they added a 16-bit mode [28:03] and the it instruction which is awful [28:05] and a kind of a weird floating point [28:07] vector extension set with overlays and a [28:09] register file and then 64 bits [28:12] which partly cleaned it up and they [28:14] added you know [28:15] there was some special stuff for [28:16] security and booting and [28:19] you know so it slowly got more [28:20] complicated now risk five shows up and [28:22] it's [28:23] it's the shiny new cousin right because [28:25] there's no legacy [28:27] and it's actually an open instruction [28:29] set architecture [28:30] and and people build in universities [28:33] where they didn't [28:34] have time or interest to add too much [28:36] junk like some architectures have [28:38] so relatively speaking just because of [28:41] its pedigree [28:43] and age it's early in the life cycle of [28:46] complexity [28:48] and it's a pretty good instruction set [28:49] they did a fine job [28:51] so if i was just going to say i want to [28:53] build a computer really fast today [28:55] and i want it to go fast wrist five is [28:58] the easiest one it's the simplest one [29:00] it's got all the right features it's got [29:01] the right top eight instructions [29:04] you know that you actually need to [29:05] optimize it doesn't have too much junk [29:08] so yeah so modern instruction sets have [29:13] too much bloat [29:14] especially the old ones because they [29:15] have too much legacy baggage [29:16] construction sets that have been [29:18] iterated and added to [29:19] will have too much blood yeah that's [29:22] what always happens [29:23] right so as you keep adding things like [29:26] you know the engineers have the struggle [29:27] right [29:28] you have this really good design there's [29:29] 10 features so you add some features to [29:31] it [29:32] the features all make it better but they [29:33] make it more complicated [29:35] and as you go along every new feature [29:36] you add gets harder to do because [29:38] the interactions with that feature and [29:39] everything else gets [29:41] terrible and and the marketing guys and [29:44] you know the the old customers will say [29:46] don't delete anything [29:48] but meanwhile they're all playing with [29:50] the new fresh thing that's [29:52] you know only does 70 of what the old [29:55] one does [29:56] but it does it way better because it [29:57] doesn't have all these problems [30:00] right so this is you know i've talked [30:01] about diminishing return curves there's [30:03] a bunch of reasons for diminishing [30:04] returns [30:05] but one of them is the complexity of the [30:08] interactions of things slow you down to [30:10] the point where [30:11] something simpler that did last would [30:13] actually be faster [30:16] and that's happened many times it's it's [30:18] some [30:20] result of complexity theory and you know [30:22] human nefariousness i think [30:25] so do you ever see a situation where x86 [30:28] gets [30:28] broken down and something just gets [30:30] reinvented or will it just remain sort [30:32] of legacy and then just new things will [30:34] pop up like risk five two [30:36] well well then with a fairly you know [30:38] clean slate that obviously had to carry [30:40] a long baggage [30:42] for this and that but you know they [30:43] deprecated a lot of like you know the [30:45] old 16-bit modes and bats [30:47] there's a whole bunch of junk that [30:49] disappeared and sometimes if you [30:52] you're careful you can say all right i [30:54] need to support this legacy but it [30:55] doesn't have to be performant and i can [30:57] isolate it [30:58] from the rest of the client emulator and [31:01] stuff [31:02] yeah emulate it or support it and we [31:06] used to build computers such you know [31:07] you had a front end you know fetch [31:09] dispatch [31:10] execute load store l2 cache and if you [31:14] looked at the boundaries between them [31:15] you'd see [31:16] like a hundred wires doing random things [31:18] that [31:19] you know were dependent on exactly what [31:21] cycle of the you know or what phase of [31:23] the clock it was [31:24] now the interfaces tend to look like [31:26] it's like instruction boundaries i send [31:28] an instruction [31:29] from here to there and you know and then [31:31] i have a protocol that says act so [31:34] the computer inside doesn't look like a [31:36] big mess of [31:37] stuff connected together it looks like [31:39] eight computers hooked together that do [31:40] different things there's a [31:42] fetch computer and the dispatch computer [31:44] and the integer execution computer and a [31:46] floating point computer [31:47] and if you do that properly you can [31:49] change the floating point [31:51] without touching anybody else [31:54] and again that's that's less of an [31:55] instructions that thing than [31:57] what was your design principle when you [31:58] build it and then how did you do it and [32:01] were you faithful to that because the [32:03] thing is you get to a problem you say [32:05] boy if i could just add these five wires [32:06] between these two boxes i could get rid [32:08] of this problem [32:10] but every time you do that every time [32:12] you violate the abstraction layer [32:15] you've created a problem for future gym [32:19] future gym like like [32:22] i've done that so many times it's like [32:23] if you'd solved it properly [32:25] it would still be clean but you know [32:28] some point you always have to hack a [32:29] little bit and then that [32:30] over time that kills you it's i've seen [32:34] a number of talks where you [32:35] where you speak about the concept of [32:38] abstraction layers in pretty much [32:40] a lot of aspects of engineering but also [32:42] kind of you know life as well [32:45] so that you can you know independently [32:46] upgrade different layers without [32:48] affecting those above and below and [32:50] providing you know new platforms to [32:52] build upon [32:53] what point in your life did that [32:56] kind of ethos click and what what [32:59] what what what made what happened in [33:01] your life to make that [33:03] you know that be a pervasive element of [33:05] of your personality [33:08] oh pervasive element of my personality [33:10] that's pretty funny i know i repeat it a [33:12] lot maybe i'm trying to convince myself [33:15] um the [33:18] like when we built ev6 so dirk meyer was [33:21] the other architect and then we had a [33:22] couple other strong people [33:26] we divided the design into a few pieces [33:29] we wrote a very simple performance model [33:31] that got it but when we built the thing [33:33] it was a relatively short pipe for an [33:35] out-of-order machine because we're still [33:37] a little weak on predictors [33:39] and there was a lot of interactions [33:40] between things [33:42] and it was a difficult design to build [33:45] and we also built it with [33:48] at the time we you know digital had a [33:49] custom design methodology [33:51] so we had 22 different flip-flops like [33:54] people could roll their own flip-flop [33:56] and we frequently would build large [33:58] structures out of transistors [34:00] and i remember somebody asked me what [34:02] what elements were in our library and i [34:04] said both of them [34:05] end devices and p devices right [34:08] and then i went to amd and k7 was built [34:11] with a cell library [34:13] now the engineers were really good at [34:15] laying down the cell libraries in a way [34:17] they got good performance [34:18] but they only had two flip flops a big [34:20] one and a little one [34:22] and they had a clean cell library so [34:24] they had an abstraction layer between [34:26] the transistors and the designers [34:28] and this was before the age of really [34:30] good place in route tools [34:32] and that was way better and then the [34:35] interface that we built on ev6 which was [34:38] later called the s2k bus because we [34:39] licensed it to amd [34:41] had a lot of complicated transactions to [34:44] do snoops and [34:45] loads and stores and reads and writes [34:47] and all kinds of stuff [34:48] and uh a friend of mine who was a [34:50] digital research lab [34:52] i explained how it worked to him one day [34:55] his name is cruz [34:56] kuroshko he went to google later and [34:58] became [34:59] one of the security gurus like he [35:01] listened to me and he said he just shook [35:03] his head he's like jim [35:04] that's not the way you do this and he [35:07] explained how virtual channels worked [35:09] and how you could have separate abstract [35:13] channels of information right [35:16] and you get that right before you start [35:18] encoding commands and [35:20] saying what a wire does when it wiggled [35:22] so the result of that let's say [35:25] educational seminar slash ass kicking [35:28] was hyper transport [35:30] which had a lot of the protocol the s2k [35:32] bus but it was built in a much more [35:33] abstract way [35:35] so i i would say that was probably [35:38] you know my trans my uh move from [35:41] amd to or digital to amd [35:45] where we had the ideas of how to build [35:46] high performance computing but the [35:48] methodologies were [35:50] like say integrated like transistor up [35:53] to architecture [35:54] was literally could be the same person [35:57] yeah and the fbmd you know [35:58] there was mark you know architects [36:00] microarchitects [36:02] the rtl people write verilog but they [36:04] literally translated it to gates [36:06] the gate library people it was much more [36:08] of a layered approach [36:11] and k7 was quite a fast processor [36:14] and our first swing at k8 we kind of [36:17] went backwards because bruskieski was [36:20] my favorite circuit partner at the time [36:22] he and i could talk about big designs [36:24] but we [36:24] we saw it as transistors but that's a [36:27] complicated way to build [36:29] computers and uh [36:32] and since then i've been more convinced [36:34] like the abstraction layers are right [36:36] you don't overstep human capability [36:39] that's the biggest problem [36:40] right if you want to build something [36:42] bigger and more complicated you better [36:43] solve the abstraction layers because [36:44] people aren't smarter [36:46] and if you put more than 100 people on [36:48] it it'll slow down not speed up [36:51] and so so you have to solve that problem [36:56] if you have more than 100 people you [36:58] need to split into two abstraction [36:59] layers [37:00] yeah yeah exactly and there there's [37:02] reasons for that like human beings are [37:04] really good at [37:05] tracking you know your inner circle of [37:07] friends is like 10 20 people [37:09] it's like a close family right and then [37:11] there's this kind of 50 to 100 depending [37:13] on how it's organized that you can keep [37:15] track of but above that [37:17] you don't you don't you read everybody [37:19] outside your group of 100 people [37:20] send me strangers and so there you have [37:23] to have [37:24] some different contract about how you do [37:26] it like when we build zen we had [37:28] 200 people and half the team did the [37:31] front end and half the team did the back [37:33] end [37:34] and the interface between them was [37:35] defined and they didn't really have to [37:37] talk to each other about the details [37:39] behind the contract [37:41] right and that that was important now [37:43] they get along pretty good and they work [37:44] together but [37:46] they didn't constantly have to go back [37:47] and forth across that boundary speaking [37:50] about abstraction layers um [37:52] you've said on stage in interviews in [37:54] the past that you're not worried about [37:55] moore's law [37:56] you know process node side evolution of [38:00] semiconductors will [38:01] eventually get worked out by someone [38:03] somewhere [38:04] would you say your attitude towards [38:06] moore's law is apathetic [38:08] or do you draw or you know trust [38:10] engineers that will work out [38:12] super proactive yeah subs [38:17] like yeah yeah that's not empathetic at [38:19] all like i know a lot of details about [38:21] it [38:22] well you you get into these kind of [38:24] people conflate a few things like [38:26] intel's [38:26] tendon animator slipped right and people [38:29] said oh this because moore's law is dead [38:30] tsmc roadmap didn't slip at all right [38:33] now some of that was [38:34] alignment right tsmc's roadmap aligned [38:37] to the euv [38:38] machine availability so when they went [38:40] from 16 to 10 to 7 [38:43] they did something you know and tsmc has [38:45] been really good at [38:46] kind of doing these half steps so they [38:48] did seven without euv and then seven [38:50] plus with the uv [38:51] and then five with more and then five [38:53] plus they tweak stuff [38:54] and then they um and the uv machines for [38:58] a while people weren't sure if they were [39:00] going to work [39:01] but now asml's market caps twice intel's [39:04] like so you know and then there's a [39:08] funny thing i realized that the locus [39:10] of innovation like we tend to think of [39:12] tsmc samsung [39:14] intel as the process leaders but a lot [39:17] of the [39:18] leadership is actually in the equipment [39:19] manufacturers applied materials [39:21] sml so who's building the innovative [39:24] stuff [39:26] and euv machines the worldwide sales [39:29] so the number something like tsmc is [39:31] going to bought like 150 [39:34] uh e machines by 2023 or something like [39:37] that like [39:38] the numbers are phenomenal because not [39:40] too many years ago people weren't even [39:41] sure they're going to work [39:43] and now there's x-ray lithography coming [39:45] up [39:46] and again you can you can say well it's [39:49] impossible but [39:50] bloody everything has been impossible um [39:53] and then you know the fine print this is [39:56] a richard feynman [39:57] you know sentence he's kind of smart he [40:00] said there's lots of room at the bottom [40:01] and i personally can count [40:03] and if you look at how many transistors [40:05] how many atoms are across [40:06] transistors there's a lot right [40:10] and how many transistors you actually [40:11] need to make a junction [40:13] without too many quantum effects there's [40:15] only ten [40:17] so so there's there's lots of room there [40:21] it's i recently put out a video about [40:23] ibm's two nanometer announcement and it [40:25] and the title was [40:27] there's a lot more rumors in gordon more [40:30] yeah [40:31] a lot more so you're not empathetic [40:34] either yeah well there's also this funny [40:37] thing there's a belief system when [40:39] everybody believes technology's moving [40:41] at the space and the whole world [40:42] oriented towards it [40:44] because like technology isn't one thing [40:46] you know there's people who figure out [40:47] how to build transistors [40:49] like you know what the process designers [40:51] do it like intel or tsmc or samsung is [40:54] they used equipment which can do [40:56] features but then the features actually [40:58] interact [40:59] and then there's some really interesting [41:01] trade-offs between [41:02] like like should how should this be [41:04] deposited and etched and how tall should [41:06] it be and why [41:07] and what the space so they're the you [41:10] know they're told they're the craftsman [41:11] using the tools [41:13] so the tools have to be super sharp and [41:14] the craftsmen have to be super [41:16] knowledgeable [41:17] right and that's a complicated play and [41:21] and there's lots of interaction and at [41:23] some level you can see [41:26] because the machines themselves are [41:28] complicated you have this little [41:30] complexity [41:30] combination where the machine [41:33] manufacturers are doing different pieces [41:35] they don't always coordinate [41:36] perfectly or they coordinate through the [41:39] you know essentially the [41:40] machine integration guys who designed [41:42] the process [41:43] and that that's complicated and that can [41:45] slow things down but [41:47] it's it's not due to physics [41:49] fundamentals like we're making good [41:51] progress on physics fundamentals [41:54] and uh i i put up your [41:57] i think i mentioned before your scaled [41:58] ml talk where you have [42:00] the one that you have in comic sans [42:02] where you have the printed x [42:04] and you say you know as time goes on the [42:06] way you print the x [42:08] because of the laws of physics and [42:10] there's still several more steps to go [42:11] on euv [42:13] and high n a euv coming in a couple of [42:15] years but you mentioned x-ray [42:17] you mentioned x-rays what's the timeline [42:19] for that it's not even on my radar yet [42:22] i'm forgetting what the the machines [42:25] were available [42:26] for commercial some part of the well [42:28] typically when the [42:29] when a technology that comes along they [42:31] use it for like one thing [42:33] the first time like you know when the [42:35] euv was first using drams it was [42:37] literally for one stop [42:39] or maybe two so um [42:43] i'm trying to remember twenty three [42:45] twenty four it's not that yeah [42:47] that means they're already up and [42:49] running people are playing with it [42:51] yeah and then the wild thing is you know [42:53] the when they went from optical like the [42:56] uv [42:56] was about a 10x reduction in wavelength [42:59] right [42:59] so they'd got these crazy [43:01] multi-patterning you know [43:03] interference kind of stuff that you saw [43:05] those pictures of [43:07] and then ev they could print direct but [43:09] actually they can use the same tricks on [43:11] euv so [43:12] ev is going to multi-patterning i think [43:14] in three nanometer [43:16] and and then there's there's many tricks [43:19] you can do with that [43:21] so yeah the physics is is really [43:24] interesting [43:26] and then you know with along with the [43:27] physics you know of the optics stuff and [43:29] then there's [43:30] you know the purity of the materials [43:32] which is super important and then [43:33] temperature control so things don't go [43:35] around too much [43:37] like everywhere you look there's a you [43:38] know interesting physics problem [43:41] and uh but there's there's lots to do [43:45] and thousands of different innovations [43:47] needed i think i think i think [43:48] yeah there's literally hundreds of [43:50] thousands of people working on it so [43:53] you know every group of 10 people about [43:55] innovation [43:56] there's there's more than enough [43:58] innovation bandwidth [44:01] so uh pivoting pivoting to a popular [44:04] question we had [44:05] it's um so one of the things that [44:09] we've noted you doing as you go from [44:11] company to company is you know [44:13] the topic of building a team um [44:16] you know and as you build more teams [44:19] we've seen certain people [44:21] take engineers from a team they've built [44:23] a previous company to the next company [44:25] you know it's have you got any insights [44:28] into how you build your teams [44:29] and have there been any different [44:31] approaches at the companies that you [44:32] worked for on this [44:36] well the first thing you have to realize [44:37] is are you building a team or finding [44:39] one [44:40] so there's a great museum in venice uh [44:43] the david museum [44:44] and the front of the museum there's [44:46] these huge blocks of marble [44:49] yeah 20 by 20 by 20. how they move them [44:52] i don't know [44:52] and the block of marble is sitting there [44:55] and [44:56] you know michelangelo could see this [44:58] beautiful sculpture in it [45:00] it was already there right yeah the [45:03] problem was [45:04] removing the excess marble so if you go [45:07] in the company that's a thousand [45:08] employees [45:09] i guarantee you there's a good team [45:11] there you don't have to hire anybody [45:14] we didn't hire anybody when i was at amd [45:16] i hardly hired anybody [45:18] you know we moved people around we [45:20] deployed people let's say [45:21] and uh but there was plenty of great [45:24] people there [45:26] when i went to town the team from [45:27] scratch because there was nobody at [45:29] tesla that was building chips [45:31] and you know i hired people that i knew [45:34] but then [45:34] we hired a bunch of people that i didn't [45:36] know at some point and then [45:38] this is one of those interesting things [45:40] if you only hire [45:41] you know i've seen leaders go from one [45:43] company to another and they bring their [45:44] 20 people and then they start trying to [45:46] reproduce what they had before [45:49] and that's that's a bad idea because 20 [45:51] people is enough to reproduce it [45:54] but but it alienates you know what you [45:56] want it when you build a new team [45:58] you ideally you get people you really [46:01] like [46:01] you know either you just met them or you [46:03] work with them but you want some [46:07] differences in approach and thinking [46:09] because everybody gets into a local [46:10] minimum [46:11] so the new team has this opportunity to [46:14] make something new together [46:16] and some of that's because you know if [46:19] you had 10 really great teams all [46:20] working really well [46:21] and then you made a new team with one [46:23] person from each of those teams [46:25] that may well be better because they [46:28] will [46:30] you know re re-select which the best [46:33] ideas were [46:34] because every team has pluses and [46:36] minuses [46:38] and so you have to think about if you're [46:40] building a team or [46:41] finding a team and then what's the [46:44] what's the dynamic you're trying to [46:46] create that gives gives it space for [46:48] people to have new ideas [46:50] or you know some people get stuck on one [46:52] idea and then they work with new people [46:54] and also they're doing this credible [46:55] thing [46:56] you think wow they're great they used to [46:57] be not so great what happened [46:59] well they were carrying some idea around [47:01] that wasn't great [47:03] and then they met somebody who [47:04] challenged them or the environment [47:06] forced them or [47:07] you know whatever you know happened [47:10] and all of a sudden they're doing a [47:11] great job i've seen it happen so many [47:12] times [47:14] i used to ken olsen at digital said [47:16] there's no bad employees there's [47:18] just bad employee job matches when i was [47:20] younger i thought that was stupid [47:23] but i work with more people i've seen it [47:24] happen so many bloody times [47:27] that you know i've even fired people [47:30] who went on to be really successful [47:32] because they weren't doing a good job [47:34] because they were stuck and emotionally [47:36] they were committed to something that [47:37] wasn't working [47:38] and the act of moving to a different [47:40] place freed them up [47:42] you know i don't get thank you i should [47:46] so how much of that also comes down to [47:48] sort of company culture [47:49] i mean when you're looking for the [47:51] person for the right position or whether [47:52] you're hiring in for the new [47:54] new position do you try and get [47:57] something that goes against the company [47:59] grain or goes with the company grain do [48:01] you have any tactics here or is [48:04] it really depends on what you're doing [48:06] if you're trying to do something really [48:08] innovative it's probably mostly against [48:11] if you have a have a project that's [48:12] going really well [48:14] bringing in the instigators is going to [48:16] slow everybody down because you know [48:18] you're already doing well you have to [48:20] read the group and the environment [48:22] and then there are some people who are [48:24] really good they're really flexible they [48:26] go on this project i'm going to fit in [48:28] and just push [48:30] but on the next one i'm going to you [48:31] know you can see them they're building [48:33] their network and team and on the next [48:35] project they're ready to do a pivot [48:37] and everybody's willing to work with [48:39] them it's like trust is a funny thing [48:41] right [48:42] you know if somebody walks up and says [48:44] jump off this bridge you'll be fine [48:46] you're like [48:46] but if you'd already been [48:48] through a whole bunch of stuff with them [48:50] and they said look trust me you jump and [48:52] you're going to be fine it's going to [48:54] suck but it's going to be fine [48:56] you'll do it right and teams that trust [48:58] each other are [48:59] way more effective than ones that have [49:01] to do everything [49:02] with contracts negotiation and politics [49:05] so that's probably one thing if you're [49:08] building a team you know [49:09] building or finding a team when you [49:10] start seeing people [49:12] let's say doing politics which means [49:14] manipulating the environment for their [49:16] own benefit [49:18] um they gotta go unless they're the boss [49:22] and then you know then you have to see [49:25] if they deliver like some people are [49:26] very political but they really [49:28] they think their political strength [49:30] comes from delivering [49:32] yeah but but people randomly an [49:34] organization that are political just [49:35] cause lots of stress [49:37] do you recommend that sort of uh early [49:39] mid-career engineers [49:41] they you know bounce around regularly [49:43] from project project [49:44] just so they don't get stuck in a hole [49:47] so it sounds like that seems to be a [49:49] common thing [49:50] you learn fastest when you're doing [49:52] something new working for somebody that [49:54] knows way more than you [49:56] so yeah you're relatively early in the [49:57] career and you're not learning a lot or [49:59] you know the people that you're working [50:00] for aren't inspiring you [50:03] then yeah you should probably change um [50:06] so there's some careers where i've seen [50:09] people bounce around three times because [50:10] they're getting experience and they end [50:12] up being good at nothing [50:13] and they would have been better staying [50:15] where they were and really getting deep [50:17] at something [50:19] so you know creative tension there's [50:20] great attention between those two ideas [50:22] that kind of leads into into a good [50:24] question actually because i wanted to [50:25] ask [50:26] about you and you know your mentors you [50:29] know [50:29] going through your early career who did [50:31] you look up you know [50:32] to for leadership knowledge skills is [50:35] there anyone you idolize [50:38] oh yeah lots of people yeah i [50:41] well it started out with my parents like [50:43] i was really lucky my father was an [50:45] engineer and my mom was [50:47] super smart you know kind of more [50:49] verbally and linguistically [50:51] and the weird thing was when i grew up [50:53] is i was sort of more like her [50:56] you know thinking wise but i was [50:58] dyslexic and i couldn't read [51:00] and my father was an engineer and so i [51:03] grew up thinking i was like him but i [51:05] was actually [51:05] you know intellectually more like my [51:07] mother and they were both [51:08] you know smart people now they came out [51:10] of the 50s and my mom raised you know [51:13] family and she didn't start her career [51:15] as a therapist [51:16] until later in life but they were you [51:19] know [51:19] they were pretty interesting people and [51:22] i got that [51:22] and then when i first started at digital [51:25] i worked for a guy named bob stewart who [51:26] was a great computer architect [51:29] he did the pdp 1144 1170 back 780 vex [51:35] and the ci interconnect and somebody [51:38] said every project he ever worked on [51:40] earned a billion dollars back when that [51:41] was a huge number [51:43] so i worked for him and he was great but [51:45] there was a half a dozen other really [51:47] great computer architects there and [51:49] while i was at dec had deck research [51:50] labs and i got to meet guys like butler [51:53] lamson and chuck thacker and new oldham [51:55] and [51:56] you know i worked nancy kronenberg was [52:00] like one of my mentors when i was a [52:01] little kid practically who's [52:03] one of the chief people in the vms [52:05] operating system and [52:07] so you know that was kind of lucky [52:10] um so yeah did i idolize them well they [52:13] were [52:14] they were both daunting and not because [52:15] i was a little bit of a [52:18] you know i don't know i didn't quite [52:20] shut up who they were at the time [52:23] now i was more a little oblivious to [52:26] what was going on [52:28] you know like my first week in [52:31] digital well we got trained on this [52:33] drawing system called [52:35] valid which is kind of before the metro [52:37] graphics era [52:39] and uh this guy walked in and he was [52:41] asking us questions [52:42] and telling us about hierarchical design [52:45] and i explained to him why that was [52:46] partly a good idea and probably stupid [52:48] and so he had like an hour debate about [52:50] it and then he walked off and somebody [52:51] said that's gordon bell [52:53] i said who's that you go he's just [52:56] digital yeah really well he's wrong [52:59] about half the stuff you just said [53:01] i hope i straightened it out but you [53:02] know [53:04] i think that's just i'm low in you know [53:06] serotonin activation or something so [53:09] you know that's that's more of a mental [53:11] problem with me than [53:13] the future i think so so would you say [53:16] you've matured [53:18] not a bit is that where the fun is [53:22] no no i mean there's a whole bunch of [53:24] stuff when i was young it was like i get [53:26] nervous when i gave a talk or [53:29] like believing you know it used to be [53:33] like i realized i had to understand the [53:35] people around me better [53:37] but you know i wasn't quite convinced um [53:40] it was like just rather they you know [53:43] just do the right thing or something [53:45] so there's a bunch of stuff that changed [53:47] like i'm now i'm really interested in [53:48] what people think and why they think it [53:50] and [53:51] you know i have a lot of experience with [53:52] that and every once in a while you can [53:54] really help debug somebody or [53:56] you know get the group to work better [53:58] you know i don't mind giving public [54:00] talks at all [54:01] you know i just decided that the energy [54:03] i got from being nervous was fun [54:06] so you know i still remember like [54:08] walking out on stage at intel at some [54:10] conversations like 2 000 people [54:12] and i was like i should have been really [54:13] nervous but instead i was just really [54:15] excited about it [54:16] so some of that kind of stuff changed [54:18] but that's partly conscious and partly [54:20] just practice [54:22] um i'm still really excited about like [54:24] computer design and stuff [54:26] i had a friend of mine's wife said what [54:28] do they put in the water [54:30] like all you guys ever do is talk about [54:31] computers [54:33] it's really fun you know changing the [54:36] world you know it's great [54:38] it also sounds like um you spend a lot [54:41] more time sort of studying [54:43] the human experience if you're [54:45] understanding how people [54:47] how people think how people operate [54:49] compared to being [54:51] you know mouthing at golden bell for now [54:53] it's funny people [54:55] occasionally ask me like like like i [54:57] tell people i read books and you learn a [54:58] lot from books books are fun by the way [55:00] if you know how a book works [55:01] somebody lives 20 years and then [55:04] passionately writes their best ideas and [55:06] there's lots of those books and then you [55:08] go on amazon and find the best ones [55:10] like it's hilarious right like really [55:13] condensed experience in a book written [55:16] and you can even select for better books [55:18] like who knew right um [55:21] but i've been reading a lot of books for [55:22] a long time like it's it's hard to say [55:24] well read these four books and it'll [55:25] change your life because sometimes a [55:26] book will change your life [55:28] but reading the thousand books will [55:29] change your life that's for damn sure [55:31] and you know there's so much human [55:33] experience that's useful [55:35] it's like who knew shakespeare would be [55:37] really useful for engineering management [55:40] right but like what are all those [55:42] stories you know power politics and [55:44] devious [55:45] guys and the minions doing all the work [55:48] and [55:48] the occasional hero who's saving the day [55:52] and you know it's like how does that all [55:53] play out like [55:55] you're always played 500 years ago and [55:58] it applies to corporate america every [55:59] single day of the week so if you don't [56:02] know textbook or machiavelli you don't [56:04] know nothing [56:05] i think i remember you saying that [56:08] before you went into your big first [56:09] management role [56:10] you read 20 books about management [56:13] techniques and you ended up [56:15] uh realizing that you'd read 19 more [56:17] than anybody else [56:18] yeah pretty much yeah i i actually [56:21] contracted with venkat rao [56:23] who's famous for the ribbon farm blog [56:25] and a few other things [56:26] to you know figure out so i really liked [56:29] his thinking about organization [56:32] from his blog and he had a little thing [56:33] at the bottom that says click here to [56:35] buy me a cup of coffee or get a [56:36] consulting [56:38] you know or consult with me so i sent [56:40] him an email [56:41] so we started yakking and we spent a lot [56:44] of time talking before i joined amd and [56:46] he said you should read these books and [56:47] i did [56:48] i thought well i thought everybody who's [56:50] a big management job did that [56:52] nobody does yeah you know it was [56:54] hilarious like [56:55] 19 is generous i read 20 more management [56:58] books than most people [56:59] most managers i've ever read where they [57:01] read some superficial thing like good [57:03] the great [57:04] you know which which has some nice [57:06] stories in it but it's not that deep a [57:07] book management wise [57:09] you know you'd be better off reading [57:10] carl young than good the great if you [57:12] want to [57:12] understand management [57:16] do you find yourself reading more [57:17] fiction or non-fiction [57:20] as a kid you know i read all the [57:22] non-fiction books and then my [57:23] my parents had a book club so when i [57:26] i didn't really learn to read until i [57:28] was in fourth grade but somewhere around [57:29] seventh or eighth grade [57:31] i read all the books in the house so you [57:33] know they had [57:34] john updike and john barth was one of my [57:38] favorite authors when i was a kid [57:41] so there was a whole bunch of stories [57:43] and yeah there's weird ones like [57:46] um i'm i'm drawing a blank on the name [57:50] uh i'll think of it a second doris [57:52] lessing dork blessing wrote a series of [57:54] science fiction books [57:56] that were also psychological [57:59] you know in inquiries and i read that [58:02] and just [58:04] i couldn't believe it like [58:07] you just you know everyone saw stuff [58:08] like that kind of blows your mind [58:10] you know and it happened obviously at [58:12] the right time [58:14] but then now i read all kinds of stuff i [58:16] like [58:17] you know history and anthropology and [58:19] psychology and [58:21] you know mysticism and there's there's [58:23] so many different things [58:25] i've probably read less fiction books in [58:27] the last 10 years but you know my [58:30] when i was younger you know i read [58:32] probably mostly fiction [58:34] i mean it's i i did get a few comments [58:36] um from the audience because [58:38] when you are um being interviewed by lex [58:40] you know you said that you read two [58:42] books a week [58:43] you know and you're very adept at [58:44] quoting from key engineers and futurists [58:47] and stuff [58:48] i'm sure if you started tweeting what [58:49] books you're reading you'll get a very [58:51] large following [58:52] yeah a sort of passive jim keller book [58:54] club [58:56] yeah that'd be fun i would say i used to [58:59] read [59:00] two books a week now i i read a lot but [59:03] you know it tends to be blogs and all [59:05] kinds of crazy stuff [59:06] um but i've never i don't know [59:10] like doing lex is super fun i don't know [59:12] that i have the attention span for [59:14] social media to do anything like that [59:17] i'd forget about [59:18] it for weeks at a time so i'd be sort of [59:21] your clothes [59:22] i'm sure people just want lists i think [59:24] but how do you make sure that you're [59:26] absorbing what you're reading [59:27] rather than having your brain diverting [59:28] about some other problem that you might [59:30] be worrying about [59:31] i mean well first of all i don't care at [59:34] all [59:34] [Laughter] [59:36] i don't really care about that i know [59:38] people that read books that are really [59:39] worried if they're going to remember [59:41] them and they spend all this time [59:42] you know highlighting and analyzing it [59:45] you know i read for [59:46] interest right so what i really remember [59:48] is like [59:49] like you know like people have to write [59:50] to write 250 page books because that's [59:52] like a publisher role [59:54] like and it doesn't matter if you have [59:55] 50 pages of ideas or 500 [59:58] so you can tell pretty fast i've read [59:59] some really good books [60:01] only 50 pages because that's all they [60:03] had you know you read 50 pages [60:05] you think wow it's really great and the [60:07] next 50 pages is huh [60:08] it's the same you know and they [60:10] realize well he just fleshed it out [60:13] no you know i wish you just published a [60:15] shorter book [60:17] but uh you know that is what it is but [60:20] if the ideas are interesting [60:22] that's good i i meditate regularly and [60:24] then i think about [60:27] you know what i'm thinking about which [60:29] is sometimes related to what i'm reading [60:32] and then if it's interesting it gets [60:33] incorporated but [60:35] you know your brain is this kind of [60:36] weird thing you don't actually have [60:37] access to all the ideas and thoughts and [60:40] things you've read but your personality [60:43] seems to be well informed by it [60:45] and i trust that process so i don't [60:47] worry that i can't remember somebody's [60:49] name because [60:50] their idea may have changed who i was [60:52] and i don't you know [60:53] remember which book it came from sorry [60:56] as long as you passively absorb it at [60:57] some level [60:58] yeah well you know [61:01] there's there's a combination of passive [61:04] and active and [61:06] you know i told lex like a lot of times [61:07] i'm working on problems i i i prep [61:10] my uh dreams for it and [61:13] you know it's it's really useful um [61:18] and that that's a fairly straightforward [61:20] thing to do it's you know you before you [61:22] fall asleep you call up your [61:24] your mind what you're really working on [61:26] and thinking about and then [61:28] my personal experiences sometimes [61:31] i really do work on that and sometimes [61:34] that's just a problem in the way of what [61:36] i actually need to think about and you [61:37] know [61:38] i'll dream about something else and i'll [61:39] wake up going well [61:41] one way or the other it was really [61:42] interesting [61:44] so i mean on on on the topic of time i [61:47] mean [61:49] here we are discussing and you've [61:50] discussed with like you know personal [61:51] health [61:52] study meditation family but also how you [61:55] execute professionally [61:56] right are you one of these people who [61:58] only needs four hours sleep at night [62:01] i like seven well i don't i i [62:04] you know everybody i added it up one day [62:06] that you know my ideal day would have [62:08] like 34 hours in it [62:10] you know because i like to work out i [62:12] like to mess around with my kids i like [62:14] to [62:14] sleep and eat and you know i like to [62:17] work i like to read [62:19] so i don't know it just work works the [62:22] weird one because that that can fill in [62:24] lots of more time than you want to spend [62:26] on it but [62:27] but i also really like working so it's [62:29] you know it's it's a challenge to kind [62:30] of [62:31] tamp it down well i mean when when [62:34] there's a deadline what what kind of [62:36] gets pushed out of the way first because [62:38] i mean you've worked at companies where [62:39] getting the product out time to market [62:41] has been a key element of what you're [62:43] doing [62:45] is exercise now for about the last six [62:48] years [62:48] the key thing for me is once i have too [62:50] much to do in some place i find somebody [62:52] who wants to do it more than me [62:55] like i mostly work on unsolved problems [62:58] [Music] [62:59] you know i was the laziest person at [63:01] tesla [63:03] as best i could tell well tesla had a [63:05] culture of like [63:06] work 12 hours a day to make it look like [63:08] you're working and yeah [63:10] oh i worked you know nine till seven [63:12] like i wasn't uh [63:13] it was a lot of hours but i also you [63:16] know i go running at lunch and work out [63:18] you know i had a weightlifting room [63:20] in deer creek on the right next to the [63:22] the big machine shop so i go down there [63:24] for an hour and [63:25] work out and eat so [63:29] and you know amd and intel they're big [63:31] big organizations i had a really good [63:33] staff [63:34] so i'd find myself spending way too much [63:35] time on presentations or working on some [63:38] particular thing and then [63:39] i'd find some people who wanted to work [63:40] on it and i'd give it to them and [63:43] you know go on vacation god speaking to [63:46] press people like me and filling up your [63:49] time [63:50] what's what's your feeling about doing [63:53] these sorts of press interviews and you [63:56] know more sort of [63:57] marketing and corporate and discussion [63:58] which aren't really necessarily related [64:00] to [64:01] actually pushing the envelope it's just [64:03] talk [64:06] it's not just talk you know i you know i [64:09] worked on some really interesting stuff [64:11] so i like to talk [64:12] about it like when i was in intel i [64:14] realized one of the ways to influence [64:16] the intel engineers [64:17] like everybody thought moore's law was [64:19] dead and i thought holy crap [64:20] intel's the moore's law company like it [64:22] would be early at drag [64:24] you know if your main thing was dead and [64:26] i thought it wasn't [64:27] so you know i talked to various people [64:31] because then they [64:31] amplified it and debated and it went [64:33] back inside and [64:35] you know i reached more people inside [64:37] intel by doing external talks [64:39] so that was that was useful to me [64:42] because you know i had a mission to [64:44] you know build faster computers that's [64:46] what i like to do [64:47] so and then when like i talk to people [64:50] they always bring all kinds of stuff up [64:52] and [64:53] you know like the work we do impacts [64:55] people guys like you think really hard [64:57] about it you talk to each other and then [64:58] they talk to you and you ask all these [65:00] questions and it's [65:01] it's kind of stimulated it's fun it [65:03] makes me [65:04] orient like if you can explain something [65:08] really clearly you probably know it like [65:10] there's a lot of times you think you [65:11] know it [65:12] then you go to explain it and you're [65:13] stumbling all around [65:15] like i did some public talks where they [65:16] were hard to do [65:18] like the talk actually seemed simple but [65:20] getting to the simple part [65:22] you have to get your ideas out and [65:23] reorganize them and then throw out the [65:25] bs [65:25] and you know it's a useful thing [65:29] is that is that feynman or sagan said [65:32] that if you can't [65:33] explain a concept to a college [65:36] at a college level first year college [65:38] level then you don't really understand [65:39] it [65:40] yeah that sounds poorly like feynman he [65:42] did that really well lectures here in [65:44] fun physics [65:44] yeah it was quite interesting fireman's [65:47] problem is he had such a [65:48] brilliant intuition for the math that [65:51] his idea of simple was often not that [65:53] simple [65:54] like he'd just see it you could tell so [65:56] he was like [65:57] well i got from here to here by these [65:59] three leaves like he calculated some [66:02] orbital geometry in like five steps and [66:04] he was like so excited about how simple [66:06] it was but [66:07] i think he was the only person in the [66:08] room that thought it was simple [66:10] and uh yeah he was i presume he had you [66:13] know he had the ability to visualize [66:15] things in his head and manipulate them [66:17] so i remember you you're you're saying [66:18] at one point that [66:19] when it comes down to you know circuit [66:21] level design [66:22] that's the sort of thing you can do yeah [66:26] yeah i'm much more of a visual thinker [66:29] yeah if i had one super power it's like [66:31] i feel like i can visualize how computer [66:33] actually runs [66:34] so when i do performance modeling and [66:36] stuff like that i can see the whole [66:38] thing in my head and i'm just writing [66:39] the code down [66:40] so i don't um which is really useful [66:43] skill [66:45] but you know i probably partly was born [66:47] with it partly developed and partly [66:49] it's a it's something that came out of [66:52] you know what [66:53] you know my late adult diagnosis of [66:56] dyslexia [66:59] yeah that's i was going to ask how much [67:00] of that is nature versus nurture [67:02] yeah it's it's hard you know there's [67:04] there's this funny thing with super [67:06] smart people [67:07] often things are so easy for them that [67:10] they can go a really long way without [67:12] having to work hard [67:14] so i'm not that smart definitely so [67:17] you know persistence and you know what [67:19] they call grit is super useful [67:21] especially in computer design when you [67:24] know lots of stuff takes a lot of [67:25] tweaking you have to believe [67:28] you know like you can get there but a [67:30] lot of times there's a whole bunch of [67:31] subtle [67:32] iterations to do and practice with that [67:35] actually really works [67:38] so yeah everybody's a combination you [67:42] know [67:43] if you don't have any talent it's pretty [67:45] hard to get anywhere but sometimes [67:46] really talented people don't [67:47] learn how to work so they they get stuck [67:50] with [67:51] just doing the things that are obvious [67:52] not the things that take [67:54] you know that persistence through the [67:56] mess [67:57] you know to the other side also i guess [68:01] identifying that talent is [68:02] is critical as well if you don't know [68:05] you [68:06] have it yeah but on [68:09] the flip side you may have enough talent [68:12] but you just haven't worked hard so [68:13] people give up [68:14] too soon sometimes so but you got to do [68:17] something [68:17] something you're really interested in [68:19] like you know [68:21] when people are like struggling like i [68:22] don't know if i want to be an engineer [68:23] in marketing or this or that it's like [68:25] man [68:26] what do you like like or especially [68:29] people [68:29] that think well i want to be an engineer [68:31] but my parents [68:32] or somebody wants me to be a manager [68:34] like [68:35] oh my god you know you're gonna have a [68:37] tough life [68:39] because you're not chasing your dream [68:40] you're chasing somebody else's and the [68:42] odds of you being excited about somebody [68:43] else's is low and if you're not excited [68:45] you're not gonna [68:46] you're not gonna put the energy or learn [68:49] so [68:49] you know that's that's a tough tough [68:51] loop to begin [68:53] so i mean to to what extent do you spend [68:55] your time mentoring others [68:57] either inside organizations or [68:59] externally with [69:00] co-work previous co-workers or students [69:02] do you ever [69:03] envision yourself doing something on a [69:05] more serious basis like the jim keller [69:07] school of semiconductor design [69:10] yeah so no it's funny because uh i'm [69:13] mostly mission driven [69:14] like we're gonna build zen we're gonna [69:17] build autopilot [69:18] you know and then there's people that [69:20] work for me and then as soon as they [69:21] start working for me [69:23] i start figuring out who they are and [69:25] then some of them are you know are fine [69:27] some of them have big problems that need [69:28] to be let's say [69:30] you know dealt with one way or the other [69:34] so then you know i'll i'll tell them [69:35] what i want sometimes i'll [69:37] give them some pointed advice sometimes [69:40] i'll [69:41] i'll do stuff and you can tell some [69:43] people are really good at you know [69:44] learning by you know following and then [69:47] people later on told me that i was [69:49] mentoring them and i'm thinking [69:50] i thought i was kicking your ass you [69:52] know it's a it's a funny experience [69:56] i have you know there's quite a few [69:58] people that said i impacted your life in [69:59] something [70:01] and but some of it was like you know you [70:04] know i went after them about their [70:05] health or diet because i thought they [70:07] thought they looked [70:08] you know not energized by life [70:12] you know you can really make really big [70:13] improvements there and it's worth doing [70:15] by the way [70:17] or they're doing the wrong thing and [70:18] they're just not excited about you can [70:20] tell they should be doing something else [70:22] so they either got to figure out why [70:23] they're not excited or get excited [70:26] and then a lot of people start you know [70:29] fussing with themselves or with other [70:31] people [70:31] about their status or something and the [70:34] best way to have status is to do [70:35] something great and everybody thinks [70:37] you're great [70:38] having status by trying to claw your way [70:40] up is terrible because everybody thinks [70:42] you're a climber and [70:44] you know and sometimes it is don't have [70:47] the confidence or skill to you know make [70:48] the right choice there [70:51] so but but it mostly comes out of [70:54] you know being mission driven like like [70:56] i do care about people [70:58] at least i try to um [71:02] and and then i see the results i mean [71:03] it's really gratifying to get a big [71:05] complicated project [71:06] done and you know where it was when you [71:08] started and then you know where it was [71:10] when it was done [71:10] and then people people when they work on [71:14] successful things [71:15] associate the leadership and the team [71:17] they're working with which [71:19] was being part of that so that's that's [71:21] really great [71:22] um doesn't always happen but it's i [71:26] have a hard time doing that just quote [71:28] mentoring people because what's the [71:29] mission [71:30] like somebody comes to you and says i [71:32] want to get better well better at what [71:34] well then that's you know like well i [71:36] want to be better at you know playing [71:37] violin it was like i'm not good at that [71:40] or you know whereas i say hey we're [71:42] going to build the world's fastest you [71:43] know autopilot chip [71:45] and then everybody working on it needs [71:47] to get better at doing that [71:49] and it turns out three quarters of their [71:51] problems are actually personal [71:52] not technical right yeah so [71:56] to get the autopilot check you have to [71:58] go go debug all that stuff [72:01] you know and you know there's all kinds [72:03] of problems you know like [72:04] health problems and parental childhood [72:07] problems and [72:08] you know partner problems and workplace [72:10] problems [72:11] and you know career stall problems and [72:15] jesus the list is so bloody long we have [72:18] to take them all seriously like [72:19] you know it turns out everybody thinks [72:21] their own problems are really important [72:23] right like you may not think their [72:25] problems are important but i tell you [72:26] they do [72:27] they have a list you ask anybody what's [72:29] your top five problems [72:31] right they can probably tell you or even [72:33] weirder [72:34] they give you the wrong five because you [72:36] can see the idea right that happens too [72:39] but they don't give you the five they [72:40] think you want they give you the five [72:42] that they think you want to hear rather [72:43] than the actual [72:44] yeah or the you know people have no fly [72:47] zone so their biggest problem may be [72:49] something they don't want to talk about [72:51] so you know but if you if you saw if you [72:53] help them solve that then the project [72:55] will go better [72:56] and then at some point they'll [72:57] appreciate you and then they'll say [72:59] you're a mentor and you're thinking [73:01] yeah kinda i don't know you mentioned [73:04] about [73:05] you know projects succeeding and you [73:07] know people [73:09] being proud of their products do you [73:10] have a proudest moment of your career [73:12] project accolade specific moments in [73:15] time [73:16] oh i have there's there's there's a [73:18] whole bunch of them [73:20] i worked with this woman a little bit [73:22] becky loop and intel and we were [73:24] debugging some quality things and [73:26] it turns out there was a whole bunch of [73:28] layers of stuff [73:29] and then you know we were going back and [73:31] forth on how to analyze it how to [73:33] present it [73:34] and you know and i was frustrated with [73:36] the data and what was going on and one [73:38] day she came in with this picture [73:40] it was just perfect and it was like [73:43] like i was you know i was really excited [73:45] for her because she'd [73:46] you know got to the bottom of it we [73:48] actually saw a line of sight to fix and [73:50] stuff but that kind of stuff happens a [73:51] lot like [73:53] like probably the epiphany yeah well [73:56] working with somebody working with a [73:58] group of people going in there like it [74:00] was a mess [74:01] and then it got better you know like you [74:04] know the tesla autopilot thing was wild [74:06] and zen's success has been fantastic [74:09] like [74:09] you know everybody thought the amd team [74:11] couldn't shoot straight and [74:12] now i was very intrigued with the [74:16] possibility of building a really great [74:18] computer with the team everybody thought [74:19] was [74:20] you know out of it like nobody thought [74:22] amd had a great cpu design team [74:25] but you know the people who built zen [74:28] they had [74:28] 25 30 30 years of you know works you [74:31] know history at amd [74:33] like that was [74:36] mike and leslie they've been there for [74:38] 25 30 years [74:40] suzanne plummer yeah you know [74:44] the life is yeah you know they're kind [74:46] of lifers but [74:48] but you know they had done many great [74:51] projects there you know they both had [74:52] good track they all had good track [74:54] records [74:54] um but you know what what did we do [74:57] different well we set some really clear [74:59] goals and then we reorganized hit the [75:01] goals [75:02] and we did some really thorough talent [75:05] you know analysis of where we were there [75:07] was a couple people had really checked [75:09] out because they were frustrated they [75:10] could never [75:11] do the right thing and you know i [75:13] listened to them [75:14] oh jesus i'll have to listen to people [75:17] we had this really fun meeting [75:19] it was like one of the best experiences [75:20] of my life suzanne called me up and said [75:22] people on the zen team don't believe [75:24] they can do it and i said great [75:25] i'll drive to the airport i was in [75:27] california i'll see you there tomorrow [75:29] morning eight o'clock make sure you have [75:30] a big room with lots of whiteboards [75:32] there's like 30 angry people ready to [75:34] tell me all the reasons why it wouldn't [75:36] work [75:37] so i just wrote them all down on a [75:38] whiteboard and we spent two days solving [75:40] them [75:41] and it was wild because it started it [75:43] was like me defending against you know [75:45] the gang [75:46] but people started to jump in and you [75:48] know i was like whenever possible [75:50] somebody would say i don't know how [75:51] i know how we fix that you know now give [75:54] him the pen and then get up on the board [75:55] explain it and [75:58] it worked out really good but we you [76:02] know [76:02] the thing was the honesty of what they [76:04] did was great [76:05] here are all the problems that we don't [76:07] know how to solve and we're putting them [76:08] all on the table [76:09] they didn't like give you two and hold [76:11] back 10 and say well you solved those [76:12] two [76:13] against you know there was none of that [76:14] kind of kind of stuff [76:16] they were serious people that had real [76:18] problems and they'd been through [76:20] projects where people said they could [76:22] solve these problems and couldn't so [76:23] they were probably calling me out it was [76:25] like i just another bullshitter [76:27] and uh and i'm not a bullshitter but i [76:30] told them you know something we can do [76:31] some [76:31] some i don't know but i remember like [76:34] mike clark was there he was like we [76:35] could solve all these problems [76:37] like and then you know i walked out our [76:39] thing was pretty good but then you know [76:41] people [76:41] walked out of the room feeling okay but [76:43] two days later the problems all pop back [76:45] up and [76:46] so you have to just you know like how [76:47] often do you have to go convince [76:49] somebody [76:50] as many times as necessary and the [76:52] leadership team [76:54] on zen did it right that's why they they [76:57] got through it [76:58] it wasn't just you know me hectoring [77:00] them from the sidelines there was [77:02] lots of people and lots of parts of the [77:04] team that really said [77:05] yeah i'm willing to really put some [77:07] energy into this which is great yes [77:10] at some point i'd like i'd love to [77:11] interview some of them but um amd keeps [77:14] them under lock and key from the likes [77:15] of us [77:17] that's probably smart who knows [77:21] is is there somebody in your career that [77:23] you consider sort of like a silent hero [77:26] that has hasn't got enough credit for [77:28] the work that they've done [77:31] or a person yeah most engineers [77:35] most engineers oh it's there's so many [77:37] of them it's unbelievable you know how [77:39] many people [77:40] you know like engineers you know they [77:43] don't really get [77:44] it you know compared to lawyers are [77:45] making like 800 bucks an hour in silicon [77:47] valley you know [77:48] they you know engineers so often they [77:50] just want to be left alone and do their [77:52] work and you know [77:53] crank out stuff and there's so many [77:56] people there just bloody great [77:58] you know i've talked to people it's like [78:00] this is my eighth generation memory [78:01] controller and they're [78:03] just proud as hell because it works and [78:05] there's no bugs in it and the rtl is [78:06] clean and the comments are perfect [78:09] you know they're all over the place like [78:12] like i really like that [78:13] i think but they don't self-promote or [78:16] the company doesn't come yeah [78:19] you know like engineers are more [78:21] introverted and [78:23] you know you know conscientious and [78:26] introverted [78:26] tend not to be you know the people who [78:28] self-promote [78:30] aren't you a little like me you've [78:31] you've learned how to be more [78:32] extroverted as you've [78:34] grown well i decided i wanted to [78:39] build bigger projects and to do that you [78:42] have to [78:42] pretend to be an extrovert and you have [78:44] to promote yourself [78:46] because there's a whole bunch of people [78:47] who are decision makers who [78:49] who don't go i'm going to do the work to [78:51] find out who the best architect is [78:53] they're going to say who is the person [78:56] that everybody says is the best [78:57] architect or the loudest or the [79:00] you know capable so to some level if you [79:03] want to succeed above you know [79:06] you know you know principal engineer you [79:09] have to understand how to work in the [79:11] environment of people who [79:13] play there and and some people are super [79:16] good at that naturally so they get [79:17] pretty high in organizations without [79:19] much talent [79:20] sometimes without much hard work and you [79:23] know so you're [79:24] you know the group of people you know [79:26] director and above that you have to deal [79:28] with [79:28] has way different skill set than most of [79:30] the engineers [79:32] and so if you want to be part of that [79:36] gang even if you're an engineer you have [79:38] to you have to learn how that rolls and [79:40] it's not that complicated read [79:41] shakespeare young [79:43] couple books machiavelli you know [79:46] you know you can learn a lot from that [79:49] so [79:50] as i i know we're coming to time very [79:52] shortly here but uh i i want to [79:54] address a few questions that i think the [79:56] audience are interested in getting your [79:58] thoughts on [79:59] such as uh do you do you care much about [80:01] intel versus amd or intel versus apple [80:04] from your perspective now uh [80:09] you know i worked at all those places i [80:11] really like working there [80:13] um i think [80:16] you know there's always new waves of [80:17] stuff i'm really intrigued by the [80:19] you know the wave of ai startups and the [80:21] next revolution of [80:22] computing so you know [80:26] at the high level you know the extent of [80:28] the corporate companies with stock [80:30] prices [80:31] and boards and you know products you [80:34] know they're going to go fight it out [80:36] they do it i care about the engineers [80:38] and all the companies you know i work [80:40] with lots of people there i really like [80:41] them [80:44] but now i don't think that much about [80:46] them right now in terms of [80:48] you know like what are they going to do [80:49] next well we'll see [80:52] you know apple's always been so insular [80:55] about how they do stuff [80:56] like their product touch point is you [80:58] know aluminum box or a glass box [81:01] yeah well they've always been kind of a [81:03] secret society [81:04] the engineers are great but you know [81:06] they i think they miss out on [81:08] participation in the wider technical [81:09] world [81:11] you know intel and amd sell components [81:13] that go into many people's products so [81:15] their [81:16] interface to the public is more you know [81:19] tangible in terms of the what the [81:22] engineers do [81:23] right because yeah they're chips you [81:25] measure their performance and you care [81:27] about how many pc express lanes they [81:28] have and [81:29] and whether the chip has bugs so this it [81:32] impacts people more [81:35] so i'm interested in what they do but [81:37] they're big corporations with a life of [81:39] their own so in terms of [81:42] uh process design i mean currently you [81:46] know the [81:46] the the eda tools you know there's some [81:49] amount of [81:50] automation in there and advances in ai [81:53] and machine learning are being expanded [81:55] into [81:55] processor design do you ever envision in [81:58] visit [81:59] do you ever envision a time where an ai [82:01] model can design a purposeful [82:03] multi-million device chip that will be [82:05] unfathomable [82:07] to human engineers yeah well [82:10] so already the complexity of like you [82:13] know high-end you know amd until [82:15] apple chip is almost unfathomable to any [82:18] one person [82:19] right but but if you actually go down [82:22] into details today you can mostly read [82:24] the rtl or look at the cell libraries [82:26] and say i know what they do [82:28] right but if you go look inside a neural [82:30] network [82:32] you know that's been trained and say why [82:34] is this weight [82:36] five eight .001584 three [82:41] no business is is is isn't that more [82:44] data than design though [82:47] well here's somebody told me this so [82:51] so scientists traditionally they do a [82:53] bunch of observations and they go [82:55] hey when i drop a rock it accelerates [82:57] like this and they [82:58] calculate how fast accelerate and then [82:59] they curve fit and they realize holy [83:01] crap [83:02] there's this equation right yeah so we [83:05] you know so physicists for years came up [83:07] with all these equations and then [83:08] when they got to you know relativity [83:10] they had the bend space and quantum [83:12] mechanics they had to introduce [83:14] probability [83:15] but still there's mostly understandable [83:17] equations [83:19] there's phenomena now where there's a [83:21] phenomena that a machine learning thing [83:23] can learn [83:25] like predict you know physics is you [83:27] know some equation put inputs equation [83:29] outputs right [83:31] you know function output right but if [83:33] there's a black box there [83:35] where the you know the ai network says [83:37] inputs black box of ai [83:38] outputs and if you look in the box you [83:40] can't tell what it means [83:42] like there's no equation [83:45] right so now you could say well that's [83:48] the design of the neurons is obvious [83:51] you know the little processors little [83:52] four teraflop computers [83:55] you know but the design of the weights [83:57] is not obvious [83:59] right and that's where the thing is now [84:01] now let's go use an ai computer [84:03] to go build an ai calculator what if you [84:07] go look inside the a calculator and you [84:09] can't tell why it's getting [84:11] so now i know don't you understand the [84:13] weights you don't understand [84:14] the math or the circuits underneath them [84:19] that's possible yeah so now you have two [84:22] levels of things you don't understand [84:23] but what do you design [84:24] you might still be designing the human [84:26] experience right [84:28] like yeah commuter designers used to [84:30] design things with transistors and how [84:32] we design things with [84:33] high-level languages so so [84:37] those ai things will be building blocks [84:40] but [84:40] but it is pretty rare that there's going [84:42] to be parts of science [84:46] where the function is not intelligible [84:49] like stephen wolfram said was something [84:51] really interesting like he said physics [84:53] physics there was physics by explanation [84:55] that was aristotle [84:56] you know 1500 years right he was wrong [85:00] about a whole bunch of stuff [85:01] and then there was physics by equation [85:04] like newton [85:05] copernicus you know people like that [85:08] and he says you know stephen wolfram [85:11] said now there's going to be physics by [85:13] by program right there's very few [85:15] programs that are [85:17] you can write in one equation programs [85:20] are complicated [85:21] and he says why isn't physics like that [85:23] well pro [85:24] you know in computing world now we have [85:27] program by ai which has no intelligible [85:31] equations in it [85:32] or statements so why isn't physics going [85:35] to do the same thing [85:37] so it's it's going to be those [85:39] abstraction layers down to the [85:41] transistor [85:42] eventually each of them will be replaced [85:43] by ai [85:45] some internal intelligible black boxes [85:47] that resembles the transistors makes [85:49] things that we don't even understand as [85:51] devices [85:52] yeah like people have been staring at [85:55] the brain for how many [85:56] they they still can't tell you exactly [85:58] why you know the brain does anything [86:01] twenty-one fat and salt and they see [86:04] chemicals go back and forth and [86:06] electrical signals move around and [86:08] you know they're they're finding more [86:09] stuff but [86:11] you know it's fairly sophisticated [86:14] one one of the future aspects of [86:16] computing is security [86:18] and you know we've had a wake of side [86:19] channel attacks potential can of worms [86:23] to do with the tricks that we use to [86:25] make fast computers [86:27] to what extent do you approach those [86:29] security aspects when you're designing [86:32] silicon these days are you proactive do [86:35] you find yourself you [86:36] do you find yourself specifically [86:37] proactive or reactive [86:40] no so the the market is sort of [86:42] dictating needs so that you know the [86:43] funny thing about security first of all [86:45] is you know it only has to be secure if [86:47] somebody cares about it [86:50] right and then you know for years you [86:52] know security like an operating system [86:54] was virtual memory this process [86:56] virtual memory couldn't look in that [86:57] process virtual memory [86:59] but the code underneath it in the [87:01] operating system was so complicated that [87:02] you could trick the operating system [87:04] into doing something [87:06] so so they basically you went from [87:09] security by [87:10] correct software once you couldn't prove [87:12] the software correct [87:13] they started putting additional hardware [87:15] barriers in there [87:16] and now we're building computers where [87:18] the operating system can't see the data [87:20] the user has and vice versa [87:22] so the operating system can never so [87:24] we're trying to put these extra [87:25] boundaries in but every time you do [87:28] you made it a little more complicated um [87:32] at some level security worldwide is [87:34] mostly with security by obscurity right [87:36] like yeah nobody cares about you in [87:38] particular [87:39] because you're just one out of seven [87:40] billion people like somebody could [87:43] crack your iphone but they mostly don't [87:45] care about it [87:46] and most most you know it's [87:50] it's a funny thing there's a funny arms [87:51] race going on about this [87:53] but it's it's definitely kind of [87:55] incremental a lot of the discovered side [87:56] channel attacks and they weren't that [87:58] hard to fix [87:59] but there'll be some other things and [88:04] you know i'm not a security expert the [88:06] overhead of building security features [88:08] is mostly low the hard part is thinking [88:10] it out [88:11] and deciding what to do and [88:14] you know everyone thought somebody will [88:16] say something like well this is secure [88:18] because the software does accent i [88:19] always think yeah [88:20] just wait 10 minutes and the software [88:22] get more complicated which will [88:23] introduce a gap in it [88:24] so there needs to be real hardware [88:26] boundaries in there [88:28] and there's lots of computers that are [88:30] secure because they don't talk to [88:31] anything [88:32] like there's both you know places where [88:34] the computers are either behind such a [88:36] hard firewall or literally disconnected [88:40] from anything it's the only physical [88:42] attacks work and then the [88:43] guards so [88:47] yeah it's going to be interesting but [88:49] it's it's not super high in my thinking [88:51] i mostly [88:51] follow what's going on and then we'll [88:53] just do the right thing [88:55] but i have no face in security by [88:57] software let's say [88:59] because that always kind of grows to the [89:02] point where it kind of [89:03] violates its own premises you know it's [89:06] happened many times [89:08] you've worked at tesla and when you you [89:10] designed a product specifically for [89:12] tesla [89:13] and you worked at companies who sell [89:15] products to for a wide array of uses [89:18] you know beyond that sort of custom [89:19] workload analysis [89:21] do you consider you know the myriad of [89:23] possibilities of what you're building [89:25] will be used for you know [89:28] and the ethics behind what they might be [89:30] used for or do [89:32] are you just there to solve the problem [89:33] of building the chip for the purpose [89:36] well the funny thing about general [89:38] purpose computing is it can really be [89:40] used for anything [89:42] and so the ethics is more a net good [89:44] better than the net bad [89:47] and you know for the most part i think [89:49] the net good is better than the possible [89:52] downsides [89:53] so but people do have serious concerns [89:56] about this [89:57] the there's all big movement around [89:59] ethics and ai [90:00] and to be honest that the ai [90:03] capabilities have so [90:04] far outstripped the thinking around the [90:06] ethics of that i don't know what to [90:07] think about it [90:09] like what what the current systems can [90:12] do [90:13] is already you know a stripped despair [90:16] you know [90:16] knows what we think and and what we want [90:19] and what we're doing [90:20] and the question is you know how many [90:24] people [90:24] have it have that and one reason to [90:26] build [90:27] let's say you know lower cost ai and [90:30] programmable ai [90:31] is you know i hope and we're talking to [90:35] quite a large number of ai software [90:37] startups [90:38] that you know ai hardware and computing [90:40] is in more people's hands because then [90:42] you have a little mutual standoff [90:44] situation as opposed to [90:46] one winner take all but you know the [90:49] modern tech world [90:51] this has been sort of a winner's take [90:53] all but there's actually you know [90:55] literally several dozen very large [90:58] companies that have [90:59] you know let's say competitive [91:01] relationship with each other so [91:03] that's kind of complicated so i think [91:06] about it some [91:08] um i don't have anything you know [91:11] really good to say besides you know the [91:14] net benefit so far has been [91:16] a positive and having technology in more [91:20] people's hands rather than concentrated [91:22] seems better [91:24] but we'll see how it plays out [91:27] um you've worked for a number of big [91:30] personalities [91:32] you know elon musk steve jobs to name [91:34] two um [91:35] and you it appears you still have you [91:37] know strong contact with elon [91:39] your presence at the neurolink demo last [91:40] year with lex was not unnoticed [91:44] i was i was invited by somebody in the [91:46] neuralink team by the way [91:48] you know i'm in elon i wouldn't say i [91:50] have a lot of contact with him at the [91:52] moment so [91:53] but yeah i knew that development team [91:56] never liked [91:58] so i went over there to talk to those [92:00] guys it was fun [92:01] so you don't stay in touch with elon or [92:05] not i haven't talked to him recently now [92:07] it was it was very much a professional [92:08] not a personal relationship when you [92:10] worked for tesla yeah yeah [92:14] because i was going to ask that um [92:16] because elon's a big believer in [92:17] cryptocurrency and regularly discusses [92:19] it [92:21] you know and as it pertains to demands [92:22] of computing and [92:24] resources for something that has no [92:26] intrinsic value do you have any [92:28] opinions as it comes to cryptocurrency [92:30] not much [92:32] not really i mean humans are really [92:34] weird where they can put [92:35] value in something like gold or money or [92:37] cryptocurrency [92:39] and you know that's a shared belief [92:41] contract [92:42] and what it's based on the best i can [92:45] tell hasn't mattered much [92:47] i mean the thing that the crypto guys [92:49] like is [92:50] it appears to be out of the hands of [92:52] some central government whether that's [92:54] true or not i couldn't say [92:56] and whether how that's going to impact [92:58] stuff i have no idea [93:00] um but human you know group beliefs are [93:03] really interesting because when you're [93:05] when you're building things if you don't [93:06] have a group belief that makes sense [93:10] then you're not going to get anything [93:11] done and group leaves are super powerful [93:14] and they they move currencies obviously [93:17] to politics companies technologies [93:20] philosophies self-fulfillment you know [93:23] you name it [93:24] so that's a super interesting topic but [93:27] the details of cryptocurrency i don't [93:29] care much about [93:30] except as a manifestation of some kind [93:33] of psychological phenomena about group [93:34] beliefs [93:35] which is actually interesting but um [93:38] it seems to be more of a symptom than a [93:40] fundamental [93:42] you know or a random example let's say [93:46] um and yeah for a final question i [93:48] wanted to ask you about going beyond [93:50] silicon [93:51] i mean we've worked been working on [93:52] silicon now 50 plus years [93:55] fully this full silicon paradigm has [93:57] been optimized [93:59] do you ever think about what what's [94:00] going to happen beyond silicon [94:02] if we ever reach a theoretical limit [94:04] within our lifetime [94:07] oh yeah yeah like you know [94:11] my computer started you know with [94:12] abacuses right and then [94:14] yeah you know mechanical relays and then [94:16] vacuum tubes and then transistors and [94:19] integrated circuits and [94:21] you know now the way we built [94:22] transistors like it's like what i don't [94:24] know 12th generation transistor they're [94:26] they're amazing [94:27] and there's more to do the optical guys [94:30] have been actually making some progress [94:32] because they can they can direct light [94:34] through polysilicon [94:35] and do some really interesting switching [94:37] things but that's sort of been you know [94:39] 10 years away for [94:41] for 20 years but they actually seem to [94:43] be making progress [94:45] the economics of biology [94:49] it's like 100 million times cheaper to [94:52] make a [94:53] complicated molecule than it is to make [94:55] a transistor [94:57] like that the economics are amazing [95:01] like once you have something that can [95:02] recon replicate proteins [95:05] like i i know a company that makes [95:07] proteins for a living and we did the [95:08] math and it was [95:10] literally a hundred million times less [95:12] capital per [95:13] per molecule than we spend on [95:15] transistors now when you print [95:16] transistors something interesting [95:18] because [95:19] they're organized and connected in very [95:21] sophisticated ways [95:22] rigid rays but [95:25] you know our bodies are self-organizing [95:27] you know they get the proteins exactly [95:29] where they need to be [95:31] so there's something amazing about that [95:34] and there's so much room as if i'm going [95:36] to say at the bottom [95:38] of how chemicals are made and organized [95:40] and you know convinced to go a certain [95:42] way [95:44] i was talking to some some guys who were [95:46] looking at doing a quantum computing [95:48] startup and [95:49] they were using lasers to quiet down [95:51] atoms and hold them in these 2d [95:53] grids super cool so you know [95:57] i think we've you know barely scratched [95:59] the server zone what's possible physics [96:01] is so complicated and [96:03] you know apparently arbitrary that you [96:06] know who the hell knows what we're going [96:07] to build out of it [96:09] so yeah i think about it um [96:13] and it could be we need ai kind of [96:16] computation in order to organize the [96:18] atoms in ways that [96:19] you know takes us to that next level but [96:22] you know the possibilities are so [96:24] unbelievable it's literally crazy [96:27] so yeah i think about that [96:31] i mean it's really great jim i mean [96:32] thanks you for spending so much time [96:34] with me [96:35] i think i've got another 20 questions [96:36] unfortunately we haven't had time to get [96:37] to [96:38] okay um but but good luck uh i said it [96:41] before in the last interview but again [96:43] good luck with tense tauren [96:44] and uh look forward to seeing what you [96:46] come up with [96:48] okay great hey good to talk to you again [96:52] [Laughter] [96:53] [Music] [97:10] you