why my scripting language is already faster than python

[@leddoo]

here's a little example implementation of a register machine vm: gist.github.com/leddoo/25f307f55bb233fd6f2f900c52fe9367 note: it's supposed to illustrate the idea, not be realistic/fast.

[@swarnavasamanta2628]

Considering most computationally intensive jobs in python are done via specialized libraries written in assembly and C, getting python faster is probably not required as it will cause a massive overhaul to the architecture of the language.

[@failsmichael2542]

Come to Julia. We have some nice cookies here. :)

[@mk72v2oq]

PyPy exist.

[@drkastenbrot]

python makes multithreading and hardware acceleration (like cuda) extremely simple to use, so thats what you do

[@ticTHEhero]

assembly?) what's written in assembly for python?) also pay some respect to Fortran, kid. All of these numpy, scipy etc are almost exclusively Fortran

[@swarnavasamanta2628]

@@ticTHEhero I believe when avx512 came out for new CPUs, around the same time some modifications in assembly were made in numpy and scipy to use those instructions, since support from C compilers came later, initially a lot of libraries used straight up avx512 assembly modules in the beginning.

[@austinmajeski9427]

Funny enough, this is almost exactly what I am doing (and comparing it to), with my own custom language! Nice work!

[@leddoo]

haha, nice :D i'm taking a lot of inspiration from luau (github.com/Roblox/luau) `VM/src/lstate.h` and `include/Luau/Bytecode.h` have some really useful comments! haven't compared perf to luau yet, probably still kicks my ass :D

[@_adeniyi_]

I am also writing a compiled language myself. Doing name resolution currently. 😁

[@yashkhd1100]

@@leddoo That is nice. In fact Lua's VM is one of the best optimized VM for scripting language. I think it boils down to Lua's roots. Lua is/was used in many games as a scripting language that seats on top of GameEngine's C/C++ codebase. Essentially, it allows lot of data driven features in Game without touching core native code.

[@yumeyuki1944]

@@_adeniyi_ what? why are you all guys creating new languages? xd there is too many of them out there already

[@hihihihi3806]

@@yumeyuki1944 Learning

[@WhatDidILearn2023]

This is an incredibly well-done video. Keep up the good work my friend!

[@TheSkepticSkwerl]

The stack is at times easy, and at times difficult to understand. Your animations are so simple, yet so elegant on whats happening. great job!

[@6ujkyujhrbdfgjy5]

As someone who didn't understand what a stack was coming into this, you did a great job at explaining it. Loved the animation.

[@ProjectileGrommet]

The stack animations are crazy awesome. Such effective teaching

[@WilhelmBerggren]

Looking forward to more videos about language implementation comparisons, and your new scripting language. Subbed!

[@tootyrnt5533]

Can we all appreciate how he actually walked through mud to give us that awesome analogy lol

[@nathanoy_]

1:03 "öö-Entschuldigen sie, for loop ist schneller" - i was so cunfused

[@Yutaro-Yoshii]

My brain was trying to parse for loop as a german word, thank you!

[@dimitar.bogdanov]

Hello! I just came across your channel, and I think you're massively underrated. Keep the content up!

[@veerasivarajan6736]

Loved the succinct explanations! Thanks for sharing!

[@fxfawkes]

Well done on the video and on the language, keep it up!

[@jordixboy]

More than stack machine the correct term imo is a "stack based virtual machine". Also, imo the term "bytecode" is not correctly used, for me that "intermediary" code would be more like assembly specially designed to run on the python virtual machine, bytecode imo would be assembly code encoded in binary, for example: 0x2234 where 0x22 is the operation (ADD e.g) and 0x34 would be the parameters But just my opinion!

[@austinsiu2351]

i would love to see how your register machine is implemented

[@leddoo]

oh yeah, a simple example would have been a great idea! well, i made one :D gist.github.com/leddoo/25f307f55bb233fd6f2f900c52fe9367

[@ganster1239]

Sehr interessant! Hat mir einen neuen Einblick in die Funktionsweise von Python gegeben!

[@kellybmackenzie]

I'm writing my own scripting language and it's also heavily inspired by Lua, so this video was really fun to find! This is really awesome. c: Your language looks amazing!!

[@pseudo_goose]

What if you wrote a stack-based language where you had "fused" load-and-operate instructions? The idea is to combine the last load with the operation that follows it. Sort of like accumulator architecture, where the top of the stack is treated as the accumulator. The encoding would be basically the same as a push instruction (accepts a single value operand). Of course it wouldnt be useful in every case, but maybe it could still help with performance and/or binary code size? I think it would be interesting to experiment with something like that.

