Why Python 3.11 is so fast | Guido van Rossum and Lex Fridman

Lex Fridman Podcast full episode: • Guido van Rossum: Pyth...
Please support this podcast by checking out our sponsors:
- GiveDirectly: givedirectly.org/lex to get gift matched up to $1000
- Eight Sleep: www.eightsleep.com/lex to get special savings
- Fundrise: fundrise.com/lex
- InsideTracker: insidetracker.com/lex to get 20% off
- Athletic Greens: athleticgreens.com/lex to get 1 month of fish oil
GUEST BIO:
Guido van Rossum is the creator of Python programming language.
PODCAST INFO:
Podcast website: lexfridman.com/podcast
Apple Podcasts: apple.co/2lwqZIr
Spotify: spoti.fi/2nEwCF8
RSS: lexfridman.com/feed/podcast/
Full episodes playlist: • Lex Fridman Podcast
Clips playlist: • Lex Fridman Podcast Clips
SOCIAL:
- Twitter: / lexfridman
- LinkedIn: / lexfridman
- Facebook: / lexfridman
- Instagram: / lexfridman
- Medium: / lexfridman
- Reddit: / lexfridman
- Support on Patreon: / lexfridman

[@LexClips]

Full podcast episode: kzbin.info/www/bejne/Y3W5qp2arJmnb6s Lex Fridman podcast channel: kzbin.info Guest bio: Guido van Rossum is the creator of Python programming language.

[@arcariusmexen1104]

Thanks, Lex.

[@shambhav9534]

Never in my life did I think I'd listen to a lecture on computation of prime numbers from Guido van Rossum.

[@edbee8508]

@@ohio exactly. It's just lazy techbros who are blown away by this. Musk types.

[@mitchnaake9702]

@@edbee8508 Waaa

[@derrickwango6525]

Life-changing experience bro

[@KilgoreTroutAsf]

boasting about python 3.11 being the fastest yet is like boasting about being the top student in a special ed program

[@marcondespaulo]

Yet Guido makes a mistake. To know if a number is a prime, one divides by each previous prime known: 2, 3, 5... not 4. Still one of the the guys that shaped the world as we know.

[@carlschumacher5510]

This interview reminds me of the issues I had in the 1980's speeding up the looping of my employer's implementation of the byte-coded language "Business BASIC"...FOR I / NEXT I loops defaulted to the case where the internal floating point format was used versus the 99.99%+ case of the 32-bit integer type...I still remember those Asm/C coding days fondly...Visiting in Chicago last summer, walking past a sideway cafe, one patron asked me to explain my custom T-shirt: "Only malloc() can set you free()".

[@nedex3843]

It was a great privilege to listen to Guido van Rossum, thank you sir for your gift to the world, your invention has created opportunities for me and millions of others.

[@stillwell4822]

This discussion did a really good job of speaking in a way that allows beginners to understand

[@harleyspeedthrust4013]

the trick about operator optimization sounds almost exactly like branch prediction. If you have a branch in your code and one path is consistently chosen, modern CPUs will just execute that path and then check afterwards if it was the right thing to do. It's really the exact same idea

[@Oranbar]

Indeed I stumbled upon the same thought. It reminded me of when I learnt how assembly deals with jump operators. Same idea

[@jayknepp108]

Yes, but I think he is trying his best to make it simple to understand for people who haven't studied this deeply

[@MichaelPohoreski]

Modern algorithms using SIMD try to remove branching entirely, aka “branch free”. It can often be faster to do _slightly more work_ (trade latency) for higher throughput.

[@niks660097]

branch prediction is mostly related to L2 cache prefetching instructions and data, but in this case nothing is getting prefetched..

[@Ziferten]

Spectre has entered the chat 👻

[@pawmeowzing2906]

I got to say python father is such a nice guy to explain so much detail to him (so patiently)

[@AlJay0032]

That's why I like languages which do static type inference. It prevents run time bugs and errors and it runs faster while the programmer does not have to write type annotations. The compiler will tell you there is something wrong with the types when the original programmer is still around to understand what the problem is. Then he can fix it before it goes into production.

[@oddquirkz]

I used to love the speed of writing in dynamically typed languages. As I've gotten more experienced, I've learned to love the safety that comes with strong typing an inference. It takes longer to write the code, but less time to *maintain* the code.

[@CreamySpoon]

10:56 That audible scoff during Guido's answer did not go unnoticed, Mr. Fridman.

[@MaxKar97]

Lol yes

[@irrationalpie3143]

That's why I love Lex Clips, it's not always fluffy for the general public. Even as a professional one can learn something from the speakers.

[@Martinit0]

3:39 "Well, actually 10 is divisible by 2" - I LOLd when I realized that Guido actually lives what he did with the original python: why memorize whether 10 is a prime, when you can quickly compute it in you head.

[@danihasbini]

