WebGPU :: Javascript at the speed of Light 

💣Corrections of Mistakes: 6:10 - The Big O run-time of a compute shader is not Constant! It's O(n/p). n refers to the number of work-item elements, which is a different variable from the number of processors (p). Of course p >= n can happen, but they are two distinct variables. In order for p to affect n's complexity, then p would have to scale with n's complexity in some way. p is just a very big constant (for a specific device). 2:19 - Computer Engineers didn't invent Big O. Mathematician Paul Bachmann did. 5:04 - I didn't explain how to write WGSL in this video. To learn a bit more about this language, take a look at my previous video. 5:52 - When you have a for loop, the big o run-time is O(n) only if the stuff that's happening in the loop is running in constant time. 12:52 - I'm sorry for my incompetence in writing rust. Maybe I shouldn't have used it in the video. 15:11 - Here I'm comparing Binary Tree implementation in WebGPU to DFS implementation in C++ and JS. I should've been more clear about this. 17:23 - Here in this screen shot, I forgot to use the WindTurbulenceForce which is being used in the compute shader. 19:08 - I lied. Lying is not good 🙂

Javascript isn't slow, when compared to its peers. Its slow if you're comparing it to C/C++, Rust aka compiled languages and even java/C# compiled bytecode languages. But Javascript compared to python, perl, php, ruby, lua, aka interpreted languages, Javascript is literally the fastest. The issue is people like using Javascript for things that it shouldn't be used for, so it feels slow.

There is few things I need to point out in the video. - The time complexity is made to compute the time taken by an algorithm to run over N items. In this case of a simple algorithm such as addition of two arrays of N elements, the time complexity is O(N) both in CPU or using the shader. The algorithm is exactly the same in both case so usage of O notation doesn't make sense in this context. The difference in speed here is the number of core the GPU has. Basically we compare O(N) with something like O(N/512) or even more depending of your GPU chipset. Addition of two array is certainly not feasible in O(1). - The time to feed the buffer in GPU-land is bounded by bandwidth (PCI express bus) and in the case of transferring from Javascript, there is tons of overhead related to browser security concerns and the communication between Javascript and the deeper C/C++ layer, hence the time taken. Other than that, I think it's pretty good explanation.

Finally, a video on the internet, that talks about C++ and Rust, and doesn't slander C++, cheers brother.

Very interesting. I'm working with WebAssembly right now. One of the downsides of webassembly is that if the input size is large, the cost to compute will be too high for it to be worth it. It's best to have a smaller amount of parameters that result in a lot of computing to be worth it. Using wasm for encrypting data is really effective, as an example. So if WebGPU is powerful for computing large amounts of data, we can use javascript, webgpu and wasm for the following best cases: - Javascript: small amount of computing, or simple computing where the JIT compiler will speed it up for us; - Wasm: Expensive computing that we can't run in parallel (rust wasm supports async, but doesn't support multiple threads), lots of computing for a small amount of data; - WebGPU: Large amounts of data that can be computed in parallel;

I've tested performance between js and wasm and there's an important note. Similar to sending data back and forth between CPU and the GPU, there's a high cost to sending data back and forth between the wasm worker and the main thread that needs to be accounted for. Calling wasm just to perform one operation and then read back it's usualy not worth it, or even worse than doing that in plain js. The system should idealy be designed to make the best use of the resources it has available.

Excellent video! Loved the pacing and the amount of info you provided in this one. Enough to make people excited and start exploring the concepts on their own. Appreciate the effort! Thank you.🙏

Ok, was first triggered by the “so darn slow” (the javascript multi stage JIT compiler is a piece of marvel)… and then I saw the sub-title on 1:09. Well played. Great video!

Although I couldn't grasp quite a bit of this vedio since I am a novice dev . The quality of the vedio is superb . Hope to see you grow .