[@magne6049]

concatenative programming languages, my friend

[@PhilmannDark]

I recommend everyone to try to design a programming language. That's the best way to understand why most of them are the way they are: Making design decisions without understanding or caring for the consequences. For example, one of the worst myths in computer science is that the execution speed is the most important feature. For a lot of code, being able to write it without mistakes or understand it when you have to change it is much more important than speed. In most applications, there is just a small part of code where execution speed really matters. But since execution speed is easy to measure unlike the pains of developers and users which suffer from countless bugs and security flaws. So speed it is, even when it's irrelevant. Case in point: the Python devs took ONE YEAR to come up with an if-else-expression. The result can be understood even by a non-programmer: value = a if condition else b

[@Maric18]

funnily enough i love python but sometimes i hate the infix if value: if condition: a else b is so much nicer to my programmer brain

[@softwarelivre2389]

boolean ? true : false JS can't get any easier than that

[@theothercreare]

Oh I saw your post on discord a while back. This is looking great.

[@swansonair]

A couple of things I learned while working on my own language. It is about twice as slow as Python when calculating the Fibonacci sequence. However, when Python has to use integers it completely shits itself while my language does it in about the same amount of time. Also writing output to the console is much faster in my language. It uses both a stack and registers and supports a couple of numeric types. I think a big factor in the speed depends on how many numeric types you support. If you only do floating point numbers you might gain a lot of speed because there is no need to do any conversions from A to B and vice versa. Also no need to even consider whatever numeric type you're processing because there is only 1, and if you want integers you just round up or down. Lua technically only has doubles so that might explain why it is so fast. Another aspect I've been thinking about is the fact that any stack/register based VM with its own bytecode essentially emulates real hardware. It can't benefit from hardware acceleration to do computation but instead it uses multiple layers of abstractions to achieve a result. Maybe that's why JIT compilers are able to extract more juice because they convert custom bytecode in actual machine instructions which could make execution a lot faster. Anyway interesting video it really gave me something to think about. Edit: Python is sort of cheating by returning +Inf when the number overflows. Reading through the comments someone already pointed that out. It is in fact slower than my language. It would be interesting to see you do this test again with a different computational example where Python can't use trickery.

[@leddoo]

hey, that sounds really interesting! are your integers arbitrary precision or wrapping? (that may explain why your language doesn't shit the bed) how did you optimize writing to the console? > Lua technically only has doubles so that might explain why it is so fast. lua now actually has doubles and integers. though the version i've tested (luau) doesn't have integers, iirc. when it comes to the conversion & avoiding overhead in general, jit compilation and inline caches are really powerful techniques. i'll talk about them (at some point) in the future.

[@Dviih]

I am making a new language very early stage my main goal is to make a real simple syntax and provide C-like performance also using LLVM for that

[@rakaboy1619]

Please do not think that I am in any way discouraging you, but you are making Julia language

[@Dviih]

@@rakaboy1619 No i am not i my current idea isn't to make something like Julia and is far from

[@trainzmarcel2074]

just use luajit

[@Dviih]

@@trainzmarcel2074 Have you ever read my response to the first guy?

[@tordjarv3802]

Wow, that is cool and ambitious. I have played around with llvm myself and knows that is not easy to get into so all respect to you. Even if you end up not using it, it is still a great learning opportunity.

[@AshtonSnapp]

Good to know for whenever I get to deciding on my language’s bytecode and runtime architecture ^_^

[@BanditTech]

thanks for taking the time to go into the logic of this. :)

[@Spartan322]

And that's why CPUs use registers and not stacks. (yeah not entirely, but from implementation details its a lot simpler for overhead to not rely on stacks)

[@doesntlooklikeanythingtome0001]

TIL dis module exists and it's very cool. Great video and explanation. Like others have said most heavy lifting in python is usual handed off to a C library or Cuda. Would love to see vertorized implementations and GPU acceleration discussed more in videos about performance and runtime complexity

[@leddoo]

thanks! hmm, for some reason your comment was held for review. i recently saw this video kzbin.info/www/bejne/rIe4n3aOgNqBhck eremy said that there's a 60,000x difference between naive python & vectorized C, for matrix multiplication. actually crazy!

[@xx_Ashura_xx]