I am learning coding in python at 51 just for fun with no prior coding experience nor use for it. As I suffer from ADHD, my ability to get distracted and waste time never ceases to amaze me. So it's been 4weeks and I am still at list comprehensions. I am not sure why I thought I would understand and relate to this interview :) But I still appreciate it. Now let me go and find something to waste time on.

[@uppityfelon3404]

My ADHD is out of control...I want to learn python but I also want to watch these birds chirp.......

[@andrewdawson248]

I love Python

[@knofi7052]

I love Julia more! 😉

[@masterkraft4746]

@@knofi7052 ewwww

[@vicktorioalhakim3666]

Lex, please invite some of the Julia lang folk for a chat, like Alan Edelman, Chris Rackauckas, Jeff Bezanson, Stefan Karpinski, etc. I'm sure they'll have a lot of interesting things to say about elegant and performant language design.

[@hansdietrich1496]

You mean, those people who startet their language by copying a totally broken language with ridiculously stupid syntax?

[@vicktorioalhakim3666]

@@hansdietrich1496 By broken language, you mean MATLAB?

[@therainman7777]

@@hansdietrich1496Can you name a single part of Julia’s syntax that is stupid?

[@brunobenetti9756]

I figured out by myself that root thing when I was in the first semester of CS and was trying different methods to generate prime numbers. It's what taught me programming logic the most. I used to write down the logic and the code on a notebook and think wow this is complicated, now It's pretty easy to think about those rules I figured out. I just realized I've come a long way.

[@flavioromano]

Same, big moments

[@rbus]

The thing I really, really love about Python, being someone who very much prefers static typing and pre-allocating variables to keep memory structures simple & performance deterministic, is that Python doesn't hide pointers but in fact makes it part of the language, making C and Python kind of a match made in heaven when you want the best of a dynamic scripting language and the low-level performance of C or assembler. Now that's a fucking long sentence.

[@chickengamer14]

Bro wrote a paragraph

[@rbus]

@@chickengamer14 Word

[@MNbenMN]

​@@chickengamer14 hardly

[@mAcCoLo666]

It's not that long actually.

[@rbus]

@@mAcCoLo666 That's what she said

[@aronhighgrove4100]

I really like the range of people you interview. Not all are interesting or great, but many are.

[@AntoshaPushkin]

This sounds like a subtle insult, I like it

[@redpillsatori3020]

@@AntoshaPushkin ..he seems like a mafia gangster from the 30s, who stepped into a time machine, that travelled to the future to interview the creator of Python.

[@AJ213Probably]

Prime numbers are amazing. I have used them for a collision system before because you can uniquely identify objects using primes including if they overlap themselves. E.g. you can tell an ID is the same just by checking modulo like 503 and 1006 are the same ID.

[@InforSpirit]

Do you know if this technique has any established research term, etc.? I created same idea when I was pondering insanity of multi-event sport scoring. I named it as prime-substitution, because you can map ordinal-Naturals with ordinal-Primes and then multiplicate scores. Original scoring is saved as a number. It has limits in space-complecxity as growth of Prime-factorial is insane. And in the end there is still combinatory- problem, where certain combination of event and contender counts still has change of tie. But can be usefull for something else, like unique arithmetic ID:s, but everything prime related are calculation heavy, and most times not usefull.

[@manuelsuazo1125]

simple is a complex subject. I remember once a gold mining company hired me to optimize a fortran code. the code was easy to understand but it was 1100 lines long, but besides taking several weeks to process large volumes of data, in some of these cases it crashed. so I decided to take a different approach and instead of using arrays I used Lists. The resulting prodigy had 117 lines and was 5 times faster, but if you don't know pointers in fortran it is much more difficult to understand the code.

[@Evan490BC]

Ok, I'm really curious how you did that. Arrays in Fortran *should* be super optimised by the compiler; pointers not at all because of lack of data contiguity and jumps. Was it because your data was better modelled by recursive structures?

[@MichaelPohoreski]

3:15 the technique (re)using previous results is called _Memoization_

[@MaxKar97]

Thanks for jolting my memory💡

[@DustinRodriguez1_0]

I have always taken the approach to code that first, you make it work. Then, you make it user friendly. Then, you make it fast. That's just the way to go. I've always been a bit surprised that compilers and interpreters weren't a bit smarter, in the sense that they don't keep track of the constraints that the code has established... like if in a function a variable is set to an integer, same happens to another, and then later they get added together without any code that could change their type intervening, it can 'know' that they must be integers. It should be possible to track this sort of thing all the way from input (whether from keyboard, network traffic, file, whatever) to use, so that the compiler could figure out what is possible and what is not possible once it hits a certain segment of the code. Instructions don't just return results, they establish constraints and that should change how further code is treated, I would think. Python is my favorite programming language. I've been coding since I was 12, and I am 44 now. I've done a litany of many different languages, from x86 assembly to C/C++ to Java, C#, LISP, I even really liked Eiffel for awhile. It is a pleasant surprise that Python is so good for beginner programmers, but as an experienced programmer, I absolutely love it because it makes it easy for me to code as I think, and the guardrails that might be useful for a learning programmer, stuff like strict static type checking and such, are simply not mistakes I make any longer, so those guardrails only get in the way. It does shift some burden onto the interpreter, for sure, but I'm simply not going to send in an argument that doesn't have some necessary method I call on it, so I really don't need all the cruft of having to define its type just so the compiler can do some compile-time checking to warn me about it. I am hoping that one of the parts of the 3.11 speedups focuses on the startup of the interpreter. I know that usually dominates the execution time of many short scripts, with 50% or more of the entire execution time of the script being taken up just getting the interpreter started.

