Should programmers learn how to code in assembly? | Lex Fridman Podcast

0:02 There's this nice repo with the assembly lessons.

0:07 First of all, do you think developers should learn how to program in assembly?

0:11 And how would you go about learning it?

0:14 What is this ASM-lessons?

0:19 So, I I personally wasn't happy with the way

0:21 assembly is taught in books and online.

0:24 Cuz it's very grammar focused and you don't in general

0:27 learn a language from learning the grammar and the structure.

0:31 You You learn a language by asking someone what their name is and you start

0:35 from there and you go and solve real

0:37 problems that you have when you want to communicate.

0:40 You don't You don't learn sentence structure.

0:42 This is the interrogative and the adverb and all all

0:44 the assembly books seem to be doing like that going through

0:47 every instruction even ones that aren't really relevant explaining what

0:51 they all do and how they actually doesn't really change much.

0:53 So, And the other problem that we have in our community

0:56 is assembly is taught sort

0:57 of hand-to-hand like person-to-person like blacksmithing one-by-one.

1:02 That's that's the only logical sort

1:03 of analogy and that doesn't really scale online.

1:06 It doesn't do other things.

1:07 So, this this this this I started a set

1:10 of assembly lessons in the in the way it's

1:12 done in FFmpeg which is a little bit different

1:14 to the way assembly in general for I don't know.

1:19 I'm trying to think the other good big

1:20 use case of assembly is in embedded devices

1:22 in really really low power cheap devices

1:25 and that's completely different to what we're doing here.

1:27 I think it would be good if you

1:28 could highlight the requirements which are quite simple.

1:30 It's high school mathematics and C.

1:33 And actually not even C really really is pointers.

1:35 To emphasize yes, we've talked about how brilliant this stuff is.

1:38 But high schoolers like Daniel Kang have written um assembly in FFmpeg.

1:44 I think there's been contributions because of these lessons.

1:48 So, it's really about trying to to get this dying art

1:52 to continue because we've shown it's

1:53 possible with David to produce something amazing.

1:56 Mhm.

1:56 There's still a lot of codecs in FFmpeg

1:58 that are only maybe partially assembly um assembly optimized.

2:03 And so, it really it really starts with basics and continues

2:05 explains a lot of the jargon a lot of the syntax.

2:08 It doesn't really try and explain to you you know interrupt

2:12 handlers and interrupt instructions and all of these different jump targets.

2:16 It actually makes this really vector focused.

2:18 And describes all kinds of registers general

2:22 purpose registers vector registers uh really nice examples.

2:28 This is cool.

2:28 It's a classic it's classic example of FFmpeg.

2:31 Some of this assembly language is is is really beautiful and I

2:34 and I think it's beautiful because it's kind of like flying a Spitfire.

2:37 It's really aviation at its purest but also pushing

2:42 the aircraft beyond what the designer thought was possible.

2:45 So, we're abusing for example sometimes cryptography

2:48 instructions to do certain things and there's

2:50 a level of beauty and art where it's really you and the processor.

2:55 Mhm.

2:56 There's there's there's nothing in between.

2:58 It's you and the the the joystick of the cockpit and you

3:01 and you you move that joystick and it's physically connected to the ailerons.

3:05 And you can push that plane beyond what

3:07 it can normally do and there's a level of [gasps]

3:10 yeah, beauty and amazingness to go that but I don't

3:14 think the sort of person-by-person assembly that is someone taught me

3:18 and I've taught multiple people is going to work long run

3:23 because of the particular flavor and the way that we do it.

3:26 It's literally now I should going to say wizards handing it down.

3:31 I realize I look like a wizard wearing this hat.

3:34 But yeah, basically just like the sages the wise sages handing down the craft.

3:39 Can Can I ask about LLMs?

3:40 Like can they help?

3:42 They had more of an understanding than I expected

3:44 but they are still I've asked it questions and it

3:47 still goes and starts hallucinating not hallucinating but making

3:52 modifications and then I go is it bit exact?

3:54 No, fix it and then it just goes and does the same thing and it's

3:57 going it There isn't the corpus of information like Stack Overflow to work on.

4:03 There is not enough data to train on.

4:05 Um and this is the biggest issue.

4:08 I started my career actually doing some assembly for Itanium, right?

4:13 So, the Itanium is a dead processor type, right?

4:17 Which was done by Intel and HP a long

4:19 time ago when they wanted to do 64 bits well,

4:22 they lost and then we got AMD who did it AMD64 which became X6 X64.

4:28 But Itanium was extremely interesting in the sense

4:31 that those were processors who had a ton of computing

4:35 power to do floats FMAs which is similar

4:39 to what we need now for for LLMs, right?

4:41 And you could pack three operations per line that could be loaded.

4:47 So, basically you had an output of basically 6 billion of operation per seconds.

4:52 But the bus the memory bus only allowed 1.5, right?

4:57 So, you you CPU was four times faster.

5:00 So, you had to do crazy things to to pack things in memory

