Neat!

But can WASD run doom?

That is a cool fact. Thanks for sharing!

If you redo the bindings from outside the process but that isn't for doves or the faint of heart if you've never done something like that. Though i suspect some guide might exist somewhere.

Thats actually a incorrect meme, wasd plus mouselook was common, intended and pretty normal going back to the launch shareware demo start menu. There are many videos on the topic even. Maybe even an entire channel.

+1. Also, the thing that *does* become more expensive is mutating a pointer from an old object to a newly object. If an old object is updated to point to a new one, that reference should aim to statistically last as long as the old object, because the GC has to do a bunch of extra bookmarking for this case. If you have a data structure where that's only going to be true 50% of the time a purely functional approach might end up doing better than an in-place updating approach. I noticed that when making pairing heaps in languages with generational GC where the functional version outperformed the in-place version.

Depends where you're doing it. If you're doing it in an app that evolves often and where it's important to make it easy to maintain and understand, premature optimizations like that are the root of a lot of evils.

Yeah, there's really no downside to just kinda spelling things out for the GC.

Yes, so GC will clear out any objects that don't have a reference to them, or a reference connected to the root. Which makes sense. In gaming, this rule is respected by creating object pools for bullets or items you plan on creating multiple times

i cannot find this article anywhere, do you have a searchable term?

I am smelling ThePrimeagen

Ooh neat, will read about them.

That is a quite pointless feature, the point of JS is being high-level, the developer do not need to to worry about lower level details. If you are worring about memory in JS and fighting against the Garbage Collector, you should be using C++ or Rust. I guess that could be useful to optimize legacy codebases, where rewriting everything would be too expensive.

@@rj7250a It's not as in depth or low level but looks like like it might offer a way to do some basic cleanup which might help with Node and React if used right. See how it turns out...

@@rj7250aConsidering how JS is essentially the default language for a lot of developers, and how JS has such a bad reputation for gobbling up memory, I think the language needs all the help it can get.

@@rj7250a manual Memory management especially of longer life objects is a scalpel, and should be used thoughtfully. in C++ the expectation is that every programmer "should know" how to use that scalpel, but in reality most of the time the average C++ just writes the destructor, and then only calls delete in the destructor of the holding object, or when an object goes out of scope, which is mostly effective, but can quickly lead to bloat. Java is supposed to be "an easier language" where one of its initial sale points was "you don't need to worry about deleting your objects manually we have garbage collection" when in reality this was targeting those C++ devs that didn't try to dynamically manage memory. Over time many Java devs have leaned to just shrug at memory deallocation as a "Garbage collection will take care of it" which has led to the impression that Jave is inefficient, and for "lazy" developers, and many of the developers that do want to still work in Java, might be frustrated with "you can give it hints, when will it have an impact? Yes, No, Sometimes, Maybe"

That's a great idea!

Executioner

The Judge? Named after Dredd :p

@@jonispatented 100% right 😁

@@simondev758 Not morbid enough I'm afraid haha. Great video Simon!

the undertaker? or is that taken

In games, I've had to write many different allocators for different sitautions. You can get really fast allocations under the right conditions by using something like a pool or linear allocator vs the general purpose Doug Lea style allocator.

@@simondev758 Right, also even using a pool may not perform better in a GCed language if the pool is fragmented in memory, because letting the objects die young can be cheaper than the bookkeeping involved with having old objects point to new ones. Typically for pools to make sense the objects need to be value types allocated together, which is something that javascript mostly can't do unless you reorganize your code from arrays of objects to objects with array fields and basically vectorize everything (which is also what the JIT compiler likes).

For games, the trick is to ensure you can't save any state between frames within scripts. You can set up a system where all the script's memory is deleted every frame. Then you get the benefits of a bump pointer without the downside of garbage collection.

That's a good point, although I wonder if TypedArrays gets us most of that? That's what I was alluding to with the "going crazy with TypedArrays" comment near the end.

@@simondev758 ah nice, thanks. Didn't know about those. One learns new things every day.

I don't know that you would need to freeze the objects, or recursively freeze the given data structures. Treating them as read-only by convention of function would be sufficient. One immediate caveat: the built-in `map` `filter` `fnd` `reduce` etc are *slow*. They have to check for sparseness of arrays, weed out non-numeric keys, dynamically bind to `this`, create a shallow copy of `this` in case a function mutates values of indices on `this` during iteration, et cetera. Handwritten versions of the same thing (that expect non-sparse, numerically-indexed arrays with no mutation, etc) can be much faster. It would also be neat to see the time / memory costs of composed partial applications of functions. I can tell you first-hand that it's more than sufficient for high-performance interactive experiences. Making things like interactive SVG graphs, in React, with heavy client-side data analysis from raw data, and separate linear algebra for correct positioning, and all of the line segment highlighting, collision detection for hover states, modal popups to render data points, etc, without significant impact on laptops in the past ~8 years. On the main thread, no less. Not good enough to support running Quake 3 in FP, I’m sure, but surprisingly good if the libraries used are tight in performance, and you keep all logic segregated from anything that remotely smells like DOM access. And this was written... 5 years ago... geez, I’m old.