[@SuperVfactor]

Same approach. I think it applies to anything science, trial and error. By making it works, you understand the matter and will look for a better way by learning from the actual working solution. It has to work first since a proof of a 'solvable' solution to a particular problem.

[@AlJay0032]

Always make it right first and in many cases you never should optimize it. About the tracking in the compiler, there are languages which do this. Functional languages which do type inference for example.

[@DustinRodriguez1_0]

@@AlJay0032 I agree. On modern hardware, if your code is slow but you're not dealing with some problem which simply requires a truly profound amount of computation (like on the order of trillions of operations or unavoidable triply-nested loops), it almost always means you chose the wrong algorithm, the wrong data structures, or both. And yeah, type inference is great... but I have yet to see a compiler that takes advantage of the constraints beyond that. It might use a faster floating point low level operation than an integer one on the CPU... but I've never seen one that would optimize away a conditional like "i < 20" based upon there simply being no code paths through the program which could even possibly result in a value of i greater than 19. I don't mean that 3 lines prior i is set to 15 or something, I mean i is composed of digits read from the keyboard and then manipulated, passed through various functions, eventually ending up being passed in and it could be seen by someone who understands the whole process that even if the maximum possible value was input, no matter what the end result would always be less than 20 by mathematical necessity. Most optimizing compilers don't do whole-program dataflow analysis like this. I've just always been surprised when I write some code and I'm like "I know these conditions are going to be met" but then the compiler doesn't seem to 'know' the same limitations. I always assumed compilers were just 'smarter' than humans when it came to code, but hand-tooling low level things still comes in handy, albeit quite rarely nowadays.

[@AlJay0032]

@@DustinRodriguez1_0 Switching algorithms is usually easier in a higher language.

[@InforSpirit]