5:04 reuse the registered and those type

5:06 of semantics no language could do that, right?

5:09 So, like I have the Itanium programming book because

5:15 Intel did amazing books but that's exactly what Kieran says.

5:18 If you don't know what you're you're you're going to do,

5:21 it's impossible to read, right?

5:23 It's a ton of jargon and so on while those lessons are amazing

5:28 because they are targeted to a real problem and you can do it yourself.

5:31 And people have.

5:32 People have their patches and they say oh,

5:33 I studied your lessons and here's my first changes.

5:36 That's amazing.

5:37 And part of that in the lessons is is a framework

5:40 called X86 Inc written by Laurent who was working on X264

5:46 and it allows you to do more things about that to create

5:50 a type of like not caring too much about different calling convention.

5:54 And we had a lot of students who gave

5:58 code to X264 using that a long time ago, right?

6:02 So, it's really doable and I believe it's um

6:06 necessarily to understand assembly language even if you don't

6:10 do it much to understand what's going on inside

6:13 your computer and that will make you a better programmer.

6:17 And I assure you that because doing that you will understand

6:20 some of the architecture of the memory inside your your computer, right?

6:24 Understanding register L1 L2 L3 RAMs SSDs

6:28 disk and so on which are very important because then you have a good programming

6:34 culture that will make you a better programmer.

6:37 Uh what do you think about the Rust

6:38 programming language cuz that's a bit of a meme?

6:41 We have very different opinions with Kieran.

6:43 I think it's valuable what they're doing in terms of memory safety as a concept.

6:47 Can it achieve this some of the speed up that assembly achieves?

6:52 Uh not assembly by hand, no.

6:54 I think that's a given C potentially but I see

6:56 it very It has a very big Esperanto vibe about it.

7:00 It's like we're going to solve this and we're doing this in a particular way.

7:04 Meaning it's a bit too utopian?

7:06 There's a lot of focus on the self-importance

7:08 rather than solving real world problems.

7:10 It reminds me of the Sinclair C5.

7:13 Sir Clive Sinclair of Sinclair computers built a car.

7:16 And he said oh, everyone will be traveling around in in one

7:19 of these electric cars and it was um it first

7:22 reminds me of that where I think the community doesn't the community

7:26 doesn't quite understand that in order to get people to move,

7:30 you have to build something that's as good

7:32 as if not better than what you have now.

7:34 Um yes, people are doing Rust rewrites but if they're if they only if they only

7:40 do 85 90% of the feature set of what what we need like things like core utils,

7:46 that last 1% takes 99% of the time

7:50 to use Elon's famous quote prototypes are easy.

7:52 Like this kind of stuff is easy but this to get a real electric car,

7:55 you have to make a car as good as if not better

7:57 than what we have now and Rust isn't in that stage yet.

8:01 I think we I don't think anyone would object to seeing Rust code in FFmpeg

8:06 but it needs to work as well

8:08 and support the same unit testing as everything else.

8:10 It needs to be flawless.

8:12 It can't just randomly break.

8:13 They can't just randomly break ABI when they want to.

8:16 It needs to It needs to have I think

8:18 more I think it still has only one compiler implementation.

8:21 Yes.

8:22 So, it it's got to be as good as if not better and saying hey,

8:27 here's my utopia of memory safety isn't enough even

8:30 though we we probably all agree that that's the goal.

8:34 So, I've done a ton of Rust and the two

8:38 major topics I had was adding Rust modules inside VLC.

8:42 One of the reasons VLC got popular and which was one of the main architectural

8:46 decision is that VLC is a very small core and a ton of modules, right?

8:51 And so, you can write modules in C C++,

8:56 in Objective-C and anything that is basically interoperable with C.

9:00 And and so, which we we did some Rust modules.

9:04 And so, I have experience on that and and I wrote some of it.

9:07 And also like my my new startup called Kyber

9:09 is an open source project mainly done in Rust.

9:13 Um what Rust is extremely good in in the sense

9:17 that um it's a better C++ that cares

9:21 about memory and allows you to do things about

9:24 memory ownership that no one else can do so far.

9:29 However, it's great when you start a new

9:31 project from scratch and you do everything in Rust.

9:35 But it's very not good when you interrupt with existing part.

9:39 And some part of the Rust community believe that they

9:42 need to rewrite everything and everything will be better with Rust.

9:45 And and the answer is like no.

9:47 Like I'm almost always in all my years of being engineer,

9:53 manager, CTO of startup and so on, don't rewrite.

9:57 Right.

9:57 Is that that's the that's the initial instinct for a lot

10:01 of people when they show up to a code base probably before

10:04 LLMs is like probably because they don't understand the the the wisdom

10:10 of the way things have been done in the past to say,

10:12 "Well, we need to rewrite it."

10:13 Hence why there's a thousand JavaScript frameworks.

10:16 But the reason is the following.

10:19 And this is very important to understand.

10:21 It is an order of magnitude easier to write code than read code.

10:26 Yeah.

