i think there is some confusion as to the actual meaning of async. Async does not really have anything to do with threads. They are closely related but fundamentally separate. You can have async execution within a single thread, sometimes this is even more performant than using a thread pool. Async execution just means that the event loop can be passed off to other tasks.

Ah yes, multithreaded mutable data. What could go wrong?

People often confuse concurrency with parallelism, concurrent tasks run at the same time, but only one is executed at a given time, parallel tasks are executed at the same time, thus requiring synchronization

Node isn't always single-threaded, as its core is written in C/C++ and certain modules will run in separate threads. But Node's single-threaded nature means we avoid having to deal with potentially difficult to debug problems related to memory sharing / data synchronization between threads. I/O, network, and CRUD operations against a database are usually the bottlenecks, not long-running code blocking the main thread.

Glad this video popped up on my feed, love the way your videos are made! Subscribed :)

just gonna ignore that each worker took more than 2x the time

Ryan, this is very helpful, actually you helped me understand Go, and node more as a professional developer who mains Typescript, Thank you!

NodeJS works exceptionally well for I/O Bound Tasks. Worker has been part of NodeJS since version 12. And Web Workers initially started in 2009.

It is also possible to use the cluster built-in module is well-suited for scaling network applications, the cluster module is more suitable for scaling network applications, while the worker_threads module is more suitable for parallelizing CPU-bound tasks within a single process.

I had to stop watching after around 1:17. The Javascript always run on a single thread, but all of the IO, file handling, etc isn't happening in Javascript. All of those things are managed in a thread pool. By default, NodeJS maintains a thread pool of 4. This can be overridden by setting the UV_THREADPOOL_SIZE env variable.

A few of your videos have been dropped into my homepage, you look like have some big balls man. The videos you make are mostly things I already know but haven't used yet but it's like you're introducing them nicely.

Thanks for sharing this really useful way of using worker threads. I'll have to give this a try.

Very good video, straight to the point, no BS, thanks!

i hit the subscribe button HAAARD im going to explore the rest of your videos and hope they are just as well done! thank you for the information and high quality production!

Glad you discovered it! ~3 years ago I failed a junior interview because the interviewer asked me "why javascript was single threaded". I explained her I felt that the question was a "gotcha question" because the initial affirmation was false and depending on the enviroment you could make use of multiple processes or threads with workers or clusters to achieve multithreading. She laughed at me and told me I was wrong because javascript used the event loop and couldn't run on multiple threads. I don't think she was an engineer but to this day I'm not sure and I think she was following a script, a bad one as you can see... Anyways, thanks for the video! Keep pushing!

Man, congrats! Awesome video quality and content.

The way you speak and explain things is perfect and pleasing to listen to. Cheers

Hey, I had some experience with this feature while doing PWA application. And sadly I should say, that Workers aren't "magic stick", that can fix any performance issue by just wrapping a code into it. One big limitation is that data, transferred between worker and main thread should be serialized. Serialization can cost more than performance you potentially got by splitting algorithm into threads.

I like the format of this video. Subscribed.

Now you got me thinking about a framework for semantic thread-management 🤔Would love to see more about this

wow. just impressive how direct and well executed this video is. And it takes time and work. and you make it looks like simple. Just top of the line Job. Congratulations. The sad part is that I can only give a like once.

Very glad I saw this video! Makes me excited to do some more NodeJS development

That was pretty cool. Thanks for the video!

Excellent vid as always... (and you should probably do voice-over work too, lol) - Have you had any experience with Caddyserver which is written in Go? - I am thinking of using it primarily for its reverse proxy features and it would be interesting to get your take on it...

you also do commercials or radio announcements, by chance? (if not, you should) 😁

Very informative. Thank you!

Thanks for this appreciate the podclass.

Nicely crafted video ryan, really good

Thanks Ryan!

Well done. Clean. Something I will use. Thanks.

Thanks for introducing me to worker threads in Node! :D

That is a very useful video. Thanks a lot!

nice and sharp explanation. Thank you. For a turn-based strategy what should one use?

heads up. Code in the Promise constructor runs SYNC and is blocking! There is no such thing as an async constructor. not even for a promise. Regarding to 3:18 at Line 7. To make this happen in a JS async nature you should use Promise.resolve().then(...your code...) in calling Promise.all([doFib()]) is executing the function doFib() - however, the code runs sync because its calculated in the constructor of the promise which is immediately solving and resolving the task - doing the work immediately, rather than creating a promise that should return once the task is solved. all the functions in Promise.all() are executed one after another before the constructed array is handed to the Promis.all() function - so Promise.all() is receiving an array where all the promises are already resolved and there's nothing to wait for. what you would want to see in the Promise.all() test is not everything being calculated in sync - but printed kinda simultaneous as all of them are actually processed in "fake" async - time-slice parallelism. this is probably affecting the test - i didnt try it myself though because i'm too lazy to type all that code. And one more thing - if you're using workers, you can ease your life with the "comlink" npm packaged. written by former google dev advocate Surma and its reaaaally taking the pain out of worker thread communication.

This example seems to be about parallelization rather than concurrency. The first time the calculations ran on a single core and it wouldn't matter if they ran asynchronously or blocking, because the rest of the cores were idle. The second time the job finished faster because of mutithreading, but the result would be the same even it would run in a blocking fashion.

Came here from Beyond Fireship. Nice video! Subscribed!

Nice video. I finally understand the shared buffer data type.

@3:02 That is why you don't do CPU intensive execution in Node.JS. But for input-output operation it is very optimum. It is still faster than other non-async language backend runtime.

I would love to see more posts / videos like this

NodeJS (or JS) doesn't have a lock for volatile variables, so how can we ensure that two (or more) processes are not changing the same buffer in the memory at the same time?

I don't know the performance difference between fork and worker thread, but i wanted to point to the fact that worker thread create v8 instance which have the overheard of allocating memory and all that stuff because it's fundamentally creating new process

Saw this video and subscribed. Liking the vibe.

I already have a difficult enough time keeping node workers alive for more than a few months without PM2. Can't imagine how bad the reliability would be with that responsibility also being pushed directly into 1 node process, lol.

I learned a lot from this video , thank you so much

Thanks for this video! I am running a nextjs app, where each request takes around 10-20 seconds to complete (some GPU related stuff). The whole app used to freeze when more than 4 users used to connect at a time. It was hard to debug because I thought it should be async, turns out as you said if a blocking operation is performed in an async context, the whole event loop freezes and the users see a 502. I created a redis queue and a separate service that does the blocking requests and everything is working fine now. Would love to try out worker threads, looks promising.

I think you have concurrency and parallelism mixed up. As well as the definition for asynchronous function. When you ran the worker threads they were running in parallel, that is, multiple threads running the same program on the same tick. When you ran asynchronous, those are concurrent.

I find it very invocative how it evokes function.

It is so easier to do in Go though. It is essentially the same amount of code as in the first (not working) example, but it works asynchronously as you would expect. You can create async functions just by adding "go" keyword to a function declaration (or right beside the execution also, if you want). Use a waitgroup instead of Promise.All and it just magically works as you would expect. Crazy, right?

YOOOOO, your intro was amazinggg I thought whole video was like that for a sec hahaha tho if it was ngl it would be hella fun and exciting to watch it sure will take ton of time tho-;''

Great Demo! Thanks.

If you can read between lines then this is definitely a fantastic video. Thanks

great video man! internet needs more guys like you. thank you

Same. Just found out the power of Worker Thread in Nodejs recently.

Really enjoyed it, duuno if it's the voice, but I was glued till the end...Very informative video also

Got insights about load balancing , orchestration and cloud computing . Thanx great for a start !

that is a golden voice for tutorials ❤ i am big fan right now

Thanks for the awesome tutorial,

2:08 Small tip: You may use "console.time" which will log time automatically in ms. Like this: console.time("Fib"); const result = fibonacci(iterations); console.timeEnd("Fib");

Could you please do a follow up video on how to incorporate shared buffer into this implementation?

Workers are really cool if you understand them. I use them for some front-end applications, happy to see they are in node now. They are expensive to create though. They're not equivalent to doing like a goroutine or something.

Nice and accurate video my friend! I wonder if backend frameworks like ExpressJS or Nest take advantage of this technique. Doing some processing on an image or something is a perfect use case to use worker threads.

isn't worker_threads already a thing since NodeJS 10? Still, in most cases, a compiled language will outperform in performance than interpreted language.

Hey Ryan, while I understand this video is to demonstrate multicore execution I think it's important to point out that you can achieve asynchronous execution inside the event loop without workers. It would have been good to see you include the following async version of the code in your demonstration so that users understand there is a middle ground that allows asynchronous execution without requiring worker management. async function fibonacci(n) { return n < 1 ? 0 : n

i know you try to convince me to back to Nodejs, but don't try, i decided to stick to GO xD

The fastest way for two threads to communicate is via a fixed size shared mutable buffer that is allocated once.

Very well done Ryan.

Node는 System call로 던질 수 있는 I/O 작업은 이를 통해 os로 던지고. Crypto나 기타 os로 못 던지는 작업들은 node의 스레드풀을 이용한다고 알고 있습니다. 결국 worker thread를 사용하지 않는다 하더라도 node는 멀티 스레딩을 활용하는 것이지요.

worker threads are using new processes to accomplish theirs task on separate threads (one thread by process in a single thread fashion) you can get the PID of each worker_threads I guess the only multi-thread capabilities is with IO via LibUv using callbacks, promisses and async await on those...

Absolutely amazing Can you make video on Worker threads crash course demonstrating with express as well please

Worker threads are not a new thing in nodejs. It even works in browsers lol. JS ecosystem is still slow and no one writing fast apps in it. Nodejs designed for IO, not cpu-bound tasks

Thank you very much, I did lost an amazing job opportunity because I could not explain exactly it. You did it sou clearly that next time I will no fail 😅

Single thread is the beauty of nodejs because context switching is expensive and you don't have to worry about variable locking and complicated race condition. Node has an event loop and execution stack to handle async operation in single thread. That's proven to be very suitable in server environment in last 10 years. If you have long execution need to pull off from the execution stack, you can simply use setTimeout(() => {}, 0) to allow other execution in the queue to jump in. That's what non-blocking IO means.

Hi Ryan, how then do we decide how many workers to spawn? My basic understanding is a cpu can have multiple cores, and a core can handle multiple threads.

Cluster module is better suited for distributing load horizontally on a node server, while worker threads module is better suited for parallely performing cpu bound tasks. You started this video with the problem of load distribution (whose solution is cluster module) and then suggested worker threads with an example of cpu intensive job.

Ryan, you popped up a few times now -> i subbed

First time on this channel. Dude! You have excellent voice. Great content. Sub & like.

Really interesting, great video.

Hey Ryan, thats a cool video, can you please make a video around JS buffers and how to use them please?

the intro is awesome!

Is there any chance of using a database connection pools, dependency injection, and so forth with workers?

actually, everything that's being called with async is in fact separate thread but it's doing some OS stuff in a background, what you also shown us is concurrency not the parallel execution so in fact it's not fast, it's just handling executions frequently between them, but it's not increasing speed, concurrency only increases speed when it comes to IO bound operations, but this is true for different techs like in Python or Ruby, Java can tho truly run in parallel and utilise all cores, so there are many misconceptions in net about this.

Dude you have an amazing voice. thanks for the video.

Make sure you have the cores to support those threads. If you’re writing multithreaded code and then deploying as a 1-cpu container, you won’t see any benefit.

Great video 🎉 thank you

does it share the loaded lib at runtime ? What if a package has a singleton and it is imported by both workers and master ?? Do they share a ref ? What s the overhead using it ? Besides the sharedbuffer interface, it looks likes a neat improvement of past ipc systems. looks good overall.

I used to use `fork` & `cluster` module to use multiple cores. Now this newly released module seems interesting...

This is the best video ever. First of all it finally explained to me what nodejs is, and secondly such a clear explanation of worker threads and multi threading. 🔥🔥🔥

Great video!

Your tuturials are great. Are you working as js/ts developer or golang? I mean proffesionally :)

I tried to use workers - but I have not seen any improvements. After this I tried clusters - there was improvement. I tested with the Apache ab tool - and there was improvement in performance.

Yep, this is the last straw, I am learning Go, good video.

Very informative video

Friend, this is the first time I join your channel, I'm happy that KZfaq brought me here, your voice is a gift from God. Keep up the excellent work.

Technically fork is only slightly slower these days. One could man handle fork to essentially be threads. In fact, under Linux, threads are not actually "threads" but "light weight processes" and thats because forking is actually what happens when we create threads; only that when we create threads, we dont clone things like the file descriptor table and some other things, so thread creation becomes somewhat faster than a normal fork. That being said, I loved this video. New sub.

very well explained!

Great explanation :)

I try to make the same code but with image resize instead fibonachi(using sharp). And I obtain a little different result. Only 4 workers work in parallel, another wait to them. Why it is working differently?

I would like to see more backend technologies related videos

At 3:05 I guess you meant 'sequentially' instead of 'synchronously'. In your fibo code case Concurrent = Parallel = Synchronous (concurrent not necessarily sync. Async can be concurrent too). Good tips btw.

Video was very informative and things are demonstrated well but where can I get that code please help