What is mindboggling, there could easily be both static typing and dynamic typing in Python. In simultaneusly... That would be a step closer to the world where you have one language that can be runtime interpreted (fast prototype) and after with little to no changes to compiled to machine code (fast performance). Type annotation is already nescessary, if you want to do anything complicated with python. Your problem: It is classical hindsight problem. You has the knowledge of program, but computer is stupid as ever. Knowledge mean calculation and that takes resources. Current interpreter only need to know local namespace and not to know whole program (and without annotation, it is very hard to do with computer). Cost of knowledge of every connection in program can easily be higher than some little mistakes in runtime. Generality always makes everything slower, and when you implement own knowledge you always make everything faster (generality: error check everything in production cycle. Knowledge: Check integrity only once in factory's terminal, material does not mutate in production.) But that said, I would love program that analyses every connection in complicated programs and make dynamic visual graph about it. That essentially is same problem.

[@thecompanioncube4211]

Never in my life I imagined Python and fast computation in same sentence

[@oksatoki]

With pandas in 2022 python can process information just as fast as C# for example with 1/10 of the time needed

[@melihcelik9797]

@@oksatoki But pandas is a framework that utilizes native implementation heavily, as well as numpy. They are not vanilla python. They were always faster than vanilla python, and in fact they were as fast as other languages as you have stated. The problem is that python is not really that fast enough if you are using structres of python only. Like, python numpy arrays are waay more faster than python vanilla lists. And even python has some functions that are implemented in native langauge, which makes them a lot faster. For example, if you had a list of integers with the lenght of 5.000.000, calling the python function sum() will actually invoke the native implementation of the sum function which will perform way faster than just suımming the values in your code with a for loop. Even for loops will be faster than the while loops because their implementation differs in the interpreter level, which is of course impelented in a native langauge. I guess what I am trying to say is, python frameworks were never the problem. Python itself was the problem. A developer must know the tricks of using the built-in functions rather than implementing themselves, and that is not as easy as it sounds. Some of the functions can be really tricky to use for your data, and wting a function that iterates over each data in the list might be easier for some cases. If the extra performance is required, in that case the developer must use external frameworks like numpy or pandas, or use built-in funcionts and shape their code around that. Which in return may reduce the readibility and maintanability of that code. That is true for all languages, but that scenario is encountered more frequently with the case of Python.

[@viktorstojanovic9007]

@@oksatoki Yeah but c# feel soo much better to use

[@isodoubIet]

"fast" here is a very relative term.

[@boots7859]

I've read it a lot, on Python forums, and in YT comments so..... Of course, never in your life will Python itself actually be able to fast computationally. Python is as fast as Basic calling assembler routines, nothing else. As an aside, PureBasic built by a 1-2 man team results in a compiled .exe that is basically as fast as C, without having to call external libs. So I was wrong, Python itself is slower than Basic, and with external libs doing the heavy lifting, still nudged out by a Basic.

[@johngodoy2929]

This was amazing! Thank you!

[@curls6778]

Sounds to me like optional typing could help boost performance here… if the user specified a type, the interpreter skips the initial „not-keeping“ and assumes it is going to get that type every time.

[@ianrust3785]

when is the type checking enforced? you'd need an explicit compilation step, but at that point you may as well be using a compiled language altogether. What they could do is just provide official support for compiling python and allow the programmer to choose between using the interpreter or compiling it. Kind of like what Java already does.

[@curls6778]

@@ianrust3785 there already is a compilation step though, it’s being compiled to bytecode, the type checking could be enforced then… but maybe i’m understanding wrong…

[@ianrust3785]

@@curls6778 That's happening at runtime, while the code is being interpreted, on certain critical pieces of code. To do static type checking the whole code needs to be compiled prior to runtime, where you can output an error message & signal the programmer to fix the bug. Something they could also do is use a linter & type hints to do partial type checking... this can be done in python already using some 3rd party tools. If these tools were integrated with the interpreter the optimizer could make more liberal assumptions about type-hinted variables.

[@raianmr2843]

They decided not to go in this route. I forgot the reasoning presented but this is pretty much a closed case.

[@cjsima]

@@ianrust3785 I think it does get compiled before runtime … that’s what .pyc files are

[@0M9H4X_Neckbeard]

This whole clip is just a very roundabout explanation of how Python should just really finally have a static-type mode where I can FINALLY declare a function that really only can ever accept two integers and I really mean JUST TWO INTEGERS not any other type Python!! grrrrrr

[@What-he5pr]

Yeah lol.

[@johnneyland3334]

Awesome video !! Both of you ...Thank you !!!

[@MrAlanCristhian]

Guido: we planing to go up to 3.99 Lex: what happens after 99 Guido: probably just 3.100 🤣

[@Martinit0]

a true programmer would have said 3.9A

[@smorrow]

It's correct, though. They say dot, rather than point, so it isn't a decimal point. You don't have the property that 3.1 and 3.10 are the same thing, or that 3.11 is somewhere between them. Theorem and figure numbers work the same way. I tend to just not pronounce the punctuation at all, but if I did I definitely would never say 'point'.

[@MasterHigure]

23:00 The idea is also used in modern CPUs. It will go down a jump-if branch it has gone many times before while doing the actual test in parallel, and when the test is done, if the assumption was wrong, it will backtrack.

[@therealestsnake]

This is literally my thought! It's basically just a branch prediction.

[@mag2XYZ]

Interesting topic and guest!

[@jordimanyer8543]

The problem with python is that the efficient type-static code needs to be written in C and put into libraries like numpy, then glued together using a 'glue' which is slow and type unstable. This means you are limited to using libraries in order to have an actual performant code, unless you want to get down to compiled code (which is not what most of the python user-base want or is capable of doing). The solution to this is allowing optional typing in the glue (python), so that you can actively choose to make bad/slow (bust easy) code or good/fast (but harder) code. This is what languages like Julia have solved from the get-go, where both the high-performance kernel libraries and the dynamically-typed high-level scripts can be coded in the same programming language.

[@emilysort]

Python is fast and performant for the vast majority of use-cases, and Julia has bugs and has a poor language ecosystem. It takes more than types to make a language, though I will admit for large projects they are sorely needed (but these are 1% of use-cases). You don't need libraries to make python good. Some people choose numpy inappropriately, where even standard lists would be faster (quickly appending values, using disparate objects in your list, etc.). Most things can be done in pure python. Ive even seen entire game engines written in pure python built by solo developers, with really good performance rivalling even that of industrial engines like Unity. Python has a reputation for bad performance that just isn't true, when you look at it realistically and not theoretically. It aint going nowhere.

[@jordimanyer8543]

@@emilysort As a mathematician doing research in computational methods for HPC, I can tell you you are absolutely wrong about the performance of Python versus typed languages. That said, I agree it is good enough for most use cases.

[@emilysort]

@@jordimanyer8543 I agree, typed is better.

[@raianmr2843]

I don't think Python will ever manage to fix a problem so fundamental. It's like asking for natively supported green threads in C - never going to happen. I'm glad languages like Julia exist and I hope they get the mindshare they deserve.

[@Brukrex]

@@emilysort bro scanning pixels is slow and takes so much performance

[@suche_cz]

As Python developer, I would like to have static typed Python. Even for begginers I would be helpfull - it's good to know from beggining to be aware of types on variables and function parametrs etc ....

[@0M9H4X_Neckbeard]

Yep, Pyhon is a neat language but the lack of static typing (or a static-typing-mode) is extremely painful to work with, even disregarding the obvious performance impact

[@2Sor2Fig]

Meh, if you want the performance benefits of typing, you could always just use Cython.

[@AndreCarneiro666]

Variable and function types has a cost. It's performance. If this was not a problem Python could have this feature since the beginning, right?

[@captainzoltan7737]

yeah, i'm a beginner/ not even a proper programmer, and even I prefer static typing. I've done some hello world-esque stuff in c/c++ and some unity c# scripting and fell in love with static typing there.

[@sony3002]

"As a biker, i would like to have 4 wheels bikes." That's basically what you're saying. The difference between a bike and a car is the number of wheels. If you want 4 wheels choose a car, don't use a bike. The difference between a dynamic language and the others, is when types are computed. If you want static types, use a compiled language, don't use a dynamic language like python. I find it so weird when people say "I'm a python developer" while having no idea what Python is...

[@losthighway4840]

A thought I had is why not reapply the addition operator function when the type of the variable gets reassigned? In theory if the type never changes, there wouldn't be a need for all of this accounting. I'm sure there's a reason for this.

[@MrJoegotbored]

That was interesting. Thanks for sharing!

[@johnniefujita]

i find the rienman zeta function as one of the most mind blowing examples of beauty in the world. so aesthetically pleasing. And this beauty is so intrinsically related to the art of building efficient algorithms. Introspecting the unlimited set of general cases of a problem into a single, finite expression is pure gold.

[@brian8507]

Ok math nerd. Calm down. I could say the same thing about bernoulli numbers or the gamma function. They are all the same thing really. You should refrase as: "numbers in general are mind blowing...."

[@caret4812]

it's not really unlimited set of general cases, you're not looking at the values (which are also finite btw, this is CS not math) but rather the types

[@therainman7777]

@@brian8507Wow, what a pointless, useless, and unnecessary response you just wrote.

[@brian8507]

@@therainman7777 eat a pickle (male part)

[@therainman7777]

@@brian8507 Wow, that was even worse than your first comment. Why do you exist?

[@KrisTC]

Lol. Just heard the comment “ better to assume the weather today is the same tomorrow as it is today, because that is better than staying with a random value” to which I say not in Scotland is not. 😂

[@larsnystrom6698]

I remember reading about tagged operations, i think it might have been called, 45 years ago (in Communications of the ACM? Perhaps 1977?). But implemented in the hardware, machine language. Exacly the same idea, but implemented in the machine architecture, instead of in software. I don't think any computer ever implemented it. But I thought it was a good idea!

[@zelastminute]

I used to be a big fan of Python syntax. Still find it really expressive and, as dynamic typing language goes, it is probably the cleanest to work with. But I have come to see dynamic typing as a beginner trap. As Guido mentioned in this video, it is certainly handy to have the flexibility of bringing a variable into life without specifying its type. However, the drawbacks are that it is painful to work with on larger projects, especially with third party code as the compilers/linters provide very to no help as to what a valid argument for a given function call. Moreover, the fact that important performance tricks need to workaround this feature is also confirming that dynamic typing is objectively a bad idea on all fronts, except maybe for beginners or prototyping work... Very interesting talk however.

[@venkataramanapodugu6211]

bro can you explain deeply

[@CTimmerman]

@@venkataramanapodugu6211 CPUs expect exact bits. Some high level languages hide that so you can do big number math without bothering with that, but that comes at the cost of speed. Unreal Engine 5 looks great but doesn't use Python for performance.

[@isodoubIet]

". As Guido mentioned in this video, it is certainly handy to have the flexibility of bringing a variable into life without specifying its type. " At the very least you should have to specify you're declaring a new variable though. How does turning typos from hard errors into silent logic bugs help anyone, especially beginners?

[@strictnonconformist7369]

@@isodoubIet I think the biggest practical benefit for development an interpreted language, whether static or dynamically-typed is that of iteration speed during development/prototyping/learning because you don’t need to wait nearly as long for a build cycle. In that perspective, interpreted languages make for faster human iteration, and compiled languages make for faster computer iteration, and static typing is where both the compiler and human can more quickly settle on an optimal solution. Dynamic typing is most immediately helpful while the human is still pondering types, but once there’s been a clear decision, it ceases to have practical value to remain dynamic, at least at the level of simple operations of simple types, particularly scalars and built-in types like strings.

[@isodoubIet]

@@strictnonconformist7369 The "iteration speed" benefits drop off very early, around when the code is about a page long. After that the interpreted/dynamic nature slows you down because errors are only caught at runtime after a bunch of processing has happened.

[@r.a.9802]

Thank you Lex and Guido

[@cappedvillain2522]

I didnt know lex was this tech savvy.... new found respect for the man

[@stretch8390]

@Armel Talla and also lost a lot of reputation by going to the press instead of peer review at that same institution.

[@NahianRahman_Nehal]

Hey Co you're doing great job by doing these 👍

[@spyral00]

Python is so simple and brilliant. Guido's a genius.

[@robertsutton3666]

"I borrowed things left and right...cut corners". I am not alone hahaha!

[@Az-jt2zp]

"people like fun" these nuggets are the knowledge bombs I'm here for

[@rickymort135]

I don't like it

[@3x3Qt]

Yeah… Guido’s continuously pulling us back down to earth. He’s right that there will always be people doing unrealistic stuff to try and prove a point, even a redundant one. It’s like complaining about the top speed of a bus.

[@arcariusmexen1104]

Simplicity vs performance

[@MrFrimko]

why so? As a C# developer I dont understand why you(python community) speaks that it is impossible to fit both simplicity and perfromance

[@code-dredd]

@@MrFrimko C# is not interpreted in the same way Python is, so it's not an apples-to-apples comparison. Also, simplicity often means the most straightforward implementation whereas the performant ones are often way more complicated. String searching and matching would be a good example. Matrix multiplication algorithms also fall into this category.

[@einzelsorten5783]

Yep, just add performance, static types, no GIL, proper threading, maybe LINQ, and soon, you'll have what C# had 15 years ago. Python is a great example of why popular is not good (and then there's JavaScript, lol)