I think the motorcycle/bus analogy is better at explaining the difference between GPU's and CPU's. A CPU is like a motorcycle, it can quickly take you and only you to your destination. If multiple people need to use the motorcycle, they'll have to wait for their turn, or you need to get more motorcycles (cores). A GPU is like a bus, it can take a large group of people from the same point A to the same point B at a bit of a slower speed. This works great if everyone is coming and going to/from the same places, since it'll be much faster than taking one person at a time with the motorcycle.

You should try Zig, especially in a WASM context! If you're coming from C++ you'll find it a lot easier than Rust. It's also very easy to set up a fixed-size pre-allocated buffer for the fastest possible communication between WASM and JS, and won't have borrow checker gymnastics standing in your way.

I'm blown away. Not by WebGPU (although that's pretty incredible too), but by how amazing this video is. The pace at which you give information was on point, animations were pretty cool and I can't believe you took the time to implement these algorithms in wasm and webgpu! Keep it up man, loved this video and I'm excited to see your future ♥

Awesome video! Could you explain how you measured the time for GPU compute without including the buffer copy / how you were able to measure the time of the buffer copy and subtract it?

Man this is an amazing content. Thank you

He's gonna summon @ThePrimeagen saying things like "Blazingly Fast" 😂

Wow this was a great video, really informative, good job! The visuals were on point as well. I would be interested in a beginner's guide to webgpu as well, I find the syntax a bit confusing, if you're looking for video ideas ;)

i think you including rust in this video is amazing, i feel much better because i tried it too and couldnt do anything, i was feeling dumb

The interesting comparison would be, how much slowdown the webgpu abstraction introduces compared to a C++ cuda implementation. Rather than comparing CPU vs GPU Code.

love your work brother

Nice video! Just curious which mic you are using?

It's not yet compatible with mobile browsers, but here's hoping the day is coming soon

1:53 That subtle flex tho

Isn't the simple addition example still O(n) since you are still technically limited by the amount of operations you can do in parallel. Sure its much faster but the O-Notation is unaffected since its O(n / C) where C is a constant depending on the GPU.

I wonder if the Rust and C++ versions of your code that were compiled to WASM were using SIMD where possible. Sometimes the compiler can detect and optimize for this, but it often only works for simple loops.

Even if this doesn’t make 5k, please make more!

For the Rust code, are you building a release version of the app? The debug build is usually 20 times slower.

thanks for this video. btw, can you explain the difference between webgpu and webassembly?

Compiling C++ with emscripten becomes painful when the external dependencies become complex.

well done bruv!

Well done 🎉 Subbed!

if the data is in gpu land is it persistent or we can use malloc like functions to delete the unnecessary data after the task has been completed

Thanks for the tutorial. Is it possible to share the three.js code that generates the animation of the particle system as shown @16:30 of the video?

i wanna make 2 transparent triangles intersect each other, is it possible in webgpu??

Ive been waiting for WebGPU for a while now! Seeing the physics sims coming out of BabylonJS. Going to beat the hell out of passing a 1xN sized texture buffer to some differed pass in WebGL to mimic a compute shader! Is Rust worth learning? Cause I went JS/TS -> C++ WASM, haven't really felt limited at all, besides transfer latency.

Really good anumations and basicaialy video editing. Althought... its just using gpu... you can do it already in I think vulkan

(C++) + webGPU = pure power and performance 🙃

Great video. Quality studf

Thank you!

People who are saying javascript is slow in browser are wrong not event cuz they think javascript is slow, but cuz they think programming language is a bottleneck. No. It's the rendering engine of browser. Style computations, layouts, DOM updates! If you'll try to draw a page inside a by hand it'll be faster than dom even without extra sorcery.

Incredible done video

on point subbed!

Did you compile rust with production flag and at the highest level of optimization?

What is your hardware spec for 160fps ?

Super interesting