You need to be *very* careful doing this. Not only is it quite easy to leak the shared objects and have a "randomly changing" entity, but if you end up putting different contents in the same object you can crater your performance. Keep in mind very short lived objects are very cheap, they're not the case you need to optimize.

@@SimonBuchanNz Oh, believe me, I know. Like I said: internal functions only. And I profiled it -- though I don't know if it would still have as much of an impact today.

Thank you for sharing your experience, is there any kind of example we can examine and learn from it by any chance ?

I thought it was pretty straight forward and I'm hardly a guru, just hobby code. What was interesting was @7:02 where it was said that 26 ms of time for the GC, a skipped frame, was "unacceptable" to game developers! Wow, they have demanding criteria for unacceptable. 26/1000 = 2.6% of a second, hardly a blink of an eye. Are players that competitive that 26 ms lag will make them rage quit a game? I guess so. I recall reading C# was used to build an expensive trading system at some stock exchange, I think it was London Stock Exchange, and they scrapped it when they found it was a few milliseconds slower than C++, which HFT did not like.

Yeah, I've been a gamedev since the early 2000's, specifically specializing in optimization. I've spent time shaving fractions of a millisecond off a function, reordering data or statements to make them cache/branch predictor friendly, etc. 26ms is huge heh, at least it is in that world

​​​@@raylopez99 if you expect to simulate your game objects 30 times a second (or more) then you only have 33ms for each update tick for a stable tickrate. You need to update all game objects that need updating, check for collisons, handle those if they happened, and in online games also sent out the state changes to all clients as well as run any netcode shenanigans to save on bandwidth and make the game feel smooth and as fair as possible for the clients even tho each player has different latency and thus differ in game state on their end. And especially if you have a lot of servers running then it makes sense to want to reduce their cost as it will directly have an impact on profits.

@@SETHthegodofchaos Wow that's a lot of things to do in a short amount of time...I always suspected games compensate for slow connections (the same thing happens in online chess blitz matches which I play, with time added for a slow connection) but your post was the first time I've read about it.

​@@simondev758 is this the reason games take decades even with huge bugets? Why can't game dev be done inefficiently then optimizing after measuring, once the whole game is complete?

me too

Rust doesn't have GC, as you know, but it does have lifetime annotations, which I don't like since I don't really understand them at the practical level aside from parallel processing, but I do see they are built into a lot of library functions.

@@raylopez99 The lifetime annotations in Rust are logical pointers to the compiler, they don't go into the runtime environment like a GC. Rust is not fundamentally different from C in how it allocates and frees memory, the only difference is that you don't have to explicitly worry about it (most of the time). Added to things like ref-counting that eliminate the cases where lifetimes cannot be used, it manages to cover the needs of software development.

@@raylopez99 The lifetime annotations allow a sort-of compile time garbage collection. In Rust, every variable and memory allocation has a definite beginning and end, aka a lifetime. For 99% of what you write in Rust, the lifetime is trivial to infer from context. For example, I declare a float inside an if statement, and never reference it again outside that if statement. In this case, the lifetime begins at the start of the if statement's scope, and ends when the scope ends. For pointers and references, lifetimes sometimes need to be explicit because it's not trivial. For example, you may create a structure and pass it around from function to function, in and out of all sorts of scopes. Making a lifetime explicit is done through a lifetime annotation, which just names the scope of a variable for the compiler.

Why not implement it the way Perl and Python both do, and that is to use reference-counting as a first resort, and only fall back to garbage collection in situations where that fails (i.e. reference loops). That would seem to give you the best combination of performance and flexibility.

You can override new and delete in C++, globally or on a per class basis, and/or make your own malloc/free wrappers/stand ins. It's handy to make a template class that overrides new/delete for a parameter class, thst has one pre allocated array as a static member for use as a pool or bucket/slot list. Instances of the class are the same size, so this array doesn't fragment. Just use an unused slot for the allocation. You inherit from the template with itself as a parameter MyClass: public Pool{...} Globally there's a lot you can do, but one really efficient one is to basically have one array again and just allocate iteratively along/from it. Whenever you go into a new global game state (say leave one level and go to another) you can just reset back to the start, or a predetermined push/pop pointer into to allocate sequentially from again. You still should run destructors to free video memory assets and such, but having a global allocator that can just allocate sequentially for (relatively) permanent stuff for the time being, and never go back except when everything is reset, can be great for a lot of cases. Doing these things, plus reserve for stl vectors, is some of the best performance optimizations I've ever gotten out of C++, save avoiding dynamic memory in general, which these strategies sort of do. The normal memory allocation algorithm is super slow (from a game pov), not to mention usually thread safe which also implies locking overhead. It's best if that never happens but once at startup. So often you allocate ALL system memory at startup and allocate it yourself in one of the mentioned or a few other ways. Especially on console. Or at least it was ao when I did such work in the 2000s.

Had no idea, sometimes I just out and just implement things instead of checking around, especially short little functions like that heh