[@avithedev]

Python being as fast as go would be complete game changer

[@ElPrincip6]

Is it possible or just a dream?

[@christopherprobst-ranly6357]

Not with CPython, no. Pypy maybe but it has other drawbacks.

[@christianm4906]

It is just a bit faster, but you still have other programming languages with performance out of the box.

[@kayakMike1000]

Right now, pypy is not to far behind cPython. Two minor revs behind 3.11

[@JakobKenda]

@@ElPrincip6 no chance, go is compiled to machine code whereas python is interpreted which adds a layer of indirection

[@altairbueno5637]

Guido talks as fast as the Python interpreter runs!!

[@trevorelvis1355]

Wow...I learned alot.

[@sitachouhan1830]

thank you, Guido van Rossum and Lex Fridman

[@kevin2732]

His personal website is my favorite, especially as a developer

[@scienceandmathHandle]

As I have gotten more and more invested into c++ template programming, this discussion reminds me more of a discussion of generic programming in c++, and less of a Python one. I also feel like c++ and python have become closer to each other(in my own view), with "auto", "constexpr", and "std::format". The compiler at compile time in c++ also feels more like the interpreter at run time in python, minus the GIL of course. That is just my opinion and perhaps more of a rambling

[@strictnonconformist7369]

Regardless of all the “looks like dynamic” for “auto”, “constexpr” and “std::format” they’re still statically-determined at compile time, while Python is always at runtime, with an observed repetition slightly optimized for, compared to default dynamic assumptions of the language specification itself. The 3 C++ details you mention all make it easier for the human to reason about the code with less cognitive load, whereas the mentioned implementation details of the Python is all about making it easier for the byte-code interpreter to “reason” about the code with less “cognitive” load.