10:27 And you see that also with LLM.

10:28 They can write code.

10:30 They analyzing is a lot more difficult.

10:33 And so when you arrive and when you

10:36 arrive to a very complex piece of code, right?

10:39 You you don't understand it, right?

10:41 Um because it's so much more effort to understand the code

10:44 from someone else because you don't have the sole process.

10:47 Um and often I joke about um some some languages mostly uh Pearl for example,

10:54 um which has very complex syntax.

10:56 And imagine I am at my maximum intellectual efficiency in programming, right?

11:03 And I do write the best code ever.

11:05 I will not be able to understanding myself 6 months later, right?

11:08 Because reading code is more difficult.

11:11 So very often you arrive you don't understand all the wisdom,

11:15 all the business logic, the reasons that were done that is maybe not documented.

11:19 And you say, "Well, I'm going to write

11:21 it." And the thing is no, you don't, right?

11:24 Because that's as Kieran said, right?

11:26 "I'm going to rewrite core utilities in Rust."

11:27 And then of course you arrive very quickly

11:30 at 80% um then 90% takes a bit more time and then you got the last ones, right?

11:37 On the other side, right?

11:38 So for new projects, it's great.

11:41 Everything related to parsing files,

11:43 uh networking uh because of the memory uh checker borrow checker,

11:47 it's amazing and there is nothing else.

11:50 To answer a bit differently for us.

11:54 Imagine I take a piece of software like uh David or H.264, right?

11:59 Which has a ton of runtime in assembly, right?

12:02 Um I rewrite the C part in Rust, right?

12:05 So it's more secure.

12:06 Yes, but then you arrive into the assembly and you can

12:10 jump anywhere in the memory because we are doing handwritten assembly.

12:13 So even if I rewrite the C part in Rust for security reason,

12:19 you you break all the security when you

12:22 you write handwritten assembly because we can jump anywhere.

12:26 So in my opinion, we need to do something that is um secure assembly, right?

12:32 So which is compile time check the assembly which is similar to the check

12:36 assembly project that we're doing on on David and H.264 with VideoLAN is

12:42 to start instrumenting your assembly at compile

12:46 time to check that it's not jumping

12:48 anywhere in the memory because else you might rewrite a part of C in Rust.

12:52 But if you want to have the same performances,

12:54 you're going to have inline assembly

12:55 and so you destroy your whole security model.

12:58 Um so that's a bit what I think about Rust.

13:01 I just want I I would say on a personal level, I'm so in awe about the assembly.

13:06 I actually once in a it never gets old the speed improvements to show 62x.

13:12 Uh so there are months but on a personal level,

13:14 I I run our internal test suite at work and just

13:18 see I'm still in awe at the gains we have.

13:20 There there's a source of joy and happiness programming for different reasons.

13:25 But I think one of the greatest happinesses is in optimization of code.

13:31 And it sounds like you're like at the cutting edge of that.

13:35 That was cool.

13:35 In the community, I want to speak about

13:37 two people who are wizards of assembly, right?

13:43 The two of them are actually working living

13:45 in north of Europe uh Sweden and and Finland.

13:49 And um Henrik Gramner knows so much about Intel x86

13:57 assembly that when we ask questions at Intel about things,

14:01 they tell like, "Why are you asking us Intel?

14:04 You have Henrik.

14:05 Henrik knows better." He knows all the cycles of almost

14:09 all the SIMD instruction by all the CPU generation.

14:14 Oh yes, this is a P4.

14:15 This is a Nehalem.

14:16 This is a Core 2, etc.

14:18 That person is like the best person on assembly in the world and he's

14:23 the nicest person that you've seen like very

14:28 He arrive you don't see and he's amazing.

14:30 And the other one is is called Martin Martin Storsjö

14:35 and he's the doing mostly the same on ARM, right?

14:39 So Neon, right?

14:40 And iPhones and Androids and so on.

14:43 And he codes in assembly on his phone editing it with the crappy uh uh

14:53 keyboard like virtual keyboard you have while

14:56 watching his kids play in the playground, right?

14:59 Like like this is just like wizard level.

15:03 So those two people are like Yes.

15:06 So a part when you're programming assembly at that high level,

15:10 a part of that is knowing the architecture that you program on.

15:13 On ARM in particular, yes.

15:14 ARM in particular.

15:16 But x86 I mean these are complicated architectures, right?

15:19 Yeah, but on um in some ways it's

15:22 more x86 with out-of-order execution is not so bad.

15:25 ARM you really need to understand all the different

15:27 generations of ARM processor cuz they're all different.

15:30 There's A72 etc.

15:32 etc.

15:33 And there's the Apple variants, there's this variant, there's that.

15:35 And you need to write code that works efficiently on all of them.

15:38 x86 but broadly speaking you have Intel AMD, you have sub variants,

15:42 but generally speaking there's something [snorts] fast is

15:47 going to remain fast on all of the variants.

15:49 Whereas in ARM it's a completely much more complicated ball game.