I'd be curious to know why your rust code ended up slower than JS, I'm not an expert rust developer but I'm reasonably confident in the language and compared to almost identical C++ code I wrote it was always only slightly slower. Nothing significant to the point of being slower than JS. My big hiccup with it was trying to write Rust like C++ at first as in school I learnt Haskell and was told it was a "functional programming language" so when hearing Rust was the same I despised the style at first. Rust tends to optimise better when you write as functionally as possible. I definitely agree with you that writing some mathematical algorithms in Rust can be rough though, as its borrow checker rules tend to get in the way more than they help. I'm sure if I knew more unsafe rust beyond just NonNull I could get around this but in the realm of writing something mathematical I think C and C++ will keep their top spot (someone feel free to comment about Zig). It does seem like an odd comparison to make though as Rust and C++ are both LLVM based so will tend to be within the same order of magnitude with the differences being caused primarily by Rust's safety checks preventing some compiler optimisations combined with C++'s frankly better optimisation. I feel C# might've been a better bench alongside these with the focus of the video on running code on the GPU just since C# is both a well known language (everyone knows of Rust, few people write it, nobody writes it for a living) and C# is commonly used in game dev (Unity, to a lesser extend Godot). It also I believe has web app relevance in the form of Blazor although I've never touched it myself.

1:56 man just straight up roasted my pc out of nowhere

C++ library/API have memory problem during webassembly runtime (out of bound etc), if you want to use library other than C standard like ffmpeg, use C version

Nice video! And thank you for all your efforts, but you are not comparing apples to apples. A better comparison in my opinion would be JS & webGPU vs C++ & Vulkan

Hope this thing is adopted into game engines like Phaser or Cocos Creator

werent the shaders that babylonjs and three js use based on gpu computation

Greatttte man❤

I wish we just got access to the GPU memory and compile programs into it and use the hardware directly. Not sure how achievable that is though. There might be compatibility issues, mainly across different hardware vendors

how did you make the like button do the rainbow effect? that was cool. Also it sucks that safari on ios doesn't have webgpu

I was almost crying at the end of the video man

How does all this work on an APU today? Will the speeds be different? Both CPUs and GPUs have evolved a lot since conception, but GPUs have become monsters that occupy a lot of space and use lots of power. Im pretty sure in the future we will go back to using only one processor that integrates the best parts of CPUs and GPUs and will run some chimera language that delegates processes accordingly and more efficiently. But right now is a "pick your own tools" situation.

MAXIMUM COMPUTE POWER! WEBGPU!

It is impossible to do all the additions in parallel for any big enough number of additions. You are limited by the number of compute units in the GPU. Also it is very hardware dependent. You are better to use a 64 core Threadripper with a parallel algorithm (if you have it) than a GTX 1030 for the perlin noise :) Also you have an error in the O notation for 12:37 - if n is the size than that is O(n^2) since there are two loops to size one inside another. P.S. You are right about Rust. It can be as fast as good C in the best case, but if you have the best C code Rust cannot match it.

Try using web worker pool while writing wasm next time.

Really fantastic thing

Very good and informative video! I would love to see another one even if this doesn't get 5k likes 😳👉👈 (which I'm sure it will)!

Can they utilize multigpu? seem like only 1 gpu were used on my system.

next: what is "atomic"

good goood goooooood! thanks!

you definitely inspired me to learn Rust)

Basically I don't need this yet as a robotics engineering student, but I'm looking at it I guess 😄

I like the presentation and want to commend the effort and polish put into this video, but like other commenters, I feel the need to point out that there are a some problems. Primarily, the Big-O notation is being misused pretty heavily, but also please never ever present misleading benchmarks without thoroughly investigating any similarities/differences they show (like saying that you're not sure your Rust code is good, or that you're really confident in your C++ code, and then just putting those results head-to-head). That said, keep up creating content!

"Every sum is happening at the same time" bro that's some quantum shit right there

Did you do cargo build with a release flag???? For rust

Considering people use Python for math calculations, and pyhton is slower than Javascript, I would argue that speed is not important for that :D

webGPU may remplace HTML5 in a near future? with some aproch like flutter that renders all on a canvas?

This isn't JS at blazing speed, it's WASM so the title is a bit misleading. But yeah, all compute intensive stuff can finally switch to a more performant environment.

you missed opportunity to use "mythbusters nvidia gpu versus cpu"

Blazingly fast

1) Running the same algorithm on different Hardware doesn't change it's Big O runtime. 2) copying data to gpu or webassembly worker takes O(n) so with this approach shouldn't accerate any function that needs O(n) anyway.

For the GPU image, showing an external graphics card is kind of becoming passé. I type this on an iPad. Has GPU. Benefits from WebGPU. But no physical card. Alternate image: highlight GPU cores of any modern APU chip.

Am I tripping? isnt runtime for 12:37 O(n^2)

I don’t think there’s anything flawed to the method of: getting the current time (t1) -> doing some computation -> getting the current time (t2) -> subtract t1 to t2, to get measure performance. The flaw here is that you introduced a new computer into the mix out of nowhere lol

JS devs will get you to use a powerplant to add 2 u8 integers, but will not for their lives optimize.

Try with zig

Let Rust for Application Code or the cool kids out there. Core Components, Library Code, or any heavy-lifting etc.. - that's C++ Land, and it's gonna take a while till something beats that. All hail C++❤

hi, great video, could you upload the code somewbere?

JS IS DEFINITELY NOT SLOW. JS is the fastest dynamic language there is, not only to run, but specially for implementing any type of algorithms, because it's an extremely expressive language, and it's the internet overlord. There's almost 30 years of optimizations making it run even faster then C++ in some scenarios. Google's V8 engine actually replaced almost 30% of its C++ code to JS to enjoy it's optimizations. You even reached the same conclusion in the video, running the same algorithm in JS faster than Rust. Even before all of the JS optimizations we have today, there was already 3D games running in JS, even before WebGL, that is the predecessor of WebGPU.

How to speed up Java script: - Step 1: Use rust - Step 2: Use C++

Actually JS is fast enough for many types of games that don't require crazy performance. I think the slowness mentioned here is exaggerated.

I've never heard someone say WGSL like that lmao

I learn WebGPU, i wanna make cartoon object

--release

So we could have JS-miners installed along with ads? Finally! Nothing goog will ever come out of any ecma. JS-programmers are being referred as modern lumpenproletariat for a reason.

I'm confused as to the target audience, this we well made and informative but it had so much filler I found myself flicking through it. I can't understand why someone who codes and knows what webgpu is enough to click on this would like being talked down to so much.

JS is not slow. Idk why people stick in 1999? JS is like half the speed of the similar c++ code, if the code is well optimized for JS engines (using typescript solve most of the problems).

This was interesting until you saw JS being faster than rust and didn't even question it and instead used it to imply that Rust is worse than C++ lol

This is great, I just don't get the WebGPU name. It's still a WebGL, a graphics library. I suppose this is a totally new project and you guys had other ideas or for whatever reason could not work with the WebGL folks, at least please name it something else, that makes sense. I don't know, WebGL-Next? Anything but this. WebGPU is kinda stupid for the awesome work you put in there. Thanks!!!

showing numbers without code isn't that helpful tbh

I thought we were making js faster but i see rust all over the place

When you were a kid? 2017? What are you 15? LOL

Theme is interesting but format is not, having everything you say displayed on slides is not very fun to follow (one can get the transcript for this), way too long vid than it should

Oh noes... The world needs less JS, not more!

GPU? more like a baffling amount of JS at 2.0GHz

19:08 Lying doesn't inspire people. Not for long anyway. The compute shaders of WebGPU might be great for simulations, machine learning and other math-heavy 3D operations, but 99.9% of the code is sequential for a reason, and introducing yet another language only makes code maintenance worse.

jeez some things just shouldn't be done. stop using javascript, my lord.