[@scienceandmathHandle]

@@strictnonconformist7369 Yep I agree. I just think its sort of interesting that parts of this vlog just sort of felt like it could have come out of a cppcon talk. I was looking at the matplotlib cpp source the other day and all the templating just sort of reminded me of how "x=0" in python feels like "auto x=0;" in cpp from a coders point of view. Like you pointed out, it has nothing to do with what is actually going on when it is being used, it just sort of "feels" more similar now compared with old 90s cpp era code writing. Things like smart pointers, auto type deduction, lambdas, all just feel sort of "Pythonesc"(totally not a word) but maybe that has to do more with me learning Python first before I got seriously into cpp. Who knows?

[@strictnonconformist7369]

@@scienceandmathHandle if you want a truly disorienting language for syntax and keywords, go with Swift: it’s sort of like English in that it assimilates words/concepts from many other languages Borg-like while having some things all its own. It has type inference which in theory makes it less explicit for types for writing the code as someone reading the code, but that’s also been known in past versions (I need to check in the current version) to be less than ideal in implementation, resulting in absurdly long compilation/build times, assuming it doesn’t tell you the expression is too complex, if you depend too much on type inference. Swift is a Swiss Army Knife of languages in that, like C++, it’s truly multi-paradigm, and for so many things, there’s not a single “only use this” way of doing things. For supposedly being an easier language to learn, it has a rather large amount of syntactic and semantic complexity. There are parts I love about it (type inference is both a blessing and a curse) where it has grabbed things from elsewhere. It’s even more flexible than C++ in some ways in that due to needing backwards-compatible with Objective-C, it’s simultaneously able to support SmallTalk message type OO that’s not so strictly-typed, while also being able to work with more C++-like strictly-typed objects that help for performance. Like Objective-C evolved to have before the transition to Swift, it uses Automatic Reference Counting, with a few more tweaks: it’s more like COM than the garbage collection of Python or other languages, and is much more deterministic. And yet, Swift, meant as a systems language, doesn’t exactly have a small runtime, so isn’t nearly as suited as C/C++ for embedded microcontroller software. I’d expect Python may be smaller.