underated channel. please post more about this

[@revengerwizard]

Loved the video, really well made and explanatory, however, I don't think the language being register based is the reason of the performance. My small little scripting language right now is stack based and still it's faster than Python. I think the reason is to be searched more on how efficient or complex the implementation of Python (CPython) is, considering it's really enormous, compared to that of Lua or other scripting languages like mine or yours and maybe certain things aren't implemented as well as they could be.

[@leddoo]

good catch :P the comparison, as presented, is indeed not justified. but i actually think it's fair, given some more context: my compiler used to generate stack-machine-like code. for example, `c = a + b` was turned into `copy t1, a; copy t2, b; add t3, t1, t2; copy c, t3`. so allocating one register for every temporary & copying to the destination instead of writing it there directly. this is equivalent to the code python generates. and the performance happened to be about the same too - the iter-fib function took ~ 650 ms. so the baseline worked out to be about the same. when i made the compiler a bit smarter (i.e. generate `add c, a, b` instead), the execution time of iter-fib went down to 310 ms. however, like you said, it was almost certainly a coincidence that the baseline happened to align with python's performance here. i do however have a hypothesis for why the equivalent code had comparable performance: my vm is currently very slow when it comes to fetching instructions (multiple bounds checks, multiple memory reads). and cpython has a similar per-instruction overhead (for copies): reference counting (and other cpython specific complexities, like you mentioned). anyway, all that is to say: while the vms certainly worked quite differently internally, when executing equivalent byte code, they had comparable performance. btw, when removing all the checks & memory reads from my vm, the execution time goes down to 150 ms. at which point, the stack-machine-like code (that used to have perf comparable to python) would also be significantly faster than python. but currently, this optimization isn't safe, as the necessary byte code validation checks aren't in place yet.

[@SumriseHD]

1:04 He says "Hey, excuse me! for Loop is faster!"

[@trantrungkien2790]

Your explanation about python VM is amazing :D I learned a lot.

[@evan_game_dev]

This video just got recommended to me. How did I not already know you had a channel?

[@leddoo]

hey evan, lovely to see you! i commented "those jump cuts are so relatable" or sth like that on one of your vids. which was about the most indirect way of saying, "as a fellow youtube beginner, i felt that!" :D

[@evan_game_dev]

@@leddoo haha, that makes a bit more sense now

[@xartydev]

wow very nice explanation, keep up the great work bud.

[@iofish__]

great explanation and very nice animation of the stack

[@0LoneTech]

I suspect profiling might reveal that the cost of duplicating references in the stack is rather small compared e.g. to building objects to store the results of calculations.

[@lolcat69]

I am also making my own programming language called "BlockLine" and when i was just prototyping, it was already faster than python xddd... But that is only cuz blockline just work with 'short' variables to restrict you a bit ( cuz, the look and the way it works is inspired in old hardware and languages )...

[@cloudysh]

I liked the explanation. Subscribed from the first video i watched :p

[@danield1303]

"Ey, tschuldigen Sie! For-loop is schneller!" 😂😂 I certainly didn't expect German in this video

[@xtay2287]

Hast mich mit dem Clip im Bad als subscriber bekommen

[@thekwoka4707]

Is the answer "because everything is faster than python"?

[@noodle-eater]

Cool, I want to make my own scripting but dunno what should I make, do you have any suggestion?

[@leddoo]

ooh, sounds fun! if you've never done this before, starting with a simple language is probably a good idea. lisp is about as simple as it gets. i learned a bunch from minilisp. lua, of course, is also pretty cool! :D

[@MarekKnapek]

Instead of compiling scripting language to stack or register based bytecode and interpreting the bytecode ... compile it into LLVM bytecode and then compile the LLVM bytecode to machine code of your computer and execute the machine code directly without any interpretation.

[@danielstromberg]

Python is a language. CPython is an implementation of Python. Python probably beats your language in development speed, which is almost always more important than execution speed. Obsessing about execution speed is largely a thing of the past; I should know because I remember when people thought C might be too slow compared to hand-coded assembly language. If you need more performance from a CPython program, profile to identify your critical section and look at alternative implementations of Python like Pypy, Cython or Shedskin; the latter two can facilitate redoing just your critical section in a faster Python, while the first is something you would normally run your entire program on.

[@victorjans3771]

wallah dieser kanal ist größte entdeckung seit amerika

[@leddoo]

bruuder, größte ehrung seit schulabschluss