lol

i7-4790k from 2014.

No idea, that would be kinda interesting, although the generated code would need some sort of leg up on js to generate better code than what the jit compiler is already doing.

Really interesting, haven't heard of that but I'm going to go read up.

It's used extensively in Apple's stuff (Objective-C & Swift).

there's a lot of problems with ARC too - firstly, unpredictable run time, if it's reclaiming a large structure it may not finish in time. Secondly, you're losing the cache-friendly advantages of a compactifying multi-gen GC. Also, cycles are a bit of an issue too. So, it's not really useful for real-time, and have a worse amortised performance as multi-gen GCs in throughput-oriented loads.

@@greggoog7559 apple, schmepple, it's much older than that, it's in Python, it's in Mathematica, and many other older languages.

It's worth noting that reference counting is only fast as long as your reference counter is single-threaded (i.e. objects are not shared across threads). Otherwise you need atomic instructions which stall the CPU on every release. This adds up if you have lots of objects. Periodic garbage collection could - at least in theory - be faster in that case.

I'm trying to finish up the last section this week actually.

Access to SIMD really makes the difference in c++

As iterators did you use objects with for loops or something else can you please share little bit information?

What? There are many situations in which you can't just shove data on the stack. The heap exists for a good reason.

@@mariocamspam72 placing everything inlined does not necessitate its on the stack - you can just as well place them in a heap-allocated array or a vector - just its not pointers and the (p)OOP style design of references, virtual functions and all that, but literally the objects are near each other. And this is not even data oriented design yet, just regular easy-peasy locality. Only after this one can really wonder about "okay now what part of that data is accessed the same time" so this is very baseline code quality - not even an optimization, but a default to not pessimize performance... Also with RAII and move/copy you can just avoid naked pointers and references in most cases even without any "smart pointer" kind of thing... Very gentle and easy style with good perf comes out of it.

@@u9vata You sound like the perfect candidate...for Rust.

@@raylopez99 Really not a rust fan, because of the borrow checker, not much benefits and still slow compile speed. Rust really does not give much at all for safety when cpp is done well and is worse for productivity. I am happy though that Linux kernel has no C++ and would maybe do rust for huge teams, but where I know the team I prefer C++ for greenfield projects - only bad in legacy sometimes. But I am waiting for Jai which I have good feelings about and also think about creating my own language because I have a resource management idea that is much more simpler than the borrow checker and "nearly as safe". The good things about rust is basically its enums and match statement, but otherwise not really interested after I tried it for a while. For me the biggest issue is that it was pretty slow to write the same solution when it comes to programmer productivity and also very slightly was slower. I usually use C++ for hiperf though like data structures, or I even have my own sort algs that outperform libs and such so for my use case rust is not giving much - yet I am sure where safety counts more then both productivity and speed its better so there is place for it. Interestingly I see more interest in rust from web devs direction and somewhat from the systems development like OS dev, but not really seeing interest for rust in 3D / cad / games / hiperf where the productivity plus speed outweights safety benefits a lot. And again not really that big benefit when doing modern cpp... For this area I bet Jai / Zig / or maybe even my own imagined lang fare better because more focus on productivity is key and more focus on lets say compilation speed - which is real issue also in rust not just cpp...

The takeaway is whatever you want it to be. If you have ingrained and immoveable opinions, then you'll take away something that supports them. Or if some data or finding in there surprised you, maybe it changed your opinion on things. I fiddled around and tested things, and showed the result, that's all.

@@simondev758 Just in case you felt attacked by me, that was not my goal, sorry for that.Some years back, I had GC issues in Minecraft as well, but I was limited to fiddling around with the GC settings, the result was some extreme settings for G1GC which made the lag spikes almost go away. So, I know what fiddling and testing around looks like and I appreciate the work you did.

I've generally been responsible for optimization on a few games. When performance is important, you're managing the memory yourself, not via raii, smart pointers, etc. Those are great, although they have their own footguns and drawbacks.

@@simondev758 Thanks for the reply. (No need the read the rest...) Sure if you really need the get the max performance, reusing memory, and controlling when allocation and free is done is required. Though OS mem allocators are usually pretty good at cheap free and reallocate on the same size nowadays... They are not perfect. PMR was added to help with that. But at this point, if you are considering thus things, I can say that that you are working at a "expert" level, so new/delete (and their overload, in-place, and array variant) are tools you should use. However, for most dev, the rule of thumb is use RAII, so that there is no mem leak, as something more important then perf. Optimize if you have to, where it makes sense. Most of the time, it's not the memory alloc that makes something slow or fast, but the architecture and algos. (if are surprising costly, especially if mispredicted, and doing something in O(nlogn) when you could do it in O(logn) will have more impact then allocs. (and don't forget that O notation is not that good, as it's only true for infinite N, so consider the size of the N when selecting the right algo) ... (and that is why doing things in other language then "low-level language" can result in the same or better perf...)

Absolutely

He's not a rust_developer_maybe?

@@raylopez99 where did rust come from 🤕