[@scienceandmathHandle]

@@strictnonconformist7369 Thanks for your feedback, and take a thumbs up on me! I would like to check out Swift sometime when I get the time. I hear its pretty cool. But unfortunately it is not what what we use at work. I wish I had the time to learn "GO" and "Rust" too! There is only so much time in the day though. But there is a general trend right now towards .NET at work that I may not be able to escape from. So I guess I will see what the future holds.

[@nagoshi01]

So uh... why is it faster?

[@wakari5444]

I‘m a little confused. I thought the more compute intense a task is, the lower is the time portion taken by the interpreter. This would imply that low compute intense programs benefit more from 3.11. Is my assumption incorrect?

[@jellovendigar]

I waited him to ask “why not use optional type annotations in code?”

[@pawmeowzing2906]

Lol good question

[@CTimmerman]

So with 100% code coverage, all types should be known and could be automatically added to the code to speed up first runs on other machines. from typing import Final can be used to create const vars for futher speedups. Or switch to Rust and only mark some things as mutable. V and Nim have simpler syntax, though, but even contracts like Ada/Spark and its mathematical correctness can be generated.

[@ttb1513]

But python allows arrays of heterogeneous types, right? So adding two vectors doesn’t mean it is adding vectors of integers, as elements could be a combination, for example, of integers, BigInts, strings and even matrices. Just as an example. Inferring the types may seem trivial, but the way a language like python handles typing, it is not.

[@aedieal]

100% code coverage doesn't mean 100% branch coverage. Formal verification is close to impossible for python, because there might always be something that goes wrong. One solution could be to have everything bear-typed (assert the types at runtime), but it can be quite expensive.

[@CTimmerman]

@@aedieal MyPy does static type checks with provided type hints, and Cython uses type hints to optimize transpiling to C.

[@What-he5pr]

What about input data lol

[@CTimmerman]

@@What-he5pr input() for utf8 and ctypes for C types.

[@SkyFly19853]

I am happy about it because this is good for video game development.

[@firstnamelastname307]

seems like a debate static versus dynamic type checking, and, if dynamic, it seems a matter of cache-ing. no judgement though :-)

[@Cordeezy_]

I hope I live to see the day of python 3.420 🍀

[@bmatt2626]

21:32 can the programmer not flag edge-case functions to force generic interpretation?

[@fico1557]

my code for the prime number example: from math import sqrt gol = int(input("max broj je:")) i=9 prime = [3,5,7] while i

[@sf2998]

Python is a great language and its not that slow as some people have said it was..

[@kopetannngame]

Lol, it's many times inferior to the C# and C++ programming languages

[@kasimirdenhertog3516]

17:21 'Now, you write your little Python program' - I felt like he was looking down in my soul there for a moment 🫢

[@danielbriggs991]

I was like, "Oh, cool! This would be a good talk to listen to while defining octonion addition and multiplication in Python." Imagine my reaction at 14:00

[@astropgn]

Gotta say, Guido is way nicer than I expected.

[@NoamGonen]

Thank you Lex Luther for this useful clip. Sincerely, superman.

[@miguelredal8536]

Is possible to install PyTorch for python 3.11?

[@arpanmukherjee4625]

So basically start using type hints in Python so that you know you are sending same types all the time.

[@dorbie]

Python is viable for many of its modern uses because of performant C++ library implementations underneath it. Listening to this talk about complex type abstraction at the bytecode level you know that "fast" is a relative term here.

[@mrKreuzfeld]

Wonder if python should allow optional strong typing. One would only use it when one have a bit of code that is just too slow for its purpose.

[@saitaro]

Python is a strongly typed, what you probably mean is static typing.

[@rogerray8764]

How about an option to define types in python to increase optimisation?

[@pawmeowzing2906]

I wonder about this too. Pretty sure they will use break compatibility as an excuse

[@user-mikesmith]

Thinking about the add example from the perspective of what a CPU is capable of, most CPUs can do multiple math operations per cycle without SIMD instructions and many more per cycle with SIMD. What was described here for operators is maybe tens of cycles (or maybe over 100 cycles) for one math operation. The described operator process is several orders of magnitude slower than the theoretical maximum of the hardware. For python, assuming a JIT, why not approach the performance optimizations as how to get close to theoretical maximum capability of the CPU (for tight loops) versus tricks to do better but still orders of magnitude slower than CPU theoretical capability?