[@Turalcar]

Reminds me of that place near the Dead Sea: The Lowest Bar in the World

[@47bytes]

I acknowledged the educational purpose of this video and why you recorded it but I strongly dislike the clickbaity title and the conclusion you came to. You implemented a lisp like language with a register machine which is by nature far simpler then python. Register machines just tend to generate faster code but are harder to implement/reason about when the feature set of the language grows. Saying python generated bytecode is bloated (like stepping through mud) does not in any way acknowledge the fact that it is like that because python has far more features then your language has which comes with the trade off that code compilation is far more complicated. Note: I'm not a python dev or think of python as a superb language I just don't like the one-sidedness of this video

[@leddoo]

> Register machines just tend to generate faster code but are harder to implement/reason about when the feature set of the language grows. could you give an example of how it becomes harder? so far, i've found them much nicer to work with 🤔 > Saying python generated bytecode is bloated does not in any way acknowledge the fact that it is like that because python has far more features then your language yes, because those other features shouldn't affect the performance of floating point code. it's not like i'm comparing a statically typed langauge to python. they both use dynamic types. copying things to the top of the stack is simply unnecessary overhead. this has nothing to do with how many features a language has. unless you can give a convincing argument for why register vms become harder to reason about, as the langauge grows.

[@FlummoxTheMagnificent]

Can you show some of the code behind this language? I’d love to see how it works.

[@ko-Daegu]

great tutorial, you will talk on your language in the future (why you are making it) 😇

[@vcankeklik]

cool content, thanks.

[@deneguil-1618]

i'd actually be interested in an efficient scripting language, my biggest gripe with python is how slow and unefficient it is and i personally believe that as developper we have a responsibility to make the most efficient code possible to reduce the electricity consumption and in turn CO2 emissions

[@alexale5488]

you serious?

[@zkshulgin]

Syntax kinda looks like Lisp!

[@davidscandurra560]

Java bytecode ist ja auch Stack based wird das dann noch von der VM optimiert?

[@leddoo]

> Each frame provides an "operand stack" and an array of "local variables". The operand stack is used for operands to computations and for receiving the return value of a called method, while local variables serve the same purpose as registers and are also used to pass method arguments. Thus, the JVM is both a stack machine and a register machine. (In practice, HotSpot entirely eliminates every stack besides the native thread/call stack even when running in Interpreted mode [...] en.wikipedia.org/wiki/Java_virtual_machine#Virtual_machine_architecture bei java ist der bytecode mehr ein "transfer format", aehnlich wie bei wasm. das werde ich eventuell auch bei meiner vm machen (stack machine transfer format, register machine execution format). denn ich moechte, aehnlich wie bei java ein implementation unabhaengiges, sicheres format haben. der tatsaechliche "runtime bytecode" muss "trusted" sein (da z.b. bounds checks ausgelassen werden).

[@davidscandurra560]

@@leddoo danke für die ausführliche Antwort :)

[@BriceMarnier]

Took me a while to understand how such a large Fibonacci number could be computed so fast (particularily about rust : 10ms means 1 number every nanosecond !), even had to write my own to confirm... Until I read back your code which uses floating point variables ! Unfortunately, all this is a fancy way to return +infinity, there is little computation done compared to actually computing even the first million Fibonacci number. In Python, the integer computation is simply done by initializing a and b to 0 and 1, instead of 0.0 and 1.0 ; for most other languages, ... well, ... it's complicated ;) but for sure it takes waaay longer ! Anyway, the video is interesting to better understand the inner workings of Python, or any language. Very nice animations, too. How about implementing BigInts in luazero, and crush some numbers to fairly compare to Python ? ;-p

[@leddoo]

> Anyway, the video is interesting to better understand the inner workings of Python, or any language. Very nice animations, too. thanks! :D > How about implementing BigInts in luazero, and crush some numbers to fairly compare to Python ? ;-p well, then we'd no longer be comparing VM interpretation performance, but bigint implementation performance ;-p

[@BW022]

I love under-the-hood looks at how languages are implemented. However, it's hard to see why such a significant change to a language is really that much of a benefit for a 2x speed increase. Most programs are I/O bound, so cases where raw processing performance is increased by 2x and still useful is rare. If you are doing graphics processing, encryption/decryption, lots of math, etc. then why was time on Python when you could just write it in C, C++, C#, (or complied Basic, Pascal, FORTRAN, etc.) You use Python because it's handy. If performance is even a consideration, C is approaching 50 times faster even before you look at threading. Write a program and call it, or library, etc.

