This is why I think using fixed size integers is a mistake in almost any context that isn't data serialization and/or protocols. For performance conscious parts of the codebases of my recent projects I'm considering having a type selection system that will define word types that will be the optimal size for the CPU of the current platform, like word, dword, qword, etc. Choosing types for your variables is a whole can of worms.

The best comment so far.

​@@Acceleration3 but you have to consider that register access time (what you describe) isn't everything. You also can't treat an object like a lose collection of primitives. For example let's stick to the students example. If you make age, id, birthday,... All 64bit 1 student is a huge object. With tons of wasted space. If you then have an array of students that wastes enormous amounts of space. At some point leading to a cache miss. Then the cpu has to wait for the ram to load the rest of your mostly empty data. At this point your register access times are meaningless by multiple magnitudes. Side note: The optimal cpu spacings are often choosen by the compiler anyway. Meaning that a student with 1 32bit value and 2 8 bit value will at the end be 64bits long. The reason is that the compiler knows you need at least 8bits for a particular value but adding empty space besides it doesn't change the code. Tldr: By trying to be smart you waste space and keep information from the compiler making the result worse. A datatype size is more or less a suggestion for the compiler and it will make smarter decisions than you will. By giving him false information you will not achieve improvements.

@@redcrafterlppa303 I know I'm making matters more complex but if you're going to have lots of students, a better approach to improve on cache locality and reduce memory usage without taking a hit in the performance COULD BE* using Struct of Arrays. Have on array for ages, another one for IDs, another one for phoneNumber... The first student created will have ages[0], ids[0], phoneNumber[0]... COULD BE: IF, your code is going to opperate on only a few of the fields at a time. Operating in all ages of everyone, then later on all phoneNumbers... This is Data Oriented Design. Structuring your data to not keep jumping around in both data memory and code memory.

@@besknighter that's for sure possible and something databases are for. Operating on larger amounts of data is something databases should be used for. Structuring in memory data like this isn't all that helpful and leads to messy hard to read code.

Pretty sure it's a mistake in the script, not the AI's fault

@@keppycs the channel owner said they were not a native speaker in some other comment replies which is why they use the AI voice. It's definitely the script.

@@MrC0MPUT3R you were basically saying that from the very beginning. i misread, sorry

How can i get a similar AI voice

@@Tech.Library it's a speech synthesizer, probably something like UTAU (used for music production) or eSpeakNG (a utility more than anything) should give you similar results

That's a cool feature for using types to enforce value bounds. But it won't look like that in memory. It will 100% be padded to 32bit.

Yeah, I know. I was supposed to include a little animation of the zig logo saying "are you challenging me?" I just forgot. However, as someone else said, the don't look like that in memory, although with bitwise operations you can do anything with singular bits.

@@CoreDumpped f128 and the fact that Zig can do larger numbers than Rust is cool.

there is same thing for rust just as module. These u31 seems iffy. It would be nice if we could pack them nicely together with NULLs ect, like lets say sizeof(Option) == sizeof(u32)

@@Lord2225 i would think they are amazing for things like rust enums. If you have types in a struct that are oddly sized and guarantee padding you can fit the varient bits in there and create zero cost enums just because a type sacrificed some bits it didn't need anyway. This is exactly what I do in my language that is heavily inspired by rust but tries to fix the sharp corners of the language like lifetimes and dyn dispatch.

The best bit for me was his remark about automatic type coercion when doing things like "adding" a string and a number: "and this kind of bullsh*t is marketed as a feature". It reminds me of why (among so many other reasons) I hate php so very very much.

​@@danielscott4514 honest question, is automatic number to string conversion really that bad? I see people shitting on it all the time but IMHO it's mostly harmless (at least in a sane language). Many languages have misfeatures which are at least 1000x worse (dynamic typing, everything being a reference type, nullability by default, etc.). Of all these things why do people fixate on int + string so much?

​@@k2aj710 Certainly being able to do something like "number of results: " + resultCount (where resultCount is a numeric variable) is something that is pretty harmless most of the time. However, if your language lets you concatenate a number onto a string - and if it uses the + operator for string concatenation as well as numeric addition - then what happens when you try "3" + 2? Do you get "32", or 5? For what it's worth, I took the "and this is marketed as a feature" comment in the video's narration to be aimed directly at dynamic typing generally rather than at the specific example they gave. Dynamic typing is what causes the above kind of conundrum to be a thing. No strictly typed language will allow something as vague as "3" + 2. In c# I would have to do it as "3" + 2.ToString() if I wanted "32", and I would have to do it as Int32.Parse("3") + 2 if I wanted 5 as the result. The very nature of the language eliminates that whole class of bug, which easily comes about when (normal non-superhuman) programmers are not intimately familiar with every last detail of their dynamic language's type coercion behaviour. For what it's worth, on the subject of doing something like my first example: as a regular user of c#, I'm very conditioned to combining strings and numbers using various methods that accept a format specifier, which outputs the number with things like currency symbols, commas to separate thousands, various numbers of decimal places etc). I find that in many cases you want more control over how your number "looks" as part of a string than simply concatenating the number in whatever default representation the programming language uses. So, in my view, the value of being able to write code like "number of results: " + resultCount is questionable anyway. Although I spend quite a bit of time in C# currently, I've coded plenty of Javascript, and suffered far too much php (which can truly make Javascript seem sane). Dynamic typing combined with some bad language design can really ruin your day (especially since the bugs appear at runtime only). I'm far happier and more productive in c# where a huge number of errors are definitely caught at compile time and the lack of any ability to write "string" + 3 avoids various footguns that aren't worth risking for the sake of writing "string" + 3.ToString() (or various more modern c# alternatives, like string interpolation, but you get my point). Given this is a comment on a video about low-level performance, as a side-side note, I rarely ever actually use the + operator to concatenate strings in c# - the reasons why are generally well known (if you're not sure why + is bad for concatenating strings, google c# string concatenation best practice and you're bound to get a pretty good rundown of how concatenating strings works and which approaches are best in which cases: they're considerations in any language that gets into the weeds deep enough to give you at least some choice over how much memory gets allocated/used/eventually destroyed in the process of combining multiple strings.

@@k2aj710 Gawsh my earlier reply ended up being a tome (ignore things like the side-side note on string concatenation - I put that there for the benefit of someone else that might read it later ... kind of StackOverflow learned-behaviour I think). Anyway, I just realised I've got so many horrible memories of things that various dynamically typed languages have done to me over the years that I probably didn't really answer your question (since, I've just bothered to check and Javascript seems to give the string in a string + int operation some kind of precedence, and it actually does what I would consider the preferable thing with "3" + 2 - and gives "32"). That said, I've just looked and at 7:26 in the video there are variations on that "3" + 2 theme which do end up doing arithmetic addition instead. I think probably the string + int thing - if it gets mentioned a lot - is more of an easy to explain and demonstrate example of the greater problem of dynamic types in languages. It kind of builds from there into the kinds of problems you can have with code like: if (myVar) { ... } where there are all kinds of rules for what string and numeric and every other kind of value might mean "true".

That's what she said

Yeah but I think rust compiler is smart enough to pack all the operations into a single SIMD instruction

It amazes me how stupid these comments are. 8 bit ops are equally as fast as 32 or 64 ones. It's honestly mindless people who repeat nonsense without understanding. Sure the throughput is lower. Clueless people shouldn't make comments.

@@gregorymorse8423 It amazes me how stupid you are. 8 bit operations will definitely not be as fast as 32 or 64 ones. There are no instruction sets that support 8 bit operations, so these 8 bits have to be converted to 32, math done on that, and converted back to 8 bit. Those conversions takes up precious CPU cycles. On the other hand, smaller variables (like 16 or 32) vs larger ones (like 64) can win performance-wise if the constraint is memory, i.e. more tightly packed data won't have as many cache misses. It's honestly mindless people who repeat nonsense without understanding. Clueless people shouldn't make comments.

How would a 32 bit operation take less time than a 8 bit operation. Can you explain that to me?

@@cheesepie4ever because modern architectures don't support bit operations on 8 bit data. This means these 8 bits have to be extended to 32, arithmetic done on that, and then converted back to 8 bits. This means extra CPU cycles for every operation. On the other hand, 8 bit operations can be potentially faster if you're operating on huge sets of data at a time - in which case the extra operations wouldn't hurt as much as cache misses, since 8 bits will obviously be more tightly packed and you can fit more of them in cache. As with all things performance related, don't theorize; benchmark. See for yourself.

Yes, it's pretty commonly used one too.

There was one place (3:35) where it paused unusually long between two words and that's the only reason I noticed.

1:46 It became obvious to me when the TTS spoke a typo “what does that means”

@@davidt01 I made it till over 9 minutes in and got spoiled by the comments!

@@davidt01Actually, that pause was intentional. I'm just realizing people is not getting it lol

@@CoreDumppedOhhh now I get it 😂😂

Should be answered in the stack and heap video

Yeah, I'm already working on those videos :)

@@CoreDumpped Awesome, subscribed :)

@@CoreDumpped we are now waiting subscribed nice video!

I don't believe it was answered. I posted a comment on the next video explaining why.

As far as I'm aware it's likely to be more than just "some interpreters". NaN boxing is an optimization used very widely in interpreters where the only number type is floating point. It provides a fast way to encode proper integers, allowing the use of the faster integer operations.

​@@Bobbiasfloating point integer operations aren't even comparable to the speed of native integer arithmetic

@@gregorymorse8423 NaN boxing uses doubles as tagged unions. All 11 exponent bits are 1s, and the most significant bit of the mantissa is a 0 (the NaN is marked "quiet"). The exact contents of the remaining 52 bits are effectively meaningless in floating point math. The number is still a NaN regardless of the data stored in these bits. That means we can use the lower 52 bits of the mantissa for anything we want. Currently x86_64 pointers are only 48 bits wide, so we can store pointers in these bits fine. We can also store integers or anything else we want in those bits. We can also operate in the values using integer math (with the exception that is the value would overflow the 52 bits we use that's a problem we need to deal with separately). So you can store a 52 (or less) bit integer in a NaN boxed double and treat it as though it's a regular integer for more efficient math. If you are only storing integers, you can use all 52 bits, if you have multiple types you are NaN boxing, you use several upper bits as a tag, and you can still have most of the bits dedicated to see data you want.

Sounds like an AI voice

@@syryouslyit's 100% an AI voice. One of the best ones I've ever heard but the speaker makes grammar mistakes a native speaker would never make

WTF........... damn.... @@syryously

ok chatgpt

This will only work for Option As for example Option all 0 would be an ambiguous state since it would represent Some(0) and None at the same time. That optimization for pointers is only possible as each type in combination with option is treated individually. An Option would likely be 16 bits and an Option would maybe be 32 bits wide. On why it's not 24 bits look into "struct padding"

@@redcrafterlppa303 I said if there is an invalid state. Zero is a number. I thought I remembered testing this with Option and it working. Update: Just tried it and Option is in fact one byte, or at least my editor says so.

also important to add is that, according to the rustonomicon, such Option can be represented as &T, but doesnt need to, which can have consequences when using sth like transmute

@@Blaineworld yes, think about it. The bool is a 1 bit datatype and the option is a 1 bit varient type. So the compiler cramps the 2 bits into 1 byte.

@@redcrafterlppa303 I still think my “invalid state” idea might be correct. I just tested it. Specifically, I made an enum called Test with 255 variants and got the size of Option, which was in fact 1 byte. With 255 variants, every _bit_ is used, but the combination 11111111 remains unused, which if I am correct is what None is represented as in this case.

only undefined to the 0.5x rust heads who cum when their code fails to compile for the 100th time

I'm sure the animation can't be done by ai, even if the script and audio is

Yeah I know that. What I was trying to portrait is that low level people really don't like that kind of things at all. Like, in what world does it make sense that 3 * "3" is 9 but 3 + "3" is "33" ?

If you're referring specifically to the Javascript (ECMAScript) spec, then it's "defined" behaviour across so so very many edge cases is the subject of a lot of "oh my God, what the actual f*ck!" humour among programmers who don't have to deal with that kind of nonsense in their daily lives. I suspect Javascript developers just cry themselves to sleep instead. Php developers have their own catalog of "this value + that value = nonsense", which they share among themselves when they want to speculate on what the designers of that language might have been smoking.

Jorge** has added two excellent videos that cover each of those topics. His channel (this channel) is some of the very best content I've ever seen - anywhere - on this stuff. Definitely give the man a sub! (and go watch those two vids). In general anything that doesn't have a fixed size goes on the heap, whereas your various "primitive" types (integers, floating point numbers, single characters) and fixed-sized arrays of those primitive types go on the stack. In many languages you can also combine fixed combinations of those primitive types into "structs" which, because they are also a fixed size, can go on the stack. Things that don't have a fixed size (and must be stored on the heap) include; any sort of variable-length collection, strings (as opposed to a fixed-length array of characters), and objects. ** (it may be pronounced "hor-hey" unlike how the AI voice read it out, or maybe he's just had too many co-workers who can't pronounce his name and prefers "george" anyway?)

Yeah, I made that video in less than a weekend. Didn't expect it to be so popular.

I wouldn't use an unsigned age. It's confusing. You could use a unix timestamp as date of birth and have a function that calculates the age (0 for born in the future) .

@@redcrafterlppa303 Of course, it wasn't a serious remark. Linux's time stamp similarly wouldn't run out in 2034 if it wasn't a signed int32.

@@jwrm22 there is a 64bit version that gains adoption slowly but surely. It allows for prehistoric and astronomical dates solving 2 shortcomings at the same time.

It could, but it's not a topic that would fit on this channel. Maybe on a second channel.

There is a *galaxy* of difference between Python and C. Personally I would recommend you move to a statically typed, compiled language that doesn't put you so very very close to the workings of the physical hardware and include so very little "out of the box" (one look at handling strings in C and you'll run from it screaming). If you really want to jump straight to such a nuts-and-bolts level, then play with coding C for embedded micros like Arduino. Definitely don't try to write an "application" in C. If your interests are more in the software application space then languages like Java, and C# I can personally vouch for as being great things to learn (I've used both professionally and would hands-down recommend C#. Unlike Java it does make a proper distinction between data types that go on the stack and those that live on the heap, and it can be very performant if used wisely. I hear lots of good things about GoLang as well.

The voice is TTS. The animation is just PowerPoint slides. And the knowledge is a degree in CS.

Hi, I use Eleven Labs

@@CoreDumpped thank you

I'm planning to. The topic is very hard to summarize in a single video. Any specific concept in the compilers world you are interested on?

@@CoreDumpped how about vectorization and a following video on code generation using selection DAG, probably a playlist on compiler algorithms if it's possible??

If it did not have integers under the hood it would be a nightmare dealing with floating point errors in code logic that assumes integers. Imagine a for loop that increments a variable by 1 every pass. If it was a float you would get values like 5.99999998 and when you try to use that as a array index you would get an error.

@@ParkourGrip no you wouldn't, that's not how IEEE754 works. Precision errors pop up when you try to represent fractions like 1/3, but you only start losing precision on integers once you get to ludicrously large numbers that a u64 wouldn't even be able to represent.

I guess when using f64, integer logic should work well for integers in range -2^53 to 2^53. This is a larger range then i32 but smaller then i64.

It's kinda weird: Javascript there, I fixed it sorry