@@jskr456there’s little people of the network card shouting through the network cable. And in the receiving computer there’s little people listening. Don’t let big network deceive you
The write is about writing to the screen. Under the hood it writes to standard output. Under the hood it writes to a file descriptor. Under the hood the file descriptor describes a terminal "device".
Well even with assembly you need to use syscalls so youd need bare metal to actually get "straight to the point", if youre patient enough you can use buttons and switches to write to the display...
@@cybergaz so 47 * 2 = 94 , golang makes 135 according to some other commenter Really nice that golang and rust are so close. what about zig though . some people say that its even more bloat free than C
#1 Zig took 18 syscalls (Zig v0.14, -OReleaseSafe flag enabled) #2 C took 42 syscalls (Clang v14, -O3 flag enabled) #3 Rust took 72 syscalls (Rust v1.81, release enabled) #4 C++ took 75 syscalls (Clang++ v14, -O3 flag enabled) #5 Go took 180 syscalls (Go v1.23.2, -ldflags="-s -w" flag enabled )
Specifically, each line is its own write syscall. First is "File contents:", next is the buffer, next is the empty string after newline. This is really not an equal comparison, because in python he used an iterator to iterate over the lines...
@@Sonyim414 'printf' from libc writes byte-by-byte into allocated buffer, hidden by 'stdout' macro/external variable/a thing, and if stdio detects that file descriptor that you are writing to is a TTY, it writes into it line by line, basically calling 'fflush' on this bufer each time it sees a LF byte.
This is very nice ...probably the trade off between readability and performance and efficiency. Also a little in depth so on every system call there is an interrupt triggers and on every interrupt trigger there is a corresponding "trap handler" which is again maintained by os where there is a system call table which maps calls to its trap handler. It quiet fascinating cause in the end there is a stack frame created for these calls also just like every other function
It would be interesting to do control runs executing empty source files to adjust for the Python/JS initialization, and deduce the call count of the read action specifically
thanks for thinking out loud , and letting everyone know that dumb questions and the best ones and they really fill in the loop holes in your understanding , it takes a lot of courage to do that to answer the question you posited at the end of the video - I don't think that would be possible lets assume you are reading a 10 MB file and printing its contents to the screen - lets say you create a 1 mb read buffer , now you read the file and print , to read the whole file , you would need to make the 10 read syscalls (keeping things simple here for understanding ) - now if we employ your idea of making all the calls at once , that would defeat the whole purpose of having a memory buffer for read - if we make all the read calls at once where would OS write the data it has read , because the buffer is only 1 mb and the point of having a buffer is to constrain memory usage.
You raise a good point, but maybe there can be situations where it does make sense to batch and that can be known to be safe to do. Like, to give a trivial example - only batch different syscalls. Actually, no, just realized, your example is bad. You can't have multiple reads in a batch, since there's user code running between the reads. The batching should only be done by syscalls that happen immediately one after another.
At the end you described iouring, but it cannot be used everywhere, because sometimes you need to know result of one syscall in order to decide whether or which syscall to perform next. If you bring this to the extreme, everything will be running in kennel space. Enter eBPF.
This seems to be mainly just the overhead of the interpreter. I'm more interested in the difference for bigger program, not just this simple "hello world" level program.
To your point re: batching calls. Look at sendfile. It takes two file descriptors and moves data from one to another. When switching from userkernel land memory buffers are copied (userspace cannot access kernel space) and that gets very expensive when sending large amounts of data.
comparing startup + runtime is like diffing between booting Linux and Windows and running a hello world CLI application on each, before shutting them down again.. for C, this comparison would be equal to running an executable straight from UEFI. of course c runs with less syscalls.. because it has no need to carry a insanely huge runtime with it. nodejs, Python and bun are pretty much made for long lasting executions with event handlers etc. by creating sockets and listening to file changes. the time that should be compared against, is runtime. Not startup unless you are building one-shot tools, in which case I'd question if nodejs is actually a good choice for the problem.
Sorry but this is video has way too many problems ;) (1) The number of syscalls impacts the performances, a context switch between two threads of the same process or a switch to kernel space and back can take up to 5 microseconds, so if you are reading 1 byte at time (silly example eh? sadly not too much :( ) from memory and do absolutely nothing else at maximum you can read 200000 bytes (probably its less but let's pretend it's a perfect world and you don't pay the price of the memory copies and various checks). Even if you pin the thread, you would get down to about 2us and this would mean just 1000000 bytes per second ... New kernel components like io_uring implement VERY complex mechanisms to avoid the need of context switching forth and back from the kernel! (2) The version of nodejs in use is fairly old, beginning of 2022, with the 20.15 (which is the LTS not the latests so there might be even more performance improvements) it's down to below 700 (3) Not clear which is the version of python (4) This is minor but the C code does 1 single printf when instead the nodejs and the python version do 1 print per line, this is minor because the file contains just 2 lines NOTE: I am not a fan of node.js at all lol I like facts ;) EDIT: Also would have made sense to have a comparison with some code that was actually doing something because perhaps a lot of these syscalls are done during the initialization phase and the number of them might be much lower while the code runs. It would have been an important and useful comparison.
@@ghassenlabidi5171 to be honest o am not sure of the specifics, I am more highlighting the approach to this specific test / video. I understand that the original. Idea was to highlight all the extra work that these platform do for little reason but it's also very much true that they are built for backend applications and/or long running applications in mind and therefore they are little optimized when it comes to the startup
To exclude initialization, you could start and end with a specific syscall and use awk to select just the relevant ones between, then shell magic to summarize.
@@btimbyindy you are assuming you can issue this unique syscall from the language ;) Perhaps you can but I am fairly certain it would require some esotheric external modules or, at the bare minimum, an FFI module
#1 Zig took 18 syscalls (Zig v0.14, -OReleaseSafe flag enabled) #2 C took 42 syscalls (Clang v14, -O3 flag enabled) #3 Rust took 72 syscalls (Rust v1.81, release enabled) #4 C++ took 75 syscalls (Clang++ v14, -O3 flag enabled) #5 Go took 180 syscalls (Go v1.23.2, -ldflags="-s -w" flag enabled )
shouldn't we also take into account the system calls that are done anyways without reading files? i feel a lot of those system calls are common for all node processes. also some of those reads are due to the script itself, as node and python also have to read the script passed to them. i feel comparing them to a compiled language like c is a little unfair. a more fair comparison would have been go vs c.
Very cool to learn about echo 3 > /proc/sys/vm/drop_caches ! BTW: The man page recommends to first call "sync", such that all dirty objects are written to the cache, before they get dropped again.
The fstat is for the file size, gpt used it to determine the malloc-ed block. Writes are due to writing to the terminal. I wonder why there's a call to pthread and execve, it looks like strace is showing the syscalls it does too
Huh. 430K subscribers, 12K views, yet not even 1K upvotes? Only thing I can figure is that maybe you need to tighten up the editing. If this were half the length I bet you'd get more upvotes. The comment right under your pinned comment explains the call to write(). I guess I'll say it too, that writing to the terminal window which is linked to the stdout of the process is where that comes from, because on Linux everything is a file, even the output to the terminal.
For write calls you are all forgetting kernel needs to update access time in metadata of a file. You can check that via stat command. It will get updated as you read the file and that would count as write.
We are talking about kernel calls here that happen when you access file and kernel is the one updating access time. I think nowadays there is a bit difference here and not every read of file results in an update to access time...
i feel like there is a hierarchy for this. system calls are bad, but, allocating memory is even worse, and making network requests is even worse still. so probably in the whole scheme of things, system calls is the last thing people thing about. but is very interesting.
Even working with memory need a syscall like malloc function , you supposed to mention that in the beginning, but thanks for the video anyway. Follow you from Algeria 🇩🇿
With synchronous syscalls, I don't think it's possible to "batch" them. The kernel wouldn't have the arguments. If you objdump the C code, you'll see before each `syscall` instruction, the code places values in specific registers. With io_uring, this batching is straightforward. You can submit 3 SQEs and wait for all 3 to complete. In that time, your program yields to the kernel and the kernel only resumes that thread when everything is ready. Then you can loop through CQEs and get the results.
I think nodejs python bun require exec to run the file so it might have more syscall but c is compiled in exec and directly executed so it have less syscall.i might be wrong though just my assumption
This seems to be mainly just the overhead of the interpreter. I'm more interested in the difference for bigger program, not just this simple "hello world" level program.
Hussein is basically saying we need to avoid those kernel-user switching again & again, instead do something like an UPSERT or an Asynchronous call you make in JS. Hussein I thought a little bit, I had a question. Wouldn't an Asynchronous call take more time? You will surely have less system call but execution speed wouldn't be less? And won't it create a problem if the 2nd system call is dependent on the 1st one so it went, came back, bought some metadata(read write) and the 2nd call uses it with some of the users input? I'm probably mad or I should do some breathing exercises.
You could use command buffers and queues, the way Vulkan does. And IDK anything about how any of this works, but if Vulkan does it, I'm inclined to think it's fast.
the javascript code could have been much better. especially with such an ancient version of node. i think it misrepresented how bad JS is. JS is bad. but not that bad (copium)
Maybe I would have made more sense to create a dummy Python/Node scripts to see how many of those syscalls are actually to setup Node/The Python interpreter
Watch out mistaking a library for a framework, let alone runtimes in the JS community… You’re either gonna start a third world war or end up in a mysterious us accident, really dangerous thing to get wrong…
What I get is that we need to embed html and js into syscalls. Lol, but seriously. I big part for me to using web technologies is making visual interfaces that works in most systems, in that sense, I need a runtime which might be to two runtimes if also I want to have logic in bun/node/deno or even python with a web interface. I don't want to start talking about electron because holy shit, but then are thing like tauri that uses the os webview whichever is it. Now... How would be a good approach to make logic with C for example, but having a lean web interface?
It's interesting stuff, but I this was a very unfair comparison because the programs did completely different things and I really don't get why you are using an ancient Node version
Speaking of chat GPT, a lot of times when I'm out jogging in between listening to your RUclips videos and other videos I will have conversations with the chat GPT voice mode about these sorts of backend and front and integration issues and other technology ideas I have in the same or simular domains. It would be interesting for you to record a voice conversation with your musings about this with chat GPT or PI AI to see how the conversation goes， then follow up on it to find out if it's expressing something useful or not。 You would get immediate feedback from what might be an expert source if you prompt it correctly， and it would also give us the ability to see if it's able to give useful information the way you do when we're not able to have a direct conversation with you.
I think you are not giving node bun and pthon a fair chance. Sure the c program is fast but if you think carefully we also need to make trace of when we are making the .out executable filein c. We are executing that file but to execute that file we need to first make it and that will surely take more syscalls. Just a observation to point out
I think this “benchmark” is quite frankly flawed. Not because it doesn’t show anything, it’s because it shows things in the wrong light. What you have showcased here is not the objective speed of execution of these runtimes and the number of system calls they make, but the behaviour they show when starting the environment, reading configuration, writing startup logs and all the things they do right on start, which they then almost completely stop doing. The program you wrote in C? - It’s compiled, it has no need to set things up as it’s been done in advance by the compiler. So many people structure their benchmarks in a way that is objectively flawed simply because interpreted languages require some startup overhead put in place by the runtime that simply isn’t there with precompiled programs. If we were to play a fair game, we would need to benchmark the compiler doing its own things together with the compiled program against a script running inside of a runtime.
@@TheOnlyJura Sure, a guy comes with an actual argument to which some random on the internet says "lol no" and leaves. Either provide an argument or leave jerk off.
Yeah, others mentioned this too, and I was curious how much of those extra syscalls were simply initialization stuff that only happens once. Because usually you don't simply run scripts like this. And very often.
By using the word "right?" at the end of most of your sentences, you are confusing the viewer. If I am watching this video to learn, it is uncomfortable being asked if your previous comment is right or not.
Eve since I was a poor kid, I have always hated interpreted or java like languages, I can still remember these poor laptop fans spin up, shitty coded software in shitty languages, now that I have good hardware and stuff runs relatively fine, I still hope go zig and rust save us. Also fk electron
Clearly this guy is just a sell out and barely knows how libc, kernel, or even just python works. Like 80% of those calls are just loading the python standart library. I dont know what you expected, since python is an interpreted language and needs to read every single file thats imported every time its ran.
The real (and unsurprising) takeaway for me was how ugly javascript is… Can‘t even read from a file without wrapping everything in a lambda, just so that you can await something. JS really gives me nightmares
the lambda wasn’t even needed as node has had top-level await support for years. Furthermore, await isn’t even needed either, could’ve done readFileSync instead of async.
isn't a language ultimately just a syntax, so in theory you could write a compiler for Python/JS/etc. , it'd just be difficult and cursed without modifying the labguage first a bit (like typing, memory in general)? I mean, you can do binary operations in JavaScript, so someone very demented could even write the compiler in JS, bootstrapping it from node or whatever 😂
![Stromae, Pomme - “Ma Meilleure Ennemie” (from Arcane Season 2) [Official Visualizer]](http://i.ytimg.com/vi/1F3OGIFnW1k/mqdefault.jpg)
Learn more about how the kernel (Windows and Linux) , get the Fundamentals of Operating Systems oscourse.win
So, the video was published 5 hours ago but uploaded at least 4 days earlier…
Interesting…
Hussein in a few years. "I want to discuss the electric flow in the motherboard when you do network request"
looking forward for it , so finally i can understand how network connections are made and data flows between them
More looking forward for how silicon quality makes software slow
@@jskr456there’s little people of the network card shouting through the network cable. And in the receiving computer there’s little people listening. Don’t let big network deceive you
@@thisisneeraj7133 _Intel's 13th generation:_
😂😂
The write is about writing to the screen. Under the hood it writes to standard output. Under the hood it writes to a file descriptor. Under the hood the file descriptor describes a terminal "device".
Came here to say just that :)
Go is around 185.
Node v20.17 is around 695.
I was wandering for this
What about Rust?
Edit:
Some in the comments had a comparison
c do no bullshit, straight to the point
why is it always an anime pfp? what’s with C and anime pfp’s??
@@me_12-vw1vi It is the law!!!
@@me_12-vw1vi Ying and Yang
@@me_12-vw1vi Cultured programmers
Well even with assembly you need to use syscalls so youd need bare metal to actually get "straight to the point", if youre patient enough you can use buttons and switches to write to the display...
Since we have heated debate between C vs Rust in Linux community, please also try to test Rust with this. Thank you!
That is what I was thinking about!!!
Indeed!
rust makes twice as syscalls as C
@@cybergaz so 47 * 2 = 94 , golang makes 135 according to some other commenter
Really nice that golang and rust are so close.
what about zig though . some people say that its even more bloat free than C
@@Serizon_ yes it makes half syscalls as compared to C
Man I’ve been following you and your podcast for a few years. You are heaven sent and a great teacher.
.mjs is MICHAEL JACKSON JAVASCRIPT FILE 😂
Include Go in future comparisons if possible please!
#1 Zig took 18 syscalls (Zig v0.14, -OReleaseSafe flag enabled)
#2 C took 42 syscalls (Clang v14, -O3 flag enabled)
#3 Rust took 72 syscalls (Rust v1.81, release enabled)
#4 C++ took 75 syscalls (Clang++ v14, -O3 flag enabled)
#5 Go took 180 syscalls (Go v1.23.2, -ldflags="-s -w" flag enabled )
14:37 The write syscall is also used to print stdout
Specifically, each line is its own write syscall. First is "File contents:", next is the buffer, next is the empty string after newline.
This is really not an equal comparison, because in python he used an iterator to iterate over the lines...
@@Sonyim414 'printf' from libc writes byte-by-byte into allocated buffer, hidden by 'stdout' macro/external variable/a thing, and if stdio detects that file descriptor that you are writing to is a TTY, it writes into it line by line, basically calling 'fflush' on this bufer each time it sees a LF byte.
@@rogo7330 interesting. Why is there such a distinction between TTY and non-TTY file descriptors?
This is very nice ...probably the trade off between readability and performance and efficiency. Also a little in depth so on every system call there is an interrupt triggers and on every interrupt trigger there is a corresponding "trap handler" which is again maintained by os where there is a system call table which maps calls to its trap handler.
It quiet fascinating cause in the end there is a stack frame created for these calls also just like every other function
It would be interesting to do control runs executing empty source files to adjust for the Python/JS initialization, and deduce the call count of the read action specifically
this channel is pure gold, phenomenal content
thanks for thinking out loud , and letting everyone know that dumb questions and the best ones and they really fill in the loop holes in your understanding , it takes a lot of courage to do that
to answer the question you posited at the end of the video
- I don't think that would be possible lets assume you are reading a 10 MB file and printing its contents to the screen
- lets say you create a 1 mb read buffer , now you read the file and print , to read the whole file , you would need to make the 10 read syscalls (keeping things simple here for understanding )
- now if we employ your idea of making all the calls at once , that would defeat the whole purpose of having a memory buffer for read
- if we make all the read calls at once where would OS write the data it has read , because the buffer is only 1 mb and the point of having a buffer is to constrain memory usage.
You raise a good point, but maybe there can be situations where it does make sense to batch and that can be known to be safe to do. Like, to give a trivial example - only batch different syscalls.
Actually, no, just realized, your example is bad. You can't have multiple reads in a batch, since there's user code running between the reads. The batching should only be done by syscalls that happen immediately one after another.
At the end you described iouring, but it cannot be used everywhere, because sometimes you need to know result of one syscall in order to decide whether or which syscall to perform next.
If you bring this to the extreme, everything will be running in kennel space. Enter eBPF.
To address that you would need a simple embedded vm or language in the kernel, like how redis uses lua. But that could be a security nightmare.
This seems to be mainly just the overhead of the interpreter. I'm more interested in the difference for bigger program, not just this simple "hello world" level program.
I love how unserious Hussein is in this video. 😂
Liked the video! Thank you for posting, Hussein!
To your point re: batching calls. Look at sendfile. It takes two file descriptors and moves data from one to another. When switching from userkernel land memory buffers are copied (userspace cannot access kernel space) and that gets very expensive when sending large amounts of data.
comparing startup + runtime is like diffing between booting Linux and Windows and running a hello world CLI application on each, before shutting them down again.. for C, this comparison would be equal to running an executable straight from UEFI.
of course c runs with less syscalls.. because it has no need to carry a insanely huge runtime with it.
nodejs, Python and bun are pretty much made for long lasting executions with event handlers etc. by creating sockets and listening to file changes.
the time that should be compared against, is runtime. Not startup unless you are building one-shot tools, in which case I'd question if nodejs is actually a good choice for the problem.
python and js code be like: can you do this task? no but i know guy who knows a guy and he knows a guy and .... knows a guy name kernel , he can
true :D
Bruh ES6 modules are almost 10 years old at this point. They came out in 2015.
This is awesome. I wish you did more languages.
These are like small chunks . How someone become good at it. We need a good mentor . And detailed videos
Awsome explanation. I was exploring ebpf and got notification from your chanel
So happy you jumped on Bun as well.
batching syscalls in one syscall already exists in the kernel, its io_uring haha its even possible doing zero syscall when SQPOLL is enabled
For Bun maybe you should've used Bun.file API, also AI can't write Bun (except for the one on their website)
ai can not do shit
It would've been the same
This was a fun watch. Thanks
14:06 "WE'RRRE GETTING ZEEERRRROOO, ZZZZERRRROOO!" ❤😂
Sorry but this is video has way too many problems ;)
(1) The number of syscalls impacts the performances, a context switch between two threads of the same process or a switch to kernel space and back can take up to 5 microseconds, so if you are reading 1 byte at time (silly example eh? sadly not too much :( ) from memory and do absolutely nothing else at maximum you can read 200000 bytes (probably its less but let's pretend it's a perfect world and you don't pay the price of the memory copies and various checks). Even if you pin the thread, you would get down to about 2us and this would mean just 1000000 bytes per second ... New kernel components like io_uring implement VERY complex mechanisms to avoid the need of context switching forth and back from the kernel!
(2) The version of nodejs in use is fairly old, beginning of 2022, with the 20.15 (which is the LTS not the latests so there might be even more performance improvements) it's down to below 700
(3) Not clear which is the version of python
(4) This is minor but the C code does 1 single printf when instead the nodejs and the python version do 1 print per line, this is minor because the file contains just 2 lines
NOTE: I am not a fan of node.js at all lol I like facts ;)
EDIT:
Also would have made sense to have a comparison with some code that was actually doing something because perhaps a lot of these syscalls are done during the initialization phase and the number of them might be much lower while the code runs. It would have been an important and useful comparison.
This is what I was thinking too!
Plus Bun provides its own way to read files which is way more efficient than using node's "fs".
@@ghassenlabidi5171 to be honest o am not sure of the specifics, I am more highlighting the approach to this specific test / video. I understand that the original. Idea was to highlight all the extra work that these platform do for little reason but it's also very much true that they are built for backend applications and/or long running applications in mind and therefore they are little optimized when it comes to the startup
To exclude initialization, you could start and end with a specific syscall and use awk to select just the relevant ones between, then shell magic to summarize.
@@btimbyindy you are assuming you can issue this unique syscall from the language ;) Perhaps you can but I am fairly certain it would require some esotheric external modules or, at the bare minimum, an FFI module
I feel like I haven't showered in weeks for having this silly reference but I love that 😂
Hussein, your channel is one of the most valuable channels for any modern developer
#1 Zig took 18 syscalls (Zig v0.14, -OReleaseSafe flag enabled)
#2 C took 42 syscalls (Clang v14, -O3 flag enabled)
#3 Rust took 72 syscalls (Rust v1.81, release enabled)
#4 C++ took 75 syscalls (Clang++ v14, -O3 flag enabled)
#5 Go took 180 syscalls (Go v1.23.2, -ldflags="-s -w" flag enabled )
shouldn't we also take into account the system calls that are done anyways without reading files? i feel a lot of those system calls are common for all node processes. also some of those reads are due to the script itself, as node and python also have to read the script passed to them. i feel comparing them to a compiled language like c is a little unfair. a more fair comparison would have been go vs c.
go is 135 I think
Great video! Next time try to do the same in rust and zig xD
printing is writing to stdout, hence the write syscall
Very cool to learn about echo 3 > /proc/sys/vm/drop_caches ! BTW: The man page recommends to first call "sync", such that all dirty objects are written to the cache, before they get dropped again.
great video, I wish you included rust in this
Thank you for doing this video. Keep it up!
insightful
The fstat is for the file size, gpt used it to determine the malloc-ed block.
Writes are due to writing to the terminal. I wonder why there's a call to pthread and execve, it looks like strace is showing the syscalls it does too
Write system call is used to write into the terminal.
Awesome video, I've been thinking about this.
Brilliant! I am going to check java program)))
Huh. 430K subscribers, 12K views, yet not even 1K upvotes? Only thing I can figure is that maybe you need to tighten up the editing. If this were half the length I bet you'd get more upvotes. The comment right under your pinned comment explains the call to write(). I guess I'll say it too, that writing to the terminal window which is linked to the stdout of the process is where that comes from, because on Linux everything is a file, even the output to the terminal.
Well it reads the script first parses it and them runs it, so ofc there will be an overhead
For write calls you are all forgetting kernel needs to update access time in metadata of a file. You can check that via stat command. It will get updated as you read the file and that would count as write.
Also due to this, many times to improve performance you would mount device with noatime and nodiratime, so accesing files does not result in writes.
That doesn't make much sense. Why isn't that part of the read call itself and instead a separate operation made by the process?
en.m.wikipedia.org/wiki/Stat_(system_call)#Criticism_of_atime
We are talking about kernel calls here that happen when you access file and kernel is the one updating access time. I think nowadays there is a bit difference here and not every read of file results in an update to access time...
i feel like there is a hierarchy for this. system calls are bad, but, allocating memory is even worse, and making network requests is even worse still. so probably in the whole scheme of things, system calls is the last thing people thing about. but is very interesting.
Wow.. that's great exercise. Is there any way to see what these calls are actually?
I can sense it, another dev tool them all episode is around the corner
Whats the point of doing bun, should’ve done go/rust
Sorry… why would he do rust/go? Are you just regurgitating whatever is trending?
@@engine_man exactly
Even working with memory need a syscall like malloc function , you supposed to mention that in the beginning, but thanks for the video anyway.
Follow you from Algeria 🇩🇿
malloc isn't a syscall, it's calling the mmap syscall
@@mobod6822
Oh , yeh , thanks ❤️
Where is rust
you also 'write' to stdout, so basically printing to the screen.
I'm curious (and maybe I'll try it) about Go would behave
Somebody else here in the comments said that Go is around 185. And node v20.17 is around 695.
WTF, your videos are so fucking interesting, well done!
With synchronous syscalls, I don't think it's possible to "batch" them. The kernel wouldn't have the arguments. If you objdump the C code, you'll see before each `syscall` instruction, the code places values in specific registers.
With io_uring, this batching is straightforward. You can submit 3 SQEs and wait for all 3 to complete. In that time, your program yields to the kernel and the kernel only resumes that thread when everything is ready. Then you can loop through CQEs and get the results.
I hope you can include Go in your future comparison please
I think nodejs python bun require exec to run the file so it might have more syscall but c is compiled in exec and directly executed so it have less syscall.i might be wrong though just my assumption
This seems to be mainly just the overhead of the interpreter. I'm more interested in the difference for bigger program, not just this simple "hello world" level program.
Hi Hussein Nasser, i hope you're doing great. Do you any proxies that can bridge MQTT and gRPC protocols?
Hussein is basically saying we need to avoid those kernel-user switching again & again, instead do something like an UPSERT or an Asynchronous call you make in JS.
Hussein I thought a little bit, I had a question. Wouldn't an Asynchronous call take more time? You will surely have less system call but execution speed wouldn't be less?
And won't it create a problem if the 2nd system call is dependent on the 1st one so it went, came back, bought some metadata(read write) and the 2nd call uses it with some of the users input?
I'm probably mad or I should do some breathing exercises.
You could use command buffers and queues, the way Vulkan does. And IDK anything about how any of this works, but if Vulkan does it, I'm inclined to think it's fast.
@@mage3690 interesting
Hes the type of prof that could lecture for 10 hours without break
What about write() to stdout...? Since it's literally what your program does
the javascript code could have been much better. especially with such an ancient version of node. i think it misrepresented how bad JS is. JS is bad. but not that bad (copium)
Breaking news, something already written in c does more syscalls than c itself; and water is wet.
can you please do Go, Rust, Zig, Java please?
Maybe I would have made more sense to create a dummy Python/Node scripts to see how many of those syscalls are actually to setup Node/The Python interpreter
This comparison between node and Bun is not pretty accurate since Bun has its own methods for reading and writing files which are way more optimised.
Watch out mistaking a library for a framework, let alone runtimes in the JS community…
You’re either gonna start a third world war or end up in a mysterious us accident, really dangerous thing to get wrong…
what about using node last version using V8 maybe low time more then C.
What I get is that we need to embed html and js into syscalls. Lol, but seriously. I big part for me to using web technologies is making visual interfaces that works in most systems, in that sense, I need a runtime which might be to two runtimes if also I want to have logic in bun/node/deno or even python with a web interface. I don't want to start talking about electron because holy shit, but then are thing like tauri that uses the os webview whichever is it. Now... How would be a good approach to make logic with C for example, but having a lean web interface?
Why not u publish some long project based videos
In assembly that would be even lower
This is a dumb comparison. No one starts a seperate runtime for every file they open. You should open the runtime before measuring.
When did you move to vim!???
Omg update node. Can someone get the stats?
should have compared cat command too...
Wheres Assembly 😢?
Did anyone run for rust?
It's interesting stuff, but I this was a very unfair comparison because the programs did completely different things and I really don't get why you are using an ancient Node version
Speaking of chat GPT, a lot of times when I'm out jogging in between listening to your RUclips videos and other videos I will have conversations with the chat GPT voice mode about these sorts of backend and front and integration issues and other technology ideas I have in the same or simular domains. It would be interesting for you to record a voice conversation with your musings about this with chat GPT or PI AI to see how the conversation goes， then follow up on it to find out if it's expressing something useful or not。 You would get immediate feedback from what might be an expert source if you prompt it correctly， and it would also give us the ability to see if it's able to give useful information the way you do when we're not able to have a direct conversation with you.
I though bun was supposed to be faster than node
He is testing an older version of node, the current can be even slower. The reason can be many things like security updates or support to new features
I think you are not giving node bun and pthon a fair chance. Sure the c program is fast but if you think carefully we also need to make trace of when we are making the .out executable filein c. We are executing that file but to execute that file we need to first make it and that will surely take more syscalls. Just a observation to point out
are you Moroccan?
Interesting seeing moroccan here
What type of programming are on right now ?
Oh, S-Trace. I thought that was your zesty way of saying amazon S3 💀
🔥🔥🔥
He sounds like Gru.
I think this “benchmark” is quite frankly flawed. Not because it doesn’t show anything, it’s because it shows things in the wrong light.
What you have showcased here is not the objective speed of execution of these runtimes and the number of system calls they make, but the behaviour they show when starting the environment, reading configuration, writing startup logs and all the things they do right on start, which they then almost completely stop doing. The program you wrote in C? - It’s compiled, it has no need to set things up as it’s been done in advance by the compiler. So many people structure their benchmarks in a way that is objectively flawed simply because interpreted languages require some startup overhead put in place by the runtime that simply isn’t there with precompiled programs.
If we were to play a fair game, we would need to benchmark the compiler doing its own things together with the compiled program against a script running inside of a runtime.
lol, no
@@TheOnlyJura Sure, a guy comes with an actual argument to which some random on the internet says "lol no" and leaves. Either provide an argument or leave jerk off.
@@TheOnlyJura lol, not an arument
Yeah, others mentioned this too, and I was curious how much of those extra syscalls were simply initialization stuff that only happens once. Because usually you don't simply run scripts like this. And very often.
By using the word "right?" at the end of most of your sentences, you are confusing the viewer. If I am watching this video to learn, it is uncomfortable being asked if your previous comment is right or not.
😮
Eve since I was a poor kid, I have always hated interpreted or java like languages, I can still remember these poor laptop fans spin up, shitty coded software in shitty languages, now that I have good hardware and stuff runs relatively fine, I still hope go zig and rust save us. Also fk electron
you forgot java 😏😏
11:47 - 11:53 😆😆
Clearly this guy is just a sell out and barely knows how libc, kernel, or even just python works. Like 80% of those calls are just loading the python standart library. I dont know what you expected, since python is an interpreted language and needs to read every single file thats imported every time its ran.
So is bun a scam?
No, there are two things to consider here, it is not a full application and the node version is too old
@@andreilucasgoncalves1416 Bun is standalone, i.e. it is independent from the installed node
Also, bun may have more startup overhead even if the actual script execution is faster.
The real (and unsurprising) takeaway for me was how ugly javascript is… Can‘t even read from a file without wrapping everything in a lambda, just so that you can await something. JS really gives me nightmares
No you don't have to write it that way
There are sync versions of those calls.
the lambda wasn’t even needed as node has had top-level await support for years. Furthermore, await isn’t even needed either, could’ve done readFileSync instead of async.
This is just sad. Please never do these "experiments" again
only-interpreted languages can't be described as programming languages IMO
isn't a language ultimately just a syntax, so in theory you could write a compiler for Python/JS/etc. , it'd just be difficult and cursed without modifying the labguage first a bit (like typing, memory in general)? I mean, you can do binary operations in JavaScript, so someone very demented could even write the compiler in JS, bootstrapping it from node or whatever 😂
Awesome content as usual
14:40 isn’t that write just the printf?
Yup, others said it as well. It's also potentially setting the atime (accessed time) on the read file.