Can JavaScript Go Faster? Threading in JavaScript (Data Structures & Optimization)
Вставка
- Опубліковано 15 сер 2021
- Can you make JavaScript run even faster? Or is it limited as a single thread language?
Patreon: / simondevyt
Follow me on:
Twitter: / iced_coffee_dev
Instagram: / beer_and_code
Github: github.com/simondevyoutube/
In this video we talk a bit about JavaScript's mechanisms for concurrency and spreading the work out over multiple threads/cores. We'll cover the web worker API in a bit of detail, dedicated workers, and then we'll move on to creating a small testing setup. It's kind of interesting to explore the threading opportunities that JavaScripts offers through the Web Worker API, the various pitfalls and performance footguns that lurk there, and what you can do to mitigate these issues. We'll also explore using transferable objects with ArrayBuffer, and touch quickly on what SharedArrayBuffer unlocks in terms of concurrency and multiple threads reading/writing.
Links:
developer.mozilla.org/en-US/d...
surma.dev/
surma.dev/things/is-postmessa...
v8.dev/docs/embed
developer.mozilla.org/en-US/d...
developer.mozilla.org/en-US/d...
developer.mozilla.org/en-US/d...
developers.google.com/web/upd...
en.wikipedia.org/wiki/JavaScript
And yes, Node also has threads:
nodejs.org/api/worker_threads... - Наука та технологія
![ПОЛНАЯ ИСТОРИЯ ЭКЗОРЦИЗМА [Топ Сикрет]](http://i.ytimg.com/vi/qBySr6Bt0B8/mqdefault.jpg)
Honestly this is some of the most edge case Javascript stuff I have ever seen. I love it so muchhhh
Your Javascript lessons are "The Best", your experience talks for itself 🔥
Have half an hour of work to kill and didn't want to assign myself a new ticket, then this popped up - truly godsent :D
This is quickly becoming one of my favorite JS channels
I feel like I actually learned about web workers and have a better understanding of what they are and how they work. Way better than random google searches!
8:20 if you could (in depth with examples) explain all shared datatypes and atomics, please do. That's something I wish someone like you would explain to me :)
If this helped you in any way and you'd like to support future vids: www.patreon.com/simondevyt
would really appreciate more videos on multi-threading with Javascript.
Lovely! Quality work as always Simon!
Always a pleasure to watch your content. Thanks for putting these together. ❤👍
Thank you! Thank you! Thank you! I really wanted to see a video from you that included threading!
Amazing video!
Hard to find such good content as this.
Simon you are awesome, I wrote something similar about the JS workers in the other video, but never thought you would actually make it, very thorough I am actually impressed on your dedication!
An amazing 100% interesting up to the point video. Thank you so much!
i loved it man amazing like always, if there was one place that i wish to work at i would wish to work with you you're amazing keep it up!
Awesome video. I love your presentation style.
I really appreciate the research put into this
You are really good at explaining in simple terms.
ahhh thank you! this is exactly the video i was hoping for
Really nice post. Thank you!
That was fun to watch. Thx a toooon
Great video! This is the first video i have seen going deeper into the js threads. Please keep posting more content like this. Do you have blog where you post the video content in text format? That will be great for quick reference.
BTW , in Nodejs environment, we have worker threads which are kind of similar to web workers and solves the same problem.
Nah, this is it for now. If that's interesting for people I could definitely go that route in the future.
Well explained video on using transferrables. I'd love to see a followup on using Shared Array Buffers with Atomics. It'd be nice to see a tech breakdown on typed arrays and how to properly implement them. I'm currently using transferrables for 3D physics animation but would appreciate any insights into making that faster. With 3D simulations I've found every millisecond counts.
This is actually awesome
He never misses, the absolute legend
Thank you father. We love your videos!
this is my favorite "dev/code" youtube channel :)
Very useful, thank you!
This is great, thanks!!
High quality cruftless content. Thanks a lot.
After completing my Basic HTML course today - thank you for that easy tutorial on Javascript.
This smells like sarcasm
@@none0n nah it was my fart you smelled
Super interesting! I was under the influence this was not possible.
You are correct in your interview. I learned this the first time I implemented a more clever free list vs one that was a stupid linear array. Even then the smart one was log n and the array was order N. The performance dropped by 20% because the linear caching vs cache misses of the log N version. i went back to the linear list and got my 20% back.
The new Dune movie was awesome! Still, the David Lynch version will always have a special place in my heart. Great video!
You may be able to see performance gains if you structure the workers as a predefined pool which pulls from a queue of callbacks to prevent unnecessary worker instantiation.
Maybe yeah, would be interesting to see what the cost of spinning these workers up is
@@simondev758 I actually did this for a web game engine project and then you are left with the time spent serializing your objects. in my case was about 60MS round trip. would like to try transferable objects to see if i can use it for a more "real time" approach without stutters in game
Loved this! More generic JS stuff please!
Javascript: One cannot have all the knowledge about me.
SimonDev: I will take that challenge personally.
Dam, this guy is so good. Glad i found this channel a few months ago by searching for a procedural terrain.
Cool stuff
Now please do wasm inside web workers! I played around a little with that but found it too daunting to actually get working
You're a genius
Service workers is a thing if you work with PWA. From iOS 17 there will be support for it, and Android already have good support.
Thanks for info about serialization messages speed and hardwareConcurrency!
very cool - have you looked at nodeJs at all with threading ?
Not really, I glanced at the interface just to see if they had them, didn't look super complicated. I feel like it's more important to get to know the underlying mechanics and how cpu architectures/threading works in general, tradeoffs therein, etc.
nice!
Can you make a video on implementation of spatial hash grid in three js (meshes) ?
8:28 yes I can :D
Thanks for this very nice and informative video :)
Hah nice catch!
What about a video on how to take any old c++ library and making it run with wasm and interacting with JS
I'm aware this is an old video, but for some reason the worker threads are not showing up for me in the performance tab. Do you know if you have to do anything in particular to be able to see the worker threads in the chrome performance tab?
nicely explained. Just one question prevails... WHY CRABMAN?
I have no idea, at some point I picked up that name as a handle and I still use it occasionally.
CS wizardry 💥
I'm actually really looking forward to the new Dune movie 😂
I really wanted this to be a Rust FFI video >.
heh
JavaScript (more specifically in Node) *DOES* support threading although it's limited and abstracted away. Pretty much all async operations like streams, accessing files, handling requests - this is all handled in separate threads using libuv. In the browser you can spawn a separate thread and basically offload computation-heavy tasks to it through its API so the main UI thread will not freeze on you,
I don't quite understand. If we're talking about async operations then the thing we're offloading is largely io, not computation. So it wouldn't be using threads, it would be using something like epoll. I saw that libuv has a thread pool implementation, but since node apparently supports the same Worker thread API as shown in this video, it's not clear whether libuv's pool is just an implementation detail of the Worker API, or what.
Probably you know the following, but maybe worth bringing it up.. One cannot have multi threading with shared data and no means of limiting data access, and thats what JS avoids by being single threaded, and as was covered, you can't access data in other threads the same way you do in main thread
Logical cores are basically threads? And there's no way to know physical cores in javascript?
And that's browser environment right, but what about nodejs is it any different there?
Great video btw.
do you have, or can you make a video about threejs webworkers? from what i understand, you have another instance of threejs running in the background and both share a buffer as intersection
I don't have a video about that, no, but I can look into it a bit.
I appreciate seeing a game dev taking web programming seriously
thats why when i use multiple processes...i use shared memory
with threads in other programming languages you have shared memory by default
Along with all the race conditions and problems of shared memory heh
@@simondev758 one gotta be good with mutex -based constructs and busy-waiting
but before that atomic operations should be abused to its fullest
Can you please share these codes here? I want to play around with that for learning.
Hi, I need your help.
I'm a computer science student working on a project, "Reinforcement Learning based 2D Self Driving Car in JavaScript using no library". I'm using Canvas to draw onto. The Problem is everything is that everything drawn or processed in real-time is being called into animate function that is based on requestAnimationFrame(). I've randomized road-map generation, Terrain generation Cars Drawing, Sensors Drawing, Collision Detections for multiple sensors of every car. Road Borders are being thrown around for calculations. Each Car is Maintaining Neural Networks, Evaluation Functions. I need 1000 instance of my player car object except traffic etc etc. All these calculations are being done on each frame call of requestAnimationFrame() which leads to lag in the game environment. I've no experience regarding multithreading. Can I boost performance in my case using multithreading? Right now, whatever you said did not made much sense to me due to my inexperience.
I've an i7-12H 10 Core 20 Threads 16GB DDR5 Ram Nvidia RTX 3070 8GB Laptop.
Would you share the sources from which you learnt javascript when you started learning ?
I started learning around the start of the pandemic, and really no resources beyond just the MDN docs. I'm an experienced programmer though, almost 20 years of C++ and other languages.
developer.mozilla.org/en-US/docs/Web/JavaScript
@@simondev758 thanks for replying! I had learnt a little bit of javascript before but I couldn't understand a lot of things about why i'm doing a particular thing. I started learning c++ because of that, I thought if I could learn the concepts in a lower level statically typed language everything would make more sense long term and I'd have more transferrable skills
@@razorstone3088 Learning how things work at a lower level will definitely be helpful.
do promises and await async next
// wait for a certain milisecond
function sleep(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
Added to my todo list.
I'm quite newbie in JS, so basically that means that we can create few workers for the efficient tasks and it will work fast? Is there no cons?
No such thing as no cons, just tradeoffs. In these examples, a lot of the tradeoffs came in the form of serialization time vs task length.
Does sharedArrayBuffer would improve it in any way? because it will read/write the same buffer if I understand it
Haven't tested it, it would probably make some things easier like having concurrent threads accessing a central data structure. There's a bunch of added complexity though, if you go that route, with managing concurrent access via atomics.
Great video, thanks, but this whole time I couldn't stop thinking Bob, from Bob's Burgers, switched careers 😂
Flipping burgers doesn't pay the bills, if this UA-cam thing doesn't pan out I'll have to go back to being a spy.
What about C++? Do you think it would scale almost perfectly (i.e., almost 8x faster) in this pure math example?
You'll see gains from just better optimized code, but the overall trend should follow. This test, I had 4 real physical cores and 8 logical ones via hyperthreading, which means 2 threads per core sharing resources.
how to run the code in browser? can I see code?
Are you MadSeasonShow's brother? 😁
I wonder if the JavaScript version made in Rust has significantly better performance than regular JS
You mean Deno? About the same, since the underlying engine is still V8 (C++ based)
I wouldn't expect Rust to come out on top of C++ though, they are roughly the same
@@Soremwar Milliseconds could however become whole seconds with larger code, so in terms of how quick an interpreted (or in the case of JS, just in time compilated) language is, miliseconds are life changing!
@@justanotherhotguy The problem is that when we compare Rust vs C++ we don't even find milliseconds of difference. They both produce about the same output (ignoring the obvious memory safety instructions Rust outputs)
The JS code is often jit'd into machine code, so most of the difference would come from better code generation. That would be my guess.
@@Soremwar Rust's borrow checker prevents you to compiling code that violates its rules so at runtime, there isn't any cost. Bound checking and such in rust will most likely get stripped away if it's unnecessary.
fourth!!!, infinite love from me
Bonus: Launch any function in a thread using
new Worker( URL.createObjectURL( new Blob( [ `(${myThreadedFunction})()` ] ) ) )
At 8:09 Can someone explain for me from line 187 to 191
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Float32Array
There are 4 bytes in a 32 bit float (line 187), the next lines instantiate ArrayBuffers of length "positions.length" x the size of a float, then we pass those as arguments to construct a float32array.
@@simondev758 thanks, also do you post your code on your github respo
we frontend developers usually don't know about this stuff, so it would be nice if you explain what threading was, just a brief explanation would be good. though i think i got the idea in the end
I love these types of videos btw hope you make more of it
You need to dive relatively deep to really get threading and concurrency and when to use it. There are surely good videos in youtube, this one for example ua-cam.com/video/7ENFeb-J75k/v-deo.html
It's just operations being run in parallel. ie. I can use one cpu core to calculate 2+2, and then 3+3 - or I can use 2 cpu cores to calculate both 2+2 and 3+3 at the same time, so it takes half the time (theoretically). A thread is kind of an abstract idea - it's just a piece of code than can be run in parallel (In this case 2+2 is a thread, 3+3 is a thread). One cpu core can run one piece of code at a time - one core to one thread.
The nuances come when you need the threads to share memory. ie. My first thread calculates 2+2 = x, second 3+3 = y, and third x+y = z. I want my first two threads to save x and y somewhere in the memory (RAM) that my third thread can then access. The fastest way is to have all three threads executing in the same context - which just means they share the same memory addresses in the RAM.
The initial problem in this video was that the threads all operate in their own context - they all have their own RAM addresses. Thread 3 does not have direct access to the memory addresses that x and y are saved in. That means for my third thread to get x and y, I would need to copy both variables from one context to another, which takes time.
@@chrishamilton1728 Awesome concise explanation, thanks! :-)
One small nitpick I have is with "One cpu core can run one piece of code at a time - one core to one thread.", cause the Mozilla Docs on Navigator.hardwareConcurrency states:
"Modern computers have multiple physical processor cores in their CPU (two or four cores is typical), but each physical core is also usually able to run more than one thread at a time using advanced scheduling techniques. So a four-core CPU may offer eight logical processor cores, for example. The number of logical processor cores can be used to measure the number of threads which can effectively be run at once without them having to context switch."
@@sanderbos4243 I think that's referring to hyperthreading, which is where some software splits every "physical" core into two "virtual" or "logical" cores. It runs two threads on one core, but alternates which one is running. There can never be two processes running on one core at the same time, that's just not how a cpu works as far as I know. I know you only get like 30% performance gains with hyperthreading even though you're "doubling" the cores.
Edit: turns out modern cpus can do some instructions in parallel, for example an integer operation and a floating point operation. If two threads are being hyperthreaded, then some operations may run in parallel, but it's not the same as a whole other core - hence only 30% gains.
hey hey.....how to draw a path(roads for my city) on the terrain in the video "procedural terrain generation".....plzzz tell me how to do that.... i am so stuck
8:41 For shared array buffers, also note that atomics are not supported in Safari, and Apple has a strong incentive to kill future web-app optimization, so please don't expect to rely on it.
developer.apple.com/safari/technology-preview/release-notes/
Looks like they're being brought back.
@@simondev758 I'll believe it when I see it. Devs can choose what goes into tech previews. Corporate policy controls what makes it to release. (Took them 8 years to support WebGL2, so I'm a little jaded. Obviously, I will be very happy if it I get atomics in production! :-) )
@@jonmichaelgalindo Heh, I used to work on Chrome, so I'm very familiar with how Apple drags their feet. This isn't a slam dunk, but they seem to be actually moving in the right direction so I'm cautiously optimistic.
Another important note about js/node being "single threaded" is that anytime you run an async function, which in js is most of the time, it goes onto a different thread, so thats why js is so much more performant than most people realize.
The javascript async keyword does not run it on a different thread. It just defers execution until after the DOM event, and it runs on the same thread (same js core context). Or so I've been told.
Or is that a non-standard feature of node.js?
@@elijahshadbolt7334 it does run on a different thread and it is a standard feature of any asynchronously run code in nodejs.
@@boot-strapper That is incorrect. Code inside an async function is run on the main thread. Javascript has something called the Event Loop that is used to schedule what code is executed and when. What happens is that, when an Async Function is called, a context is created for that function. The function then runs on the main thread until it hits an asyncronous call. That call can be another Async Function, or a call to one of the APIs provided by the browser. Such as the Fetch API for making HTTP requests. Rather than wait for that call to complete, Javascript will pause the context for that function and have the main thread check the Event Loop for the next scheduled task that it can work on. When the asynchronous call comes back with a response it will register that response to the Event Loop which will have the main thread resume executing the contect of the function when it becomes free again.
It's like going to a restaurant that has a long line. Then, instead of waiting in line, you tell them to text you when there's a table ready and go to do some unreleated errands. When you get the text that says your table is ready, you finish the errand you are currently doing and then head back to the restuarant.
Didn't understand 80% of the video.As I don't know profiling and in-depth javascript etc yet. Just understood the images and your conclusions. Would be great if you could mention that this video was not for beginners.
That's ok, not every video has to be explicitly aimed at beginners. Work your way through it slowly and hopefully everything will land with you.
JEA-va-script
You need to stop smoking man 😄😄
How are you so good at js? I'm advanced and you lose me plenty of times with your videos.
I'm sure you're much more advanced in JS itself, I'm pretty much a n00b there compared to a lot of people. A lot of these concepts, memory, threading, etc. I've been doing extensively throughout my career in C++.
@@simondev758 That makes sense. It's just syntactical differences but the idea is the same. I'm assuming you went to college to learn CS? Very impressive. These videos make me want to go back and major is CS to take my foundations of js and ts to a whole new level. (Or any language really)
First!
javascript threads are way too slow to use, i've tried
I'd be interested in hearing what you tried, and what you were trying to do
@@simondev758 fuzzysearch. but really anything like < 10ms can't go faster with threads, because of all the overhead
yes, it can. no, you shouldn't watch this video. if you need something faster than js, write in something faster than js or you're pissing away time :P
Yeah, that's totally fine if your application is a few hundred, or even thousand, lines long. Rewrite if you need it faster. And if "just use another language" isn't an option? They're locked in to JS for commercial/feature/legacy reasons?
No dude, you're not seeing performance drop-offs because you're using hyperthreads... Your additional threads are actually being starved because you've never implemented an actual work queue. You're also not adding any barriers for memory accesses either, but it wouldn't make much of a difference since the threading model in javascript, implemented using "web workers", is absolute crap. And lastly, you can NEVER make any kind of quality performant software in javascript due to one simple reason: you're never able to actually use the damned CPU to it's fullest!
One CPU core and its hyperthread each have their own ALU, and can each execute SIMD code. With one SIMD operation you could go 128 wide and run it on 4 floats at the same time. You don't have direct access to CPU intrinsics in JS, so you have to rely on your final interpreted code being auto-optimized for parallel work (which it never is... interpreters/compilers are extremely dumb. They also can't understand the context of what you're trying to accomplish).And the CPU will try to fill those "work units" with other unrelated data just so that it optimizes its usage. This means that you're potentially already 4 times slower in JS!! But to fully utilize the core you'd have to go wide on both threads of the same core (that's 8 floats at the same time on 2 threads). And now you realize you're 8x slower in JS!!! But wait, modern CPUs have multiple cores, which means that on a quad core you're 32x slower, or 64x slower on a octacore, than a conventional C/C++ program!!!
JavaScript multi threading sucks, If you run a situation where you need it, you are better off using something else.
Maybe, but I like to dig into "how much" it sucks heh
What else is there for creating web based games? Like, seriously asking... I know the DOM is accessible via other languages but JavaScript and the web are inseparable.
@@Retrofire-47 there is WebAssembly but it's still on it's baby steps, there used to be more options with Flash and the Unity Web player, but those are dead, i guess if you are an web developer then there is not much in alternatives of java script.
@@Galomortalbr I just was reading into Web Assembly. So do you think it's worth trying to use JavaScript's multithreading or is it kind of stupid? I'm just starting to explore this area so I figured I'd ask for your opinion