[@leddoo]

i used openpyxl for quite a few excel automations. it's unbelievably slow. that's a use case, where i chose python for convenience, but definitely felt its slowness in a non-number-crunching context. while i agree that you shouldn't write performance critical code in python, i don't think the language should be slower than it has to be - within reason, of course!

[@BW022]

@@leddoo Languages are tools, you pick the right one for the job. All interpreted languages are slower than they need to be. However, they are fast enough for what they do. Why would you use openpyxl and Python for Excel automations? Excel has VBA written into it. Built-in, no installs/setups, direct access to anything in Excel, even possible to send it to other users, performance is better, etc. For anything simple, I don't see what Python can do which VBA can't? If it is some complex analysis which can't be done in Excel, use a BI/analytics program. And if you are doing some one-time, super-funky thing on the data... why mess around with Python and Excel files? Excel isn't a proper database and Python isn't a high performance language designed for working with large datasets. Toss it in a SQL database and work with it using Visual Studio or something and save yourself the headache. So what if Python runs at half the speed it could? Why is that an issue? Let the program run longer. Who cares if it runs in 5 minutes vs. 10 minutes or 4 hours vs. 8 hours? Why do you care? If it already takes hours and you are running into real-world issues -- it can batch process overnight, thousands of users have to wait, those minutes cost money -- then you've already justified your time and effort writing it using a "proper" compiled language in the first place. I get Excel sheets to look at or work with all the time. Never seen the need to use Python. I'm either going to... (a) use built-in Excel features to work with it, (b) use VBA, (c) going to shove it into some BI/analytics tool, or (d) import it into SQL Server and use VS to work with it and never worry about performance. As handy as Python might be, there's such a small middle ground where I'd need to use it and not run into performance/data-size issues.

[@leddoo]

@@BW022 well, if you don't think a 2x improvement matters, we just have different values. 🤷‍♀ why python for excel: this was about automatically combining multiple spreadsheets into one on a server. i'm not gonna run excel on a server :D

[@BW022]

@@leddoo Well, 2x the performance doesn't matter to you since there appears to be an obvious solution which is 50-100 times faster, yet you don't use it? We know compiled server languages run 50+ times faster, yet you won't just switch to one? There is a saying that only a poor worker blames their tools. Python is an interpreted language... what did you expect? Even if someone made it twice as fast, in a year or two you'd be in the same boat if your Excel sheets were twice as large. Then what? Normal optimizing checklists will have algorithms, data structures, minimizing IO, looking at repeated operations, threading, etc. Now, if these are all optimized as best you can, and you've narrowed it down to the actual language (odd as this seems an IO-bound task), then why not just switch to a compiled language? Or... write a library in a compiled language which you can call that section which you've identified as slow? In 30+ years of programming and systems I've never run into an issue where a 2x language performance issue laid at the heart of the problem. Modern programs as so IO bound this is rare even in interpreted languages and you can already eliminated it using a compiled language which runs 50+ times faster, if that truly is the issue. And I've done a lot of server-side work using Excel. ASP.NET using ADO, from Excel into a SQL Server database, process it there, and Export it out. Today, there are analytics tools which do the same thing and work on massive data sets. They cost far less than my salary. Today, if a 2x performance issues really was at the heart of an issue (say I optimized a C# program as much as we possibly could), I'd tell my boss and there honestly was no other way and just tell him to buy 2x faster hardware vs. expecting the language to become faster. "Well, sir. It's $20k of developer time a month vs. $20k for a new server. If you really need that 2x performance boast I recommend just tossing a faster server at it."

[@techsupport1294]

Love it when people are like, " is faster than ". Keeping it in the scripting dept. how does it compare to lua?

[@leddoo]

i replied to the top comment. about half as fast as luau, when removing redundant runtime checks. but keep in mind, "it's really not optimized yet".

[@devtadeo]

AHH, The amazing world of compilers and virtual machines i love it, nice explanation i did know that python runs in a vm but i didn't know it was stack based like the jvm, if i were u i will make a compiler for ur vm to convert it to native code so speed will increment even more, altough you will add more time between writing the code and executing it because of compiling

[@leddoo]

thanks! yup, trade offs everywhere :D i checked out pypy yesterday, and man, jit compilation makes so much more of a difference than i had expected! while i’ll focus on functionality for now, jitting certainly seems like something to explore in the future 👌

[@akshatw7866]

2:22 Nice!!

[@Yutaro-Yoshii]

Well done sir, you have offseted enough carbon to fly 18 A380s continuously (3 billions python instances each saving one watt of power)

[@codecaine]

Excellent work

[@navigator1819]

Is it possible to implement a register machine in python? If so, why is it not a focus of the python development team?

[@leddoo]

there's this talk about how python's implementation details are leaked into the public interface of the language. kzbin.info/www/bejne/p3SqoJmCft-LbMk maybe the stack is also exposed. then it would be hard to switch to a register vm without breaking existing code.

[@cynical5062]

One thing to note is that you're using python3.9, which is an older version of Python. 3.10 and 3.11 are non-negligibly faster.

[@illunation]

Sehr nices video!

[@tandex3414]

most efficient would be compiling code in memory to machine code and then executing it

[@ChaotikmindSrc]

My script langage is also 2 times faster than python, i'm not sure it is a good reference point XD Btw i do direct ast interpretation, (in flattened and lowered form), which is really the worst we can imagine performance wise.

[@uplink-on-yt]

4:00 "Number crunching isn't exactly Python's primary use case." Have you even seen Python? Number crunching is most definitely Python's primary use case (see data science, when not using R), although it cheats and uses C code for that (see numpy)

[@leddoo]

yes, sorry, what i meant was: scalar arithmetic isn't the primary use case of the python vm. when using libraries like numpy or tensor flow, the majority of the time is spent in C code or on the GPU (ideally). i'll address this in the next video, someone else also pointed this out.

[@alexanders.8681]

Thank you very much!

[@la.zanmal.]

I get that you're focused on the actual stack manipulation rather than the number-crunching for demonstrating the concept, but a test like this looks really nonsensical using floating-point arithmetic... since even fib_py(1477) gives floating-point infinity already. When I switched to integers, fib_py(1000000) already takes several seconds, never mind adding another zero. As usual, though, of course, a better algorithm dramatically speeds things up. I was able to write something optimized based on exponentiation-as-repeated-squaring of the Fibonacci matrix, that was over 100 times as fast for n = 1000000, and even gets n = 10000000 in a few seconds. (Of course, at this point it is multiplying some truly massive numbers.)

[@BubbleBassBackShots]

what video editing/ animating software did you use to make the animations >

[@leddoo]

animations: motion canvas (kzbin.info/www/bejne/jYW4kpl3rNeopKc ) editing software is davinci resolve, though i kinda hate it :D it's really, really, really slow...

[@svaira]

And if you're using a register machine, you might give those instructions numbers too and write it more compact than as a string... Except that's just assembly. Yeah, I'm not surprised, if your language is more similar to the hardware it's running on it will be faster. The reason python is slower is not the design, it's that the silicon is a register machine, not a stack machine [yes there is a stack pointer but that's more the exception, the same way as pythons arrays which are random access]. A more interesting question then is, if a stack machine silicon would run python faster. I don't know of any pure stack machine CPU, but I do recall the 6502 / 6510 is more like a stack machine, given it has only two input registers and one output register / accumulator, maybe that would make for an interesting test

[@robinpage2730]

There was once a stack-based CPU, but it wasn't commercially successful.

[@leddoo]

> The reason python is slower is not the design, it's that the silicon is a register machine, not a stack machine this sounded like a reasonable explanation, so i investigated that. it does not appear to be true. basically, the issue is that we're talking about an interpreter VM here. so the registers/stack live in memory (or the cache). the stack vm does more memory accesses (in particular writes), because it needs to move things to the top of the stack. and because memory is slow (regardless of the underlying CPU arch), that makes it slower. this is kinda hard to explain, i hope i'll figure out how to explain it better for the follow-up video :D

[@YTCrazytieguy]

While the stack/register machine explanation is cool, performance is so sneaky that I have a hard time believing that this completely explains the difference between your language and python. I would really like to see a version of your language that uses a stack instead of a register machine and see the difference 🙂

[@leddoo]

yeah, i'll address this in the next video! basically, my compiler used to generate naive, stack-like byte code (loads/stores before every operation). and when it did that, the byte code was equivalent to the naive python version, and the performance also happened to be about the same (which is kinda important to mention, if i want to attribute the improvement to the register machine, lol)

[@YTCrazytieguy]

@@leddoo oh, nice!

[@rifatno1]

Why use other language for performance, when you've c/c++?

[@koder7738]

I did develop my own VM L1VM. I did write an own compiler for my language Brackets.

[@kurtthorsten4463]

great video, ty

[@defenastrator]

If we had a register machine it would map nicely onto the way processors work. Wait then we could apply traditional optimization techniques & translate it to machine code... Oh wait that's pypy

[@wartem]

Use timeit instead of time.time in order to get more accurate results.

[@coder_rc]

How do you make your videos?

[@leddoo]

for the stack vs register videos i used motion canvas (for the animations). kzbin.info/www/bejne/fmaqdoeFhZycrNU for the semicolon video, i just used screenshots from vscode + google slides.

[@dumbbass8867]

How does it compare to lua, as lua is faster than python?

[@xmorse]

Is this how wasm works too?

[@im_the_kerminator]

You wrote the back code using Rust intriguing I might try something similar

[@contprogramare1126]

Did you inspire from lisp?

[@DanelonNicolas]

I don't know why I was not subscribed to your channel. sorry for that! Now I am :) where can I play with your scripting language?

[@leddoo]

lol :D it'll be public on github with the next vid. but you should probably still wait before messing with it :D

[@Chalisque]

How does it perform compared to lua and luajit?

[@joshuakb2]

I love to see lispy syntax

[@valet_noir]

Amazing !

[@magmabits]

Entschuldigung, for-loop ist schneller!

[@corruption781]

please can you teach me how to parse a bracket function

[@ThankYouESM]

I've been trying to find a way to make JSON through only localhost handle all the math for Python, especially for generating (3D) art sent to it as PNG, but... JavaScript is too difficult for me to understand while Python is super simple by comparison. However... been recently advised to give TypeScript a shot and especially because I plan to create lots of HTML5 games.

[@pik910]

I'd naively assume that register based VMs are better because they can be better optimized on register based hardware.

[@NewbMaster69]

Compare it to C or C++. I feel like python is slower due to overhead.

[@astrolemonade349]

Hello! Have you considered open sourcing the implementation of the scripting language you are working on? Great video!

[@leddoo]

yes, i'll make the github repo public with the next video 👌

[@justin3594]

You should go work for Guido at Microsoft and make Python faster. He has a goal of 5x improvement of speed.

[@itellyouforfree7238]

the best way to make programs written in python faster is to stop using that joke of a language

[@justin3594]

@@itellyouforfree7238 and use what instead?

[@itellyouforfree7238]

@@justin3594 just pretty much any other language is faster. nim is an excellent choice to have good performance while maintaining similarity to python

[@Adityarm.08]

@@itellyouforfree7238 python has it's use cases. I prefer rust when I need performance, Haskell when I just want to solve small elegant mathematical problems, & python when I need to express complex transformations quickly on top of numpy/tf. There are also many many cases where you don't need speed, but ease of expression.

[@leddoo]

same here! rust for perf, python for messing around (though soon i'll say goodbye to python :P)

[@SkyyySi]

I'm pretty sure you meant "LISP-like", not "Lua-like".

[@whu.9163]

Did you use python v3.11 ?

[@leddoo]

no, i used 3.9 3.11 is about 10% faster (on my machine) in this "benchmark". the byte code is almost the same. the only difference is the loop, which saw a slight optimization (only one jump instruction per iteration instead of two).

[@feijoes]

very good video

[@ropi314]

"scripting language💀" - KornPlays

[@todorp4056]

Your language is some dialect of Lisp 😉, the new is the well forgotten oldest language

[@formbi]

those are just s-expressions, Lisps usually have features like macros, tail call optimizations and so on

[@petermuller608]

Writing an interpreter is always fun. However, focusing on performance of languages of vastly different potency is somehow void

[@commarchinin]

Excuse the syntax?! Excuse python's syntax more like, I prefer yours. If you get round to adding syntactic macros (given you've gone the s-exp route, you should!), perhaps try adding Lisp-like let statements? Let statements would really make your examples more readable (if only to me, a Lisper).

[@draido-dev]

Ok lol, leddo got a viral video, good job i guess 🐱

[@janni7439]

Better shower scene than Psycho

[@kotted]

Compare it to pypy

[@leddoo]

pypy takes about 19 ms, which is about 8x faster than my current fastest version. which is quite impressive, as a native rust version takes about 10 ms on my machine. (thanks for mentioning it! i never checked it out. though the video wasn't really about performance, if you know what i mean)