Yes. tagged unions are called `enum` in Rust. You might enjoy this blog which dives deeper into memory layout and memory usage of Rust enums https ://alic.dev/blog/dense-enums

@@ChimiChanga1337 I found time to read it today, and it is amazing how saving memory to the last bit forces us to lose a good cache-hit ratio. I think in my next code, I will go with the simple SoA with two arrays saving the padding of the tag only. Thanks for this recommendation.

My previous company has that lmao. Mobile verification and email. It was fucking integer field 🥸

isn't this just swapping/paging? why would you want to do this because it will be insanely slow

@@tmkcelll no it absolutely would not be swapping paging, I am trying to avoid paging all together and just use a block device directly AS RAM! I'm trying to both bypass motherboard limits on supported ram, and make programs believe I have more physical RAM then I would even have room to hold the page file for when swapping! Asking if it was the same thing makes me wonder if you watched the video? Sorry for the sarcasm but I am tired of people repeating that same response when im explicitly saying that's not what I want to do, it's very frustrating.

@@petevenuti7355 if that's the case i think the only way to accomplish that is through modifying the operating system itself, not sure if l2 is even able to be changed (i doubt it since it's inbuilt into the cpu itself). the system that enables paging essentially treats it like extra memory in the address space, so not really sure what else you want to do other than that? you can just allocate a whole device as swap space and use it as memory in linux, so there's that, and you can probably limit useable memory to almost nothing to emulate what you want to achieve and yes i did watch the video in full

@@tmkcelll yeah I'm not sure how the mmu on the motherboard and the memory management of the operating system work together or are capable of overriding each other. I was hoping somebody would know. I remember really old systems where you could put RAM on a card on the bus. As for the actual l2 cash you are most likely right as it's in the CPU chip, however if the operating system has anything to do with it, such that's not just microcode on the CPU that handles it, it would be cool if any real ram that was available could be used in that role.

He's creator of Zig hahahaha

@@emmanuelbyiringiro7207 r/whoosh

@@emmanuelbyiringiro7207 That was the joke here. :D

If only he said that in the first 10 seconds.

You have not hear anything! Watching him hailing satan. There is something wrong about this guy! kzbin.info/www/bejne/faeVemqnidqrbcksi=N4DL99SuBcSGOXQ1&t=752

@@maskettaman1488 you mean dividing perfectly readable functions into 5 classes and 25 methods LOL

@@rusi6219 No. I mean not jumping through hoops and writing some arcane code so that you can have a bool and an int share a byte. There are very very very few cases where that kind of optimization is necessary considering the quality of the code suffers greatly as a result. But also, yes, you should be breaking up functions in to smaller units. If you have 1 function that does 20 things... you should probably look at breaking it up and organizing things a bit.

@@maskettaman1488 hahaha "quality of code" is about the last thing a customer is thinking about as he's staring at a frozen screen due to fifty destructors destructing other destructors

@@rusi6219 I can only assume you're new to development in general if you think "fifty" destructors would even be perceptible to an end user. Have you never seen a stack trace from a modern web server or something? Also, destructors have literally nothing to do with cryptic bit tricks to save a few bytes on your data structures like the video is discussing You really seem to not know what you're talking about

@@maskettaman1488 I can only assume you're new to development in general if you think "cryptic bit tricks to save a few bytes" has no effect on how well software runs at scale You really seem to not know what you're talking about

Patterson and Henessy - comp arch Dragon book - compiler

@@ChimiChanga1337thank you

Personally I don't really see this to be a useful gotcha in most cases, misleading at best and poor practice at worst. We have two ways of writing our function that performs an operation on variable X. First calculating the result, and later in the function doing the calculation again (as seems to be suggested in the talk). Secondly, we calculate the result of the operation, and 'buffer' this in Y, which we can later fetch to use in our function. In either case, when the function is ran at first the block of memory where X resides has a cache miss, and X is added to the cache. If we do not buffer, we later take the variable again out of the cache and perform our operations on it. However, if you would temporarily save a result of the operation into Y, Y would be located on the stack. The stack is almost always going to be cached, because stack variables will be accessed relatively often. Hence my conclusion that in nearly all situations they have similar access times as they are both going to be cached, the 'non-buffered' solution would just require additional math operations. At least, that is how I think it works. My own specialization is not deep in computer science and/or computer architecture, so if someone with more knowledge is able to chip in on this I would appreciate it.

@@tHaH4x0rthis is correct, but really what he should have said in the talk is that it’s better to calculate non trivial expression on the fly than recall a stored value that may have already been evicted from the cache, or just never store it in the first place. This is the same thinking as not initializing something that’s used once because you can just pass it as a literal or an expression. That way you’re not paying for the extra memory operations. His point was just to say think about where you’re paying for memory operations, especially allocations.

​​@@tHaH4x0ryes, there are caveats. Math is faster than memory if you already have the operands. If you're gonna have to look up x and y you might as well look up x + y.

The whole point of storing struct fields at their natural alignment is so the CPU doesn't have to do extra work. Back in the 90s, top-of-the-line RISC CPUs might even crash your program or trigger some OS interrupt to handle unaligned access. I believe x86 tends to be more forgiving about this, but I'm not sure. It is likely that your compiler will go to great lengths to avoid unaligned memory access, using multiple smaller reads or writes instead. As always, looking at assembly output and benchmarking your particular program will be necessary.

20:52 ohhhw, its about language feature where the lang allows to create array of each member ef struct.

Or in this case just check if life_points is lower than 0, but this is a very simple example. For the zig compiler I think that Andrew's strategy is good.

I would say Andrew misunderstood the meaning of DoD and what he showcased here is straight up optimization - a step most mortals do not have to take as their code is 1000x slower for other reasons entirely, i.e. using pointers from a linked list to refer to individually heal allocated items. There is also this funny thing where he optimized the most irrelevant part of the compiler, LLVM will gobble 98% of the compile time regardless (unless Zig can use it's own fast backends for debug builds). But I do want to say that the way you refer to "readability" sounds like you don't know what you're talking about and the "readable" code you would spew out would be anything but actually readable.

@@Nors2Ka For me, readability is about how easy it is to understand the code. There is an infinite way of implementing a feature in a program, and some of them are better than others according to some criteria, for example readability or performances. Regarding readability, I would judge it by the amount of time an effort an average developer will need to understand a peace of code. At 22:29, on the left, I instantly know and understand what is a Monster and what it is capable of from its struct definition. But on the right, If I look at the Monster struct, I don't know that it can held items. And if I find the held_items hashmap, I am not sure of the key of the hashmap. Is it the Monster index in the Monster list? Is the hashmap dedicated to the Monsters or is is shared with the NPCs or other possible item holders? Should I clean something in the hashmap when a Monster is deleted? For me, the left version seems a lot more easier to maintain and add features on (for example, looting).

I feel the same way. I know in my typical projects (large web and console apps), the code being easily read and maintained is much more valuable than saving KB of memory or a fraction of the time of a single web request. I guess these kinds of optimizations are for specific use cases, but none the less it’s interesting to hear about and have in the tool belt.

I think so. I've spent the last 20 years working on high-performance software where these techniques make the difference between being the best or lagging behind. For those who're developing web front ends or bloatware, or coding in java or Python, etc. not so much, if at all, in my opinion.

I was going to comment this as well. Splitting the data like this will always require two cache-reads on the initial load *. If the out-of-band technique is applied to more data, then each one will incur an additional cache-read. When looking at an individual access, it is like it comes with a guaranteed cache-miss for each time you apply the technique. Data for arrays are stored contiguously in memory. In this example, if you expect to access several elements in a row, then much of the data will already be in cache - because the size of each struct independently is less than one cache line in size. If you expect to go through all the data in any order (and it is small enough to fit in cache), then this results in less cache-misses total, because there are simply less cache-lines to access. These benefits can artificially inflate the performance savings of the technique when people benchmark it by iterating over an entire array of data, or test it in a limited context that doesn't factor in the accumulation of external data in cache from other processes, if the data / procedure is not used often. * For completeness, there are some special cases where you don't have two cache-reads: One cache read: I assume this is what you were referring to in your comment. If you happen to be storing less than 64 bytes of total monster data, 7 or fewer monsters in this example (assuming the 'animation' data is cache-aligned to start with and the 'kind' data is not). Then you can fit 3 extra monsters into the cache-line, where it could only store 4 monsters in a cache-line previously. Three or four cache-reads: In this example his data is a divisor of the cache-line length, if it wasn't then there may be a chance of having to perform another cache-read for each access.

This technique is very useful for instances where you do multiple operations on the Monster and you only need one (or a few) fields at a time. For example, in a game you will have an update function and a render function. If you iterate with the padded struct, you waste time going over the anim field in the update function and then waste time going over the kind field in the render function. You just have to be careful of your use case, as with any optimization methods.