[@strictnonconformist7369]

My understanding about the ethos of Python is historically do everything as simple as possible, but no simpler. This certainly has a performance cost. I won’t pretend to know the long-term Python implementation objectives, but a true JIT compiler definitely is not that philosophy. There are scenarios (hard real-time) where consistent known performance is more important than amortized better performance that has performance glitches. I was amused lately to learn there is “circuit Python” intended for embedded microcontrollers. A Python with a true JIT is something I’d never expect to fit in such a scenario. There are certainly great advantages to a language design/implementation that is sufficiently minimal yet complete that you maximize its reach as-is with one implementation regardless of actual machine platform. I’ve not checked if they’ve added a meaningfully-larger amount to it since I used it 10 years ago, but as an example, Lua has in the past been embeddable as a single 29kloc standard C source file. It’s beautifully-portable and embeddable, and more than fast enough for most scenarios, and doesn’t suffer from the GIL, making it easier to work with multiple threads (though the language doesn’t officially support them) by using multiple instances in the same process, as the host process can easily take care of synchronization.

[@ttb1513]

Mike, I get your point. And I do not understand "as simple as possible, but no simpler". Isn’t "but no simpler" redundant? I don’t really see consistent performance for "hard real-time" programs as precluding the larger picture optimizations Mike alluded to. A much faster loop that does several integer optimizations will always perform that way, for integer data types. If the data types happen to be matrices or strings or something, the program will perform consistently, but slower for those types.

[@SigMeStesso]

the whole interview is so amazing it really makes you wonder how the f***k we live in a society where Kanye West gets much more credit and attention than one of the guys that genuinly contributed to shape the world we live in.

[@davidglobex189]

This is how the history of mankind has always been. In the short term we remember the clowns (entertainers) but in the longterm remember the leaders and the scientific progress.

[@bazoo513]

~ 18:40 - This optimization _does_ emanate a hint of JITC aroma.... And, as somebody noticed, of branch prediction... 😀

[@luqmansufian527]

"...all the way to 420." I got it😂

[@1MinuteFlipDoc]

does mypy (variable typing) help?

[@andrews8733]

Not much. Unless types are enforced by the compiler itself, type annotations are really for high level readability and documentation. I like them, and I use them in python, but I dont rely on them that much. And I prefer static typing

[@R4ngeR4pidz]

Where did you find this idea to cache your operations, to avoid doing unnecessary work? Sounds a lot like it comes from JIT compiling

[@PROTAGONIST_48]

More memory usage for more time efficiency

[@mr.RAND5584]

Saint Giudo. Thank you.

[@martinsz441]

I really love Python and it would be soooo amazing if it was 5-10x faster. Thats enough

[@ReflectionOcean]

Choose simplicity rather than performance initially

[@persistentbee]

"Probably go to 4.20" Underrated line

[@germanher7528]

TDLR, it the magnesium, it makes its vowels move faster

[@aronhighgrove4100]

He gets a bit lost in narrow details, and forgets to talk about the bigger picture, or gets so abstract it remains too vague. I mean most of what he said so far until 13:38 can really be said about programming languages in general. Ok, regarding the optimization, the short summary is he does some kind of caching/memoization and code specialization/instantiation, such that generic functions are implemented in more type specific ways, which allows to remove things a generic function would have to do. 19:30

[@Martinit0]

Also, instead of checking in stackoverflow he reads facebook papers.

[@victorh8863]

Anyone know what type of math is best for coding?

[@martinwolf9495]

After Python 3.11 comes Python 95. That's for sure 🤣

[@random4573]

5:14 segmented sieves

[@JohnVKaravitis]

What about add an integer to a float?

[@calebwilliams4real]

🤯 a fast python

[@badxxxmonkey5541]

6:45 I dont know. All my early coding starting off very complicated, bloated and very convoluted.

[@Soppybobs]

So as I understand this as a very green Python dev.. the interpreter stops checkin both operands types after an arbitrary amount of runs. Meaning it assumes types after completing the operation without errors.

[@millionare5446]

guido went completely over lex's head in this conversation

[@battlemode]

The guest is very charismatic

[@AsN..]

Thank you for python

[@carvalho9021]

give this man a Nobel Prize.

[@pabloe1802]

Is annoying when people with a little wrasp of programming says python is not a fast. Chose the right tool for the right job and live with it.

[@TheDiamondCube]

what about +.int?

[@Andrew90046zero]

Can't wait for 3.69

[@eksen7221]

8:33 what is the interpreter

[@stevenondieki5498]

I wonder if adding types makes the compiler guess the type better

[@tolkienfan1972]

You can use types

[@jorge1869]

@@tolkienfan1972 it is a sugar sintaxis.

[@tolkienfan1972]

@@jorge1869 oh. Then I don't see the point

[@bobanmilisavljevic7857]

Ain't no party like a python party 💪🥳