How Slow is JavaScript Really? JavaScript vs C++ (Data Structures & Optimization)

Is JavaScript really that slow? Or is that just a leftover impression from the old days?
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 vs C++, and the performance difference between them. We'll talk quickly about the history of JavaScript before working through a few small benchmarks to compare performance between them, using various optimization levels for gcc. It's kind of interesting to see how much JavaScript's performance has evolved with JIT (just in time) compilation since the early Netscape days. The v8 team has made enormous strides in performance and is narrowing the gap with C++ year by year. We'll also walk through some examples of what you can do with your basic C++ code to squeeze more performance out, either by using better compiler flags or SSE/AVX intrinsics to get better usage out of your CPU.
What's covered:
* Super brief history of JavaScript and V8
* Benchmarks and comparison of JavaScript vs C++
* SSE and AVX intrinsics
* gcc -Ofast and float associativity
* Some closing thoughts on JavaScript's performance today, as well as C++.
Speed, Speed, Speed: JavaScript vs C++ vs WebAssembly:
• Speed, Speed, Speed: J...
Godbolt:
godbolt.org/
Wikipedia:
en.wikipedia.org/wiki/JavaScript
en.wikipedia.org/wiki/Associa...
Various blog posts from V8 team:
blog.chromium.org/2010/12/new...
v8.dev/blog/10-years
v8.dev/blog/launching-ignitio...
v8.dev/blog/adaptor-frame
v8.dev/blog/high-performance-...
v8.dev/blog/fast-super
v8.dev/blog/preparser
v8.dev/blog/spread-elements
v8.dev/blog/background-compil...
v8.dev/blog/fast-properties
v8.dev/blog/fast-for-in

[@PaweMateuszBytner]

i am maths and informatics teacher on private University in Poland, and it's rather distinctive that many students I teach are already programmer technicians / professionals with some market experience. I heard many times about superiority of C++ from people worried about performance when the lecture was about C#, JS or Python. Then those same people were completely missing the point on the lecture on algorithms and data structures. I notoriously see invalid solutions to rather simple problems - sometimes just tweaked to pass provided examples- and code that is completely unaware of data structures other than arrays, or maybe aware of linked lists, but using them like arrays. Dude, your C++ code will be slower than my JS code for not-small-enough data if you don't know what data structure or algorithm when to use

[@simondev758]

Absolutely, just focus on getting the basic approach decent. I've spent years working with C++ devs, like you have, and despite all of their "worries", most of them produced pretty bad code

[@gugiserman]

Most people complaining about your language of choice probably can't write half the logic you do

[@kevinjohansson3923]

Yeah, and then they write something in C++ which is buggy at best because they can't handle it at all. I'd rather master a higher level language before jumping to low level stuff if I were them but nope.

[@brawlgammer4424]

@@kevinjohansson3923 But here's the catch: being really good at a low level language teaches alot more about programming fundamentals than a high level one. What you described are bad programming practices and that is an issue on its own, a programmer with bad practices in low level languages will probably port them on to another language in a similar fashion. I started programming in C and even though i'm no master i now have a very good grasp on programming fundamentals and most of what i've learned is transversal.

[@dufferzzzzz]

@@brawlgammer4424 Agreed. I started learning to code with JS, learned basic C to understand types better, alongside memory allocation. Then I moved on to learning TypeScript, C++ and GoLang.. Investing time in C and C++ significantly improved my understanding.

[@thewarriors3048]

@@dufferzzzzz As someone who is about to start learning programming, I am thinking on which language to start with. I know I can pivot down the road, and ultimately, low level languages are what intrigue me, however I don't think they're smart for genuine progression as a beginner. It seems like JavaScript is truly the best bet even though web development isn't too interesting to me as of now. Edit: And of course there's Python and it's vast amount of libraries. I just don't know of any decent beginner projects that can be done with low level languages. It's always really awesome, advanced projects. Open source is great, but really how much can you truly contribute as a beginner?

[@dufferzzzzz]

@@thewarriors3048 I always have a hard time deciding on projects too. I chose to start with javascript because it is fairly easy, but as 'easy' as it is, it will cause you just as many headaches because of how it works with types. I understand your view on Web dev not being interesting. When I first started, I learned html, js, css, node and ejs templating.. Didn't enjoy it overly much. Creating multiple basic CRUD applications soon got boring. I decided to learn React and investigate CQRS and microservices architecture in the cloud.. Honestly 1000x more interesting in my opinion... Terraform, kubernetes, RabbitMQ, Kafka, gRPC, Jenkins build pipelines.. Even github actions.. There really are a lot of brilliant technologies involved when you start looking more full-stack than just front end. Also if you are using microservices then you can have them essentially in any language you want. Golang is my personal go to, and you can take full advantage of the languages choose to write them in. JS is slow (sue me, haters) , and sometimes a pre compiled c++/go binary will run 4x faster so it just makes a lot more sense to use. First language is always the hardest, keep persisting and you will recognise patterns.. Good luck to you!

[@Ferdam]

I've heard you can beat most languages if you write your stuff directly in binary 🙃

[@Rssks]

Haha! Why not just wire yourself to the cpu and tap your bits in manually 🤣 ?

[@simondev758]

Even faster if you just build it right into the hardware. Only n00bs don't build the silicon themselves.

[@tythedev9582]

@@simondev758 I have a nice game idea, I just need to go mine those precious metals first

[@andrewdunbar828]

Nah, I used to program in binary machine code when I was a kid because I didn't have an assembler. Code is the same speed written that way as code written in assembly, but takes longer to write. BUT you CAN beat most languages if you write your stuff directly in Verilog or VHDL for an FGPA (-:

[@blablabla7796]

@@andrewdunbar828 that’s pretty cringe not making your own specialized hardware for each function. Kidding aside, using FPGAs are a little cheaty because of just how good they could be. I’m glad that we’re almost past having to use specialized FPGAs because GPU processing is becoming more and more accessible.

[@filipe_paixao]

episode 7: calling chemistry and electrical engineers to remodel all individual parts of all hardware pieces to be 100% oriented to the program we want

[@L1Q]

ah yes, good ol ASICs

[@yourlocalengineer]

have you heard of FPGAs

[@williewokkel]

Fpga’s are sick

[@dempa3]

I think it'd be interesting to learn from you how to write efficient code in general (I understand you have worked with optimizing other people's code for games), and maybe a "learn efficient JavaScript together" series of videos.

[@misterl8129]

please please please, as a semi sinior js dev it would be a great step for my carreer. Like a reproduction list of videos :D

[@Tiptup300]

Learn more of how data moves around on computers. Data Structures + Algorithms = programs

[@redstone_mason]

Why would you use C? Assembly is much faster

[@Gol_D_Roger_The_Pirate_King]

Binary is much faster

[@neinnine4592]

Actually binary would be faster!!

[@nathanadhitya]

Unable to imagine somebody writing "light" for optical processors for "truly fast"

[@gaafts]

To my knowledge, C code is compiled to assembly code, which is compiled to binary. In other words, it's compiled to binary anyway. There are some situations where assembly code can be faster than C code because you have outsmarted the C compiler with a faster way to do something. I can't imagine a single case where writing in binary will be faster than assembly.

[@coopercone4293]

@@gaafts You're right, but everyone above was joking around. Assembly is translated to machine code with an assembler, which uses a 1 to 1 mapping of instructions (for a given processor). Assembly is just a human readable version of machine code.

[@CottidaeSEA]

How you write the code is often more important than what language you write the code in. Understand what operations are efficient and which are not. Choose accordingly when performance matters.

[@BryceDixonDev]

An efficient implementation will always be faster than a poor/naïve implementation, regardless of the language used for either case. If you implement an N^3 algorithm in C++, it'll trend slower than a log(N) implementation in even the slowest interpreted language. Shocks me that self-proclaimed "experts" miss that.

[@CottidaeSEA]

@@BryceDixonDev Yeah, it's also why performance benchmarks are a sham. At best a marketing strategy. Python has awful performance for example, but it can be extremely performant if it is used to call compiled C functions. There'll be some overhead, but it won't be crazy slow as if everything was written in native Python. So knowing the strengths and weaknesses of the language is just as much skill as writing the code itself.

[@LewiLewi52]

Bet u can squeeze out even more performance with Holy C.

[@blocksrey]

Lmao

[@juliankandlhofer7553]

who needs performance when you can have 3d graphics in your code?

[@crynesssruns7364]

Behold Assembly

[@LordFers]

Terry would be proud of you boy.

[@Xman_9]

you can squeeze out even more performance with byte code than holly C. even better you can build your own computer to squeeze more performance!

[@cynical5062]

Great video! One thing I feel like you forgot to mention at the end is that, while yes, the V8 team is going to keep finding optimizations, so will the people working on GNU's GCC G++ compiler. It's essentially a race to see who can find clever optimizations faster.

[@simondev758]

Definitely. I highly doubt V8 will ever catch up, but they'll probably get a little closer each year.

[@andrewsides7250]

Just checked out your instagram. Thought you were a 60-something year old man until now. Love your channel!

[@simondev758]

I'm 60 at heart.

[@dgcp354]

@@simondev758 isn't comparing language what newbie do, cuz I don't think js and c++ are meant to be used for the same goal, I'm disappointed at this video, I don't think people use c++ to build a website or use js to build a game (no idea), am I wrong

[@telnobynoyator_6183]

@@dgcp354 he used js in his videos, probably because it's easy for beginners to understand and ppl started shitting on him bc of that. So he made a video saying js isn't that bad.

[@dgcp354]

@@telnobynoyator_6183 oh I get that, he keeps saying js ain't bad in the video, that's why I said to myself why even compare them at all, every language has a purpose to shine on. every language is not intended to do everything. and trying to convince js haters is like pouring water on a stone.

[@Veso266]

How old are you then?

[@jimpa7011]

Im so glad I found this channel, Simon you make great videos.

[@tuomaskoivistoinen6476]

I think really nailed it with the "you get to understand your code" and that it "sucks to have a compilers job". The less constraints a language has, the more performance you can squeeze out. But the more constraints it has, the more transparent it gets. High level languages should never beat system level languages on performance, but it's nice to see the difference isn't too bad.

[@simondev758]

When I grow up, I really don't want to be a compiler. Yeah it's pretty cool to see how much work V8 has put into this, some real wizards over there.

[@Spongman]

this is true in practice, but not necessarily so. you could have a "do what i mean" high-level language that generates the provably-optimal solution for whatever high-level request you give it and it would always be as fast or faster than hand-written code. there's no requirement that high-level languages be slower, that's just where we are right now.

[@kosnk]

I think we now recognise that high-level language compilers are starting to outsmart an average low-level coding (especially for functional languages, where math can give compilers more hints).

[@ThePC007]

Ironically, using JS actually makes me have a compiler's job. Not when it comes to optimisation, but when it comes to find errors that should be found during compile time, but aren't (dynamic typing can be a real bitch, especially during refactoring). That said, scripting languages like JS, Lua, and the likes are great for learning how to code. I wouldn't chose JS over C++ even in situations where performance doesn't matter at all, but I'm happy that I didn't have to choose C++ as my first language to learn.

[@kosnk]

@@ThePC007 , did you have a chance to try TypeScript? Strict types with syntax otherwise identical to JS. For the past few years I start my web projects only with TypeScript. Also, there's an interesting project, called AssemblyScript -- its a low-level language, compiled to WebAssembly, while being similar to TypeScript in syntax.

[@490o]

Thank you for actually putting the results next to each other. So many KZbinrs who do benchmarks expect you to scrub around to compare results.

[@awweather]

I haven't really seen anyone do what you do in JS. Keep it up! As someone who's also working on a 2d mmorpg in javascript, I have already learned a ton of stuff from your videos

[@malcolmholmes115]

Your voice is so calm and watching your videos is just like a meditation

[@wahidurrahman8993]

yeah

[@NathanHedglin]

Great video as always Simon! Thanks

[@avi12]

How about a benchmark of JavaScript vs C++ vs C++ via WebAssembly?

[@noahsmith2555]

I’ve seen you on the coding train discord lol. The internet is a small place.

[@mateuszabramek7015]

But WebAssembly is not javascript - it's compiled from languages like C++ , Rust Or even Typescript etc. So comparing C++ with C++ seems stupid. What JS does is just loads WebAssembly in browser, but that's it.

[@noahsmith2555]

@@mateuszabramek7015 WebAssembly is compiled to bytecode that runs on a stack-based virtual machine that is built into the browser, it is not native machine code. It is not comparing the languages’ speeds, it is just comparing the speed of the WebAssembly interpreter/VM interpreting WebAssembly bytecode, to the CPU directly executing native platform specific machine code.

[@Justin73791]

@@mateuszabramek7015 What about we use asm then, as that's technically JavaScript (though processed by the the same engine as wasm) :D

[@kosnk]

The reality is that if an app runs slow -- it's likely that the code is the issue, not the language. Roughly speaking, in O(n) -- n's coefficient has much less impact than its power. Yes, JS won't outperform c++, but it has more than enough fuel for a modern app (while surely gamedev being always greedy). As they say, a released app is worth much more than a well-optimised asm file. Good luck and happy coding!

[@simondev758]

Well said.

[@rabradek]

Unless you're using an interpreted language like Python, where you can expect 200x slower performance on each op when compared to a compiled language.

[@Dev-Siri]

​@@rabradek Python can go fast too You just have to call C apis

[@wmcmurray]

I was wondering exactly that the other day, I'm glad you did this comparison !

[@emmanuelfelix5935]

In the begining of the video I tought that you was forgeting important things of c++, but your final performance was impresive. great video!

[@j.c.h.9891]

What this tells me is "Know your tools!" so hard. Thank you.

[@A1rPun]

You are very bright that you derive that meaning from this video. Javascript has a specific purpose for the browser. The video didn't even mention nodejs which is basically the javascript engine pulled out of the browser.

[@Retrosen]

Your voice is so relaxing to hear dude! amazing content

[@vinfern27]

Excellent works as usual. Thank you.

[@aufkeinsten7883]

Love this channel big time for the insightful & thoughtful content, but I'd genuinely listen to any amount of audio books you'd record

[@Rssks]

Nice hands on testing! Results were as ~ expected but concept and context is what matters. By having fun in JS you open up dependency-free, ready to launch learning experience to wider range of novice fellows. Anything can be ported & fine-tuned for the final product :)

[@Rssks]

Don't get me and my sloppy English wording wrong, I do praise your work!

[@Artintrex]

C++ is my favorite language but, I still find your content interesting. Performance you manage to squeeze out of Javascript clearly shows your experience and many lessons here can be applied to games in any language.

[@shapelessed]

I'm a web dev, and while I do agree that JS has way too many flaws, I do respect how they decided not to add things like macros... Although you can still overwrite a global prototype of arrays for example and V8 will then not be able to use faster prototype lookups and you cold possibly f up the entire program.

[@tuckerbeauchamp8192]

Awesome video my friend!

[@michaelmulholland4380]

Love the channel just subbed hoping for more great content! Thank u

[@ManasTunga]

Nice comparison !!! Js being a single threaded web language that does most of job async quite impressive compared to strongly typed compiled language like C++

[@AndrewDevUA]

awesome content!! Thanks!

[@elliotcroteau5067]

great stuff dude !

[@tomm.4447]

Awesome content! You really helped me with my pet project, thank you!

[@MuriloMielke]

Did anyone already told Simon sounds like a Dark Souls NPC? I just got into the channel and couldn't help to think of it.

[@nathanpointer7844]

Praise the sun 🌞

[@simondev758]

So many not-fond memories of that game.

[@solaris867]

@@simondev758 Please fix your voice. You speak like something in your throat

[@elidrissii]

@@solaris867 Please fix your manners.

[@illford6921]

@@solaris867 yes change your voice, that you were born with. The voice if fine, sounds like a wise man if he had a long white beard I'd listen to everything he says. At that I don't get complaining about someone's voice pretty much just an insult

[@Atmos41]

That comment in the beginning, comparing Java to Javascript... The guy who wrote that clearly has not programmed with any of those languages if he thinks they are similar xD

[@IndellableHatesHandles]

JS looks no more like Java than any other language based on C syntax. Heck, even Python has more similar class syntax to Java.

[@lucaslengyel8635]

Really cool video!

[@SusumoKakinotane]

This is excellent, honestly, you make great content. And even at the end, you point out the possible issues or considerations to even try to squid some more performance. Out of this world, glad I found your channel.

[@sps014]

Great insights. C++ Wasm vs JS will be a fair comparison as both will run in Browser. Need one video on that. Thanks.

[@user-lj4lo7cx7m]

Please

[@pinch-of-salt]

Absolute legend!

[@skilz8098]

Another metric that could have been looked at is when working with multidimensional arrays with nested for loops and how you index them while trying to maintain cache coherency (preventing more cache misses) as well as minimizing the use of the branch predictor. Data alignment and page swapping could be another thing to consider especially when reading / writing data to files... Memory layout and memory access is vital when it comes to finding bottlenecks within the source code to maintain a higher level of performance. Just as important as that is when you start to work with multithreading... When these techniques are involved and being used then compare the difference in performance between each language. Nice video BTW.

[@CollinBaillie]

I wonder how much the processor technology improvements are part of the JavaScript performance increase? It would be interesting to see a comparison of old JavaScript vs old C/C++ on an old CPU. Obviously the range of tasks would be more restricted.

[@soykike1991]

Hey awesome video just subscribed this is the kind of stuff I like to see, also there might be a way to optimize the javascript code, webworkers you can spawn to do some solid math operation, but might tend the start making your code more complex. For example for large arrays of vectors you can divide them into x quantity and spawn x workers I would love to see this compared to c++

[@simondev758]

Good idea, might be an interesting follow up video to compare threading.

[@krazybubbler]

Love each and every video you upload SimonDev. Gold content as always!

[@AntonioNoack]

Memory layout indeed can be a problem, which the compiler cannot fix. Some CPUs only have (4/8 element) aligned loads. For my R5 2600 nothing happened when I used it incorrectly though ^^.

[@plokki456]

Nice video! I would be very interested to see a comparison of the performance of webgl and opengl. I worked on a project using threejs a few months ago, and it felt like webgl was dead slow compared to what I'm used to in opengl. But maybe it's not that bad actually :)

[@simondev758]

I'm guessing there's a lot of overhead since you're so removed from the driver, going through JS then IPC's to the gpu process, etc. I'd think, but have no proof, that code running on the gpu should be similar.

[@DFPercush]

You can access a canvas's draw context directly from web assembly without going through the JS boundary, so it's not quite as bad as you're thinking. But you're still basically using the smart phone version of OpenGL ES. Not the fastest API out there but it's ok for some stuff.

[@IndigoCode]

Great video, thanks! I was a JavaScript naysayer until my first time getting my hands dirty with it, but nowadays I love the language. I've seen some other comments wondering about a WebAssembly comparison, I'd definitely be curious what your benchmarks look like in asm.js and WASM. Awhile back I did some comparison between JS and WASM for skeletal animation (via Emscripten, -O3) but my results (5x-10x) were pretty dubious because I wasn't really comparing apples to oranges - no typed arrays, tons of allocations in the JS version, etc.

[@simondev758]

Definitely would be interesting, pretty sure the v8 team did some testing in the video, was pretty close to native performance. And WebAssembly SIMD is a thing now too.

[@TurtleKwitty]

"You clearly havent shipped a game" optimization and language choice are far from the most important consideration when talking about completing projects, willingness to finish it is the most important and for some JS helps with that, its a fun language. You also mention that c++ has options, but you also have those options with js, you can go full wasm and even not use the dynamic types and go full typed if you needed to eek out more performance, theres always more to do if you really need it; JS will never be as fast as bare to the metal, but its so quick to write and work with its a viable tradeoff for many projects!

[@circuit10]

Isn't WebAssembly a completely separate thing? I guess it's a web technology that integrates with JS though

[@Spartan322]

JS to WASM, while likely a bit more performant, is still likely to lead to bottlenecks that JS would be in-optimal for complex and larger projects that need robustness, another issue a lot of these discussions tend to forget is that static typed systems (alongside a lot of proper compilation steps and static analyzers) exist to reduce and prevent bugs caused by dynamic typing systems and provide heavier and clearer optimizations, and since JS and its derived transpiled languages don't really address that (aside from maybe Dart, but even then I would be real hesitant to say that, Typescript does it the Python way, which bogs down the runtime immensely) you can easily achieve a point where JS will fail and harm your development where any statically typed language wouldn't have. Note as well that typed JS is relying on runtime typing which detracts from the runtime. Its not to so much JS is bad, but its more so unsuited to this purpose and its paradigms and nature make long term development and project management beyond an utter chore, increasing development time often for the sake of looking simpler. (or it could become more complex in trying to become reasonable and now you've defeated the whole point of using it) For this specific case it will be fine since its a demonstration, the problems crop up when relying on JS infrastructure and paradigms and start trying to use it for production projects.

[@TurtleKwitty]

@@circuit10 Think of it like writing a function in assembly and calling it from c++

[@TurtleKwitty]

​@@Spartan322 Unless youre trying to argue that assembly isnt suitable for large projects then wasm isnt any less suitable. Except that static typing potentially helping for bugs isnt something being forgotten by those of us saying that js is perfectly suitable for many projects, its purely being forgotten by those that refuse to accept that js can be. Is JS perfect for everything? God no. But is it perfectly suitable for many things? If its your language of choice then hell yeah. I wouldnt expect every game dev in the universe to magically drop pygame because a rnadom person decided that python wasnt the most performant language in the universe, well same goes for js. Wouldnt expect anyone to make the next AAA hyper realistic full physics sim open world MMO or whatever in JS, but same goes for many other languages and tools that are used for making games anyways *shrug*

[@simondev758]

Yeah that was my favourite quote. So much anger in it, gave me goosebumps. Loved it hah.

[@HolyDemonRune]

I love watching these things. When I first started learning programming it was like reading the matrix falling numbers screen. Now, I love going through videos, going "I completely understand everything this code is doing... wait wtf is that?" It's actually really fun and leads me to learn more about this subject! It's also impressive, it allows you to see the difference between experience and knowledge. I can read and understand whats going on, but there's no way in hell I could've have done ANY of this. there's a chance I could have, given a year. It's not like I don't have the knowledge to do this but I lack the experience and wisdom needed to accomplish such feats. It's inspiring and mortifying at the same time; exciting but still a long ways to go.

[@simondev758]

You have exactly the right attitude to become an extraordinary engineer.

[@IronFreee]

I love JS, it's fun to use. I made a few graphical web apps and small web games with it for fun, usually with a bunch of friends in a few days. I used a lot of Typescript professionally, mainly in Angular, but I often got frustrated by the framework limitations. I remember one time when the client was complaining about a pixel gap that could have been quickly solved in JS but was left because, with Angular, we couldn't do anything about it.

[@cat-.-]

When you’re bottlenecked by a bunch of data operations often you need to.... Cpp people: AVX!! Js people: Wasm!!!

[@arminrosic9550]

This is great stuff. I am often very pleasantly surprised by just how fast JavaScript is.

[@greenpumpkin172]

Right ? I would not expect JavaScript to be so fast !

[@IxMeTutorials]

V8 is a masterpiece

[@skwtf]

Thank you! Can you start a beginners series on optimisation and best practices on common programming optimisation techniques, across different languages (if that's even a thing)?

[@simondev758]

That's what this series is!

[@DFPercush]

1. Don't bother optimizing things that don't matter. 2. Use the right algorithm. But above all else: 3. Remember the sage advice of financiers: cache is king.

[@spacedoohicky]

Will web assembly allow JS massaging as well? Though there already is some JS massaging with bitwise operators.

[@alvarolloret948]

Keep the 3D JavaScript content! You are doing great and your videos are really unique ☺️

[@EngineerNick]

This was amazing well made video :) I'd love one comparing python to javascript! I recently moved from python to rust... and I am wondering if I even need to go back :P

[@EngineeringFun]

Simon, what presentation software are you using (the cool animated font and drawing)? I just need a name or a keyword. Thanks!

[@simondev758]

Which part? The black screens with titles? Those are google slides + me typing. The drawings are just any old paint program + editing out the menus

[@EngineeringFun]

@@simondev758 Amazing, thanks. Can you elaborate on the old paint program? Maybe I can find it. How about those 3D exemplifications of various programming concepts? Thanks!!!

[@stuntman3614]

Awesome video, what tool you used to get a side by side comparison of assembly and cpp code? Thx

[@simondev758]

Near the end? There's a site, godbolt.org, let's you dump in some c++ code and see the compiled output for various compilers.

[@nowpro4604]

Love your videos, great effort. Chapters would be nice if you were to skip the coding part or something

[@dealloc]

Can highly recommend reading "Is WebAssembly magic performance pixie dust?" by Surma (a Web Advocate at Google). The article goes over compiling different languages (C, Rust, AssemblyScript) to WASM vs. idiomatic implementations in JS and running them in V8. It goes over some of the optimizations that V8 applies to JS and WASM through their compiler chain (there's a lot going on) and how in some cases JS can be much faster (and require less bundle size) than its WASM counterpart (without WASM bindings or Emscripten).

[@simondev758]

Thanks, I'll check it out!

[@openroomxyz]

Love it!

[@markzuckerbread1865]

Came here from the ThePrimeTime video, glad I discovered this channel!

[@cykboy3254]

i would like to see the same performance test ran in nodejs. id expect it to be faster than in a browser

[@ThePapanoob]

What makes you think that?

[@Rssks]

Nodejs runs v8, your browser runs v8. There should be no difference in performance of code execution. The only thing you might save in nodejs is the lack of the browser hugging up your cpu and memory (free unused resources) and that's about it :)

[@cykboy3254]

@@Rssks well, thats my point - the browser runs a v8 instance per tab and theres other factors to consider in that process that could use cycles/resources. plus nodejs has some specific architecture designs for async workloads which would be an interesting performance comparison for in modern c++

[@cykboy3254]

@@Rssks scoping also makes a big difference between browser and node, but writing good code that shouldnt be a bottleneck

[@cykboy3254]

@@ThePapanoob resource allocation. the c++ code was ran in its own process, the js code has to deal with the browser process + js execution. also, read other replies

[@juliankandlhofer7553]

This shows the exact reason you should always do benchmarks. Many times the performance differences are not as big as you think! Great Video 👍 Also, the people hating on JS are probably the same people who then wonder why their Python code is slow 😁. V8 really is a miracle.

[@NathanHedglin]

Agreed. JS is mostly “bad” because of bad developers not because it’s inherently bad. V8 uses some crazy dark magic.

[@Spartan322]

Javascript's biggest issue, (when it comes to this type of stuff) least for the last decade, has been the typing problems and its scalability issues for large projects, its a nightmare to lack qualified types in multi-person projects and runtime type checking doesn't do well at dealing with this, the lack of a dedicated compilation step and fully qualified static analyzers also really hampers the development and increases bugs, both of which start to outweigh the ease of which JS development brings. Its also never really fair to compare simple tasks in two languages, those simple tasks could be optimized down for any number of reasons because of the specifics of the language or the manner in which you solve a problem in one language is so drastically different from another that to compare them becomes utter nonsense. In C/C++ you have pointers and memory management, (and for quite a while now, compile-time capable execution in C++) something you never can get in Javascript, and that so utterly redefines the way you do things that it really doesn't work to compare Javascript to C++. All this isn't to say JS is bad, but its a tool not exactly suited to this type of development outside of demonstration, as long as everyone understands that if you're doing this stuff yourself, you shouldn't be making production code in JS for this case, its otherwise irrelevant to address in my opinion.

[@astrotecn]

i think the hate comes from the fact that the js community is fucking retarded with tons of frameworks the language itself isnt bad, the ecosystem though is fucking cancer

[@halofreak644]

I'm getting into javascript but your knowledge as inspired me to go harder

[@chadyways8750]

Honestly for learning and projects where you really aren't hyper concerned with performance, javascript does a decent job, however, as your tests even show, it shouldn't be used beyond that if you actually intend to do a lot of complex things Basically you can eventually force a square through a circular hole but it isn't ideal

[@kosnk]

But wait! There's more: SIMD is coming to webassembly in chrome 91 (not JS, but might boost the ecosystem). Again, great video, Simon! Thanks

[@simondev758]

Oh seriously? Didn't see that, very cool.

[@kosnk]

@@simondev758 , afau, webassembly is still at its early stage, and will definitely improve in performance, abilities and dev experience. Also, there's an interesting project called AssemblyScript that compiles to wasm and looks similar to TypeScript -- quite fascinating.

[@softwarelivre2389]

@@kosnk AssemblyScript is pretty neat!

[@V972]

Huh. This surprised me. I'm also guilty of firmly sticking w/ "JS slow" because of prior experiences and general [outdated] opinion. However, these tests (as well as a small history course) shows that I'm wrong. And honestly, I'm glad to be wrong, I'm glad that JS is catching up even if it probably won't be able to fully do so (it's still good enough). Thank you for the video! You've been cropping up in my recommeded for while now and I haven't regretted a single video of yours that I watched. I think I'm gonna subscribe!

[@syntaxerorr]

interesting video. Thanks.

[@odomobo]

A note on the inline keyword in c++ : it should only be used when you put a function definition in a header file. It's not a hint to the compiler. Think of it like "static", which says the function can only be called from the cpp file it's defined in. Modern c++ compilers support link-time optimization (called whole-program optimization in msvc). LTO allows optimizations (like inlining) to be performed across translation units (i.e. cpp files). Without LTO, placing a function definition in a header is the only way for the compiler to inline a function defined outside the current cpp file. This can be a useful way to allow your compiler to inline functions, if for whatever reason you can't use LTO.

[@simondev758]

"It's not a hint to the compiler.": This conflicts a bit with my understanding of inline a bit. From Microsoft's docs on inline, they do basically say it's a suggestion (has to pass the compiler's cost/benefit analysis) unless overridden with something like __forceinline. And I recall, but can't find, a post from an engineer from the compiler team saying that inline was at best a suggestion to the compiler. GCC and Clang may be different. If you have some good docs on the subject, I'd love to check them out. The rest of what you said is roughly in line with my understanding.

[@odomobo]

@@simondev758 In cppreference's page on the inline specifier, it has a note: 'Because the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred", that meaning was extended to variables.' I find it interesting that it doesn't explicitly say it, but only mentions it as an aside. Every optimization level in GCC ignores the inline keyword with respect to inlining. By default (O0), it won't inline anything (including functions marked inline), and -finline-functions-called-once, -finline-functions, etc apply equally to all functions using its own heuristics. You can see this in the GCC Optimize Options page. Similarly, if you look at the /Ob optimization flags in msvc, you see that /Od, /O1, and /O2 all ignore the inline keyword also. Unlike GCC, it does have /Ob1, so you can coax the compiler to listen to the inline keyword. However, I'm not sure this is useful. Maybe it's a philosophical question if a hint is still a hint if it's universally ignored, haha. I find it a bit frustrating that most references tie the inline keyword to function inlining, due to the fact that it's no longer used for that in most modern compilers. It makes sense that it's not a useful indicator for inlining when you consider that every templated function (or method of a templated class) is implicitly marked inline.

[@lubengeorgiev5675]

Aren't all methods defined in a class inline by default? So no need to specify it at all there.

[@Cyberfoxxy]

I think in C++ you can do performance optimizations that is simply impossible to do in JS. But then again, you rarely need that kind of performance. "Well what if you wanna update a million actors". Firstly, you don't, secondly: Batching, caching and only rendering nearby node (which you'd do anyway). Most the demands reside in physics and rendering. Just as a funny thought, i wonder if you can somehow perform calculations with CSS?

[@simondev758]

I actually have no idea what you can/can't do in css.

[@okie9025]

you can use the calc() function in CSS, but I doubt it's any better than just doing it in JS

[@tmvkrpxl0135]

Could you enable auto generated subtitle? I am student learning English and I need it to understand it properly

[@quangho8120]

I wanna add something from my own testing. First test, I have 2 for loops over i and j. Inside I calculate s += i * j. On JS, this yields 0.15 GOPs (giga operations per second), while on C++, it can do at truly ridiculous speeds of 19 GOPs, or 100x JS (using -march=native -O3). Granted, I have AVX2 which helps a lot. Second test, which is sort of similar to the test at 1:54. Still double for loop, but instead of adding to a variable s, I save the result in an array. JS version is 0.13 GOPs, while C++ is also 0.13 GOPs. Quite interesting. An explanation for this is that both versions are memory-limited. My RAM's CAS latency is like 9ns, which explains perfectly why. Point is, I think OP sort of favors the benchmarks that puts JS in a better light, which is perfectly fine. I love JS, and I think people need to stop saying that it's slow, but I want to put more love to C++ as well

[@simondev758]

Nah, just picked 3 that I thought were kinda roughly, very roughly, things you might do. A simple loop just because it's easy for compilers to attack. A more complex one that intentionally had SIMD'able data to lead into using some intrinsics to show that c++ had more cool options that JS doesn't, and last one was more of a pointer-y situation updating zillions of entities. Bad choices? Maybe, but no secret agenda there :)

[@jeremycoleman827]

Theres some wasm simd hand written vs js array super simple benchmark on 1d array that has the wasm like 1400x faster lol

[@d-one-and-only]

really cool..... what are your thoughts about web assembly?

[@Ibzann]

this guys voice is really soothing

[@kevinjohansson3923]

Yeah, it's very very nice to listen to. Especially in today's overly expressive, borderline manic state most KZbinrs present themselves in.

[@wooooooongs]

that’s simple

[@finnvictorsson]

Your voice is relaxing

[@chair547]

One thing people Miss is that when it comes to optimization your code doesn't need to be as optimize as possible it needs to be optimized enough. What that means depends entirely on your circumstances. Sometimes JavaScript is too slow and you do need to go to C or even assembly. But sometimes is not all times and usually JavaScript is good enough

[@brianevans4]

not really related, but I tried a speed test on Google Cloud Functions between Python, Go and NodeJs, and I was expecting Go to way outperform the others, but actually it was the slowest. I was mostly just testing the libraries in those languages by performing a simple database read and returning the result, since most API's are something along those lines. Python and Node were about half the response time of Go

[@TheBigWazowski]

Why would a database read be indicative of a languages performance? It sounds like you’re doing network I/O

[@indycinema]

Those comments were so unnecessarily aggro and miss the point that JS is what Web Devs already know and content on game patterns in C++ is already plentiful. It's helpful to see JS used using C++ idioms, instead of the framework nonsense that pervades webdev.

[@simondev758]

Pretty sure most of them were jokes, except for the middle one. But that one was great in its own way, so much anger heh. Loved it.

[@kallehalvarsson5808]

Not to mention the most obvious point - if you want to have a game that can run in the browser, then it's not like C++ is even an option. Either way, i always assumed that he used JS because of how forgiving and easy to read it is, which lends itself well to tutorials.

[@DudeBronkster]

@@kallehalvarsson5808 With web assembly, running C++ (or any other language that supports it as a compile target) in the browser is definitely an option. Many of the popular off the shelf game engines nowadays export to browsers, and they mostly compile to web assembly, not JavaScript.

[@kallehalvarsson5808]

@@DudeBronkster That is true, though last i worked with WASM, the support in some browsers (mainly Safari and Edge) was dodgy at best, maybe that has improved by now. But yes, you are perfectly right.

[@MrNispen]

Im wondering if it would make a difference if you would run the code with nodejs instead of in the browser

[@Soremwar]

There are differences, but they are not that noticeable V8 is present in Chrome, Node and Deno. All of them optimize the operations between them and V8 to reduce the time in between, and that is how things in Deno for example are faster than in Node when using built-in APIs, but the same speed when running for loops I don't think any of the examples here would be faster in Node really, except perhaps the WebGL integration, I'd expect the browser to be faster there since that API is provided directly by them where as in Node, it's a third party library

[@simondev758]

I've done absolutely no research, but I'd guess that Steven is right in that it probably doesn't make a world of difference.

[@tossajalumen401]

i think this would be really interesting to see is there any difference between nodeJS and browser. What i tested by my self, i was getting totally different results, but i'm not a master of this kind of testing :D

[@MrNispen]

The reason I thought it could be different is that Nodejs is a application itself, while javascript in the browser runs sandboxed within another application. Also in the browser you run the javascript in 1 tab, and the browser is designed to (possibly) run alot of tabs at once, so maybe the resources per tab could be limited.

[@BW022]

In most modern applications, performance is typically IO bound. All programs inherently do three things -- read in data, process data, and output data. Modern machines are typically so far that the only parts you typically see an improvement is the middle section. If it takes five seconds to reach a SQL query and two seconds for something to render a graph on a screen, you typically have a (relative) lifetime in most cases to process the data before a user is going to notice something. Even JavaScript running on a browser typically spends 90% of it's time in an input loop. Whether it takes 30ms or 300ms to process the data probably won't be recognized. It takes some pretty specific applications these days before processing performance is really key. In most cases, you are better off optimizing the I/O, then your data structure/algorithm, etc. before having to look at a compiled language. Even then, such systems are typically on a knife's edge and you need to be considering hardware and other solutions. If an app needs to run five or ten times faster to be usable, you now have issues about older machines, other tasks running, etc. anyway.

[@budabudimir1]

`inline` is not a hint to actually inline anything. It is there to solve the problem of single definition rule, essentially allowing you to implement your functions in header files and telling linker to pick any impl, as they are all the same. Member functions are all inline by default.

[@ToothlessXDIn]

JavaScript speed is awesome even though it's interpreted(and/or JIT). It can't beat c++, because c++ code converted native to its hardware. But, That doesn't make c++ universally accepted for everything. JavaScript has its uses, c++/c has their own. Part of JavaScript slowness because of its running along side in browser thread(browser has to do a lot in own aside from interpreting JavaScript. Ex DOM manipulation, user interaction, data transfer, session, security etc).

[@simondev758]

JS is actually converted native to the hardware too, that's what the JIT does :) But the resulting code isn't quite as performant as what you get out of the box from c++. You're right though, they're different tools for different situations. But when I wanna just whip something together or test out some ideas, JS is there for me. It's like using premixed ingredients vs making dinner from scratch.

[@softwarelivre2389]

@@simondev758 yeah, running in the browser can cause some overhead. Running in Deno might yield better results. Not by much, of course, but probably slightly better. Might be worth testing.

[@rafaelmorales1926]

Oh god I noticed your voice is somewhat similar to Creed Batton and now I can't unhear it

[@simondev758]

Man, someone said it sounded like H Jon Benjamin, now I'm binge watching Archer. I might have to watch the office next.

[@exopolity]

What you think about Rust (webassembly) with JS. Maybe some tests? Do you have any experience? It is good idea to connect this two technology in work? For example In React App ...

[@simondev758]

I really want to try Rust out, but no haven't had the chance yet.

[@ponchietto]

I can submit a real life example of a complex code written in C++ and ported to Javascript. It's a 3d mesh compression algorithm 'Corto' (on github), similar to Draco (from Google). Developed with focus on speed (without vectorization), and I can confirm a ~x2 factor in speed. The most important things (as in your video) was using BufferArrays.

[@simondev758]

That's awesome, happy to know other results are roughly in line.

[@colourfultoreador8467]

Javascript is fast for a high-level coding language

[@illford6921]

@Вероника Заглотова but do you want to learn lisp, as a student I looked for languages, saw lisp and then avoided it. It seems a bit too time consuming and hard to learn. I'd rather learn Assembly because at least that's funny

[@tomm.4447]

@Вероника Заглотова ((((((((((())))())))))))))

[@jeremycoleman827]

Lol +1

[@HugRunner]

I think it would be interesting if you could start transitioning into WebAssembly through e.g. Blazor and see if you could recreate some of your projects with greater tooling and performance.

[@DFPercush]

wasm is awesome and I love what you can do with it, but it has the potential to be very bloated. The main downside of Blazor is having to download the 3 or 4 MB mono runtime libraries in the initial fetch. Rust is kinda bad about that too, clocking in around 800kB. Emscripten is somewhat reasonable at about 200k. Raw Clang/LLVM can target wasm and give you tiny binaries, if you know how to manually interface it with JS, but that convenient abstraction layer will cost you bandwidth. Might not be a big deal, but it's something to consider. I've got a project now using svelte/sapper for the DOM manipulation and wasm/emscripten for some heavy calculations. Crossing the JS/wasm boundary is expensive, like for example if you're calling the browser's crypto RNG millions of times from wasm, you might be better off just staying in JS. For reference, the same algorithm in native code vs wasm (OpenSSL prime number generation) is about 3 times faster on bare metal than in the browser from my experience, but I've heard they're adding SIMD support to wasm eventually, maybe that will help.

[@HugRunner]

​@@DFPercush Yes, it's true that Blazor requires quite a bit of overhead/startup-code currently but once it's running it has potential to run at much higher speed than JS in some applications. I just think it would be a cool path to walk down in this series to actually explore the advantages and disadvantages. One huge advantage, as I see it, is the tooling for .NET and Blazor. While the latter still is very much in development and is about to get a huge improvement later this year with .NET 6, strong-typed languages have huge advantages over languages like JS in terms of tooling, debugging, maintaining etc. So I think it would be interesting to see if some of these project possibly could be created easier or just with an other approach than the JS way explored in most of these videos. Not just comparing the final product. The way towards the goal is important as well.

[@DFPercush]

@@HugRunner All good points. Being able to debug your code and set breakpoints from an IDE like Visual Studio is really nice. That's kind of a minor disadvantage of all these JS frameworks, they don't really have that "Press F5 to run/debug" tight integration with the dev environment. VSCode and Sublime are cool and all, but you have to do your debugging in the browser, as far as I can tell anyway. And that means finding the duplicate version of your source, that you can't change, and setting breakpoints there. Debugging is so much nicer in native apps. You can sort of do it with node, it's just missing edit and continue.

[@dealloc]

@@DFPercush You can debug from within your favorite editor that supports connecting to the DevTools debugger. When running your code, you can attach to the DevTools debugger session from the browser to the editor. In VSCode even has this built-in as a default with Node.js, but you can use Debugger for Chrome to attach the debugger to a Chrome instance and use all the features that is also in DevTools.

[@DFPercush]

@@dealloc It doesn't work so well when you have a compiled or minified file with a source map. Like svelte for example, has to do a build step even in the dev environment. I haven't tried with React, but I imagine .tsx files would be the same way. Any breakpoint you try to set is unbound.

[@mayuukhupadhyay6845]

Hello... Could you please tell me the user of backtick in javascript.. I've seen few places where inside backtick: c programming codes are written..

[@gilmoretj]

Hi, I think it might be interesting to compare the performance of C++ against WebAssembly.

[@overloader7900]

there is also -fwhole-program ,which, if all your code is in a single compilation unit(.cpp, through #include "*.cpp), may apply more aggressive optimisations about code that is never reached Also, -march= and -mtune= exist, profile based optimisations... Well, basically most of optimising c++ is playing with compiler flags, right?

[@simondev758]

I didn't try with whole program or PGO no, although I'm curious, since this was all a single cpp would whole program optimization do anything differently? I set -march but didn't set -mtune, wonder how much difference that would make. Actually, I'll try it now. Didnt change anything.

[@overloader7900]

Afaik, whole program optimisation is about visibility - it can better inline functions and cut unused code because of assuming that non-main, or not explicitly visible functions/variables wont be ever called/used on their own (which it sometimes doesn't with -flto, tried myself, the 67kb executable got to 65kb, so it definetly cut something)

[@mechap7612]

Member functions defined in the class declaration are implicitely inlined

[@simondev758]

Oops nice catch!

[@manin4568]

Genius 👌👌

[@Taurdil]

How much more memory JS versions were allocating you said? It has to be a part of the comparison, right?

[@simondev758]

I need to investigate memory usage in a follow-up.

[@jhyland87]

I use to always hate coding in JS, because I liked doing the backend stuff and JS was mainly just the UI/UX stuff. But then NodeJS came out and now I love coding in it. I actually just got a job offer as a Sr. Full Stack Developer for NodeJS/MongoDB/AngularJS/etc at a bank. Pretty excited :-)

[@A1rPun]

Good luck on that offer my fellow coder!

[@jhyland87]

@@A1rPun thanks bud! Pending on the bg check - which makes me nervous... I have a colorful background and banks are strict. But I was an InfoSec engineer at PayPal and passed that bg check, so this should be ok.... Hopefully.

[@ArquimedesOfficial]

One time i was on mac donalds and a bunch of kiddos comes and asked for "One Big Mac full with javascript and pickles" LOL.

[@APsupportsTerrorism]

Did you tell them the big mac isn't picklable? I'll get me coat ...

[@akj7]

1. Cache locality can kill you code performance. In JavaScript there is not need to care about that, because the interpreter has an arena of memory from where it gives data to variables that need them. In C++ this is a big deal. You can't have a huge vector somewhere, take the reference of another vector somewhere else, and do some operations. This is a big factor when it comes to matrix multiplications and is one of the trics that Numpy uses. 2. std::cout is slow because it is synchronised with every C printf functions. Untie it. 3. With openMP, you can quickly multitask. The parallel lauch algorithms of C++17 are also quite nice. You need to do some gynastics to achieve actual parallelism in JavaScript.

[@dominikliberda4017]

@Peterolen More like it's impossible to make good use of caches in JavaScript.

[@odomobo]

Point 2 isn't exactly right; std::endl performs a flush, but if you use " " instead, you get basically the same performance as printf. Point 1 isn't exactly right; caches are filled 1 line (64 bytes) at a time, regardless of distance between two cache lines. If you're accessing all elements in an array, then you get locality benefits from multiple elements being in a single cache line and/or from cache prefetching. Doing an operation on 2 nearby arrays is as efficient as doing on operation on 2 distant arrays, all else being equal. Memory fragmentation is indeed an issue in c++, but not because of that.

[@imalol1]

Pretty interesting video! Would be interesting to compare I/O performance as well. :) As someone who works with Java extensively now I want to compare it to your results, might try it out on my free time. PS! Would be interesting to see the numbers for graalVM + javascript. I wonder if that would close the gap.

[@simondev758]

I'm not familiar with graalVM, from google it looks like it's a Java VM not JavaScript?

[@imalol1]

​@@simondev758 There is support for js :) github.com/oracle/graaljs Though, now that I'm thinking about it I'm not sure how insightful this comparison would be since you would be just comparing one runtime to another. :P

[@simondev758]

Ah neat, missed that!

[@jeremycoleman827]

One of the early v8 engineers did a lot of work on graalvm. Graal is cool u can use python js and r all in the same file using template literals and it just compiles.

[@goonholiday656]

Me as a JavaScript developer trying to understand what you said: “Yes”

[@andrewdunbar828]

JS was slow slow slow when it was a baby but since they started serious speedup efforts it's long been the fastest scripting language. But of course still slower than low-level compiled strongly-typed languages like C, C++, and Rust. And managed languages like Java and C# are somewhere in between.

[@feitingschatten1]

C# has a few tricks that optimize its speed in relation to the OS it's on. The CLR and Windows are tightly woven, meaning MS can give it a few tricks that actually make some things "faster", when in reality it's just a thing they shoved into the OS because both C# and the system are windows-brand. Just so you know when you compare a raw algorithm, it might not be a "fair" comparison vs something that would write to GUI or other sys call. Not arguing, just adding to what you said

[@Phiwipuss]

Awww, feel offended the language you are using is slower? This is so silly.

[@feitingschatten1]

​@@Phiwipuss I don't know who you're responding to or why you thought anyone was offended. But it's important to forget about feelings and go into the technical side. The language isn't just randomly "slow". It's doing things. JS runs an engine, which is why a web app drains battery like crazy for simple forms on phones. Android doesn't give UI thread priority. Apple is a raw OpenGL engine if you use Objective C or Swift, and if you use Objective C, your memory isn't copy-on-write so you won't spam the stack and use excessive CPU cycles, which, at scale, drive up costs for AWS and similar. I'm not attached to any language. SwiftUI and JS are trash. JS is the only lang where the tools are written to fix problems with JS, and all the rest of tools are fixing the problems with the previous patches that didn't quite finish. The language itself doesn't follow logic, and the rules are sporadic since the prototype and global variable system never got fleshed out and noobdy will rewrite it, they just keep adding Babel conversions instead of fix the core. By language, I mean syntax. Obviously, the language itself runs fast enough. Anyway, let's keep going. Lack of ability to optimize since JS is just a hash table means it's impractical for 3d games that require speed. You gotta know how to handle CPU usage and memory, or you can't optimize for speed. Pointer arithmetic gives you massive boosts in memory handling and is how you can get 100% speed in the algorithm websites as well as ensure things run as fast as possible on hardware. Anyway, I just wrote this long paragraph to illustrate just how ignorant you have to be to think this has to do with feelings and not what's under the hood of the compiler. I didn't want someone who didn't know seeing your comment and going "Oh, he's making some baseless claim based on his feeling." and dismissing whoever's statements above. People like you are why I never respect web dev.

[@Phiwipuss]

@@feitingschatten1 Oh I wasn't responding to you. I just saw no reason for showing C++ in a, particularly bad light, while trying to make JS look godly. Both languages are amazing, but for separate things. I don't even think you should compare them. Comparing Rust and C, okay, but C++ to a web language, I don't think so. You don't even have to choose between them, if you want to be a web developer, JS is the only choice (when you have to choose from C++ and JS), but for desktop apps, C++.

[@BlaBlupBlaa]

Did you try running the C++ code using modern C++ standard, e.g. containers (vectors, maps, lists, stack, etc), or shared_ptr instead of raw pointer? Using more modern methods (C++14 and upwards) may introduce overhead for the sake of readability that may or may not worsen the C++ result

[@simondev758]

Some modern stuff, was mostly straightforward.

[@Viralvlogvideos]

u desrver 1 million subs, can u please make a video on how to write optimize code for js. i saw that ur suggesting to use normal loop then map so i want to know more about it

[@simondev758]

I'd love to have 1M subs, but I'm super happy with what I've gotten already. Yeah I plan to dive a bit deeper into optimization in general.

[@Viralvlogvideos]

@@simondev758 js has so many features damn people go on updating it like people do with mobiles phones or gpus haha