I'm also studying memory allocations at the moment. I'm primarily focusing on C#, but the way you explained it and covered how all other programming languages dealt with memory is really eye-opening. Thanks for your hard work in putting things together! Really appreciate it!
That was a fantastic explanation of the differences between heap and stack. I would love to see more videos like this, covering fundamental concepts in computer science. Thanks for the great content!
Love the explanations and analogies! I would love to see a video on responsible memory management in Python. Sometimes my more complex programs run into segmentation faults and I have no idea how to deal with it.
Same here - it’s really hard to write non-trivial C++ code without understanding how memory works. For that reason alone, it’s a great language to learn.
@@ArjanCodes yes it really is a great language. Speaking on pandas in particular, since every method in pandas returns a dataframe or a series I do all my data manipulation and mutation in one scope by chaining methods instead of assigning to a variable for each transformation and creating a new heap allocated object.
Arjan, this is hands down the best description of the concepts stack and heap I have ever seen. Having earned my money as an embedded devekoper for more than 18 years now (and we are talking deep embedded here with no OS hiding the hard facts from you), this is something I still know when I get woken up at my desk for lunch break😅, but I wish I could have had that when I first heard about it in university. On a different note, your RapGPT screenshots were hilarious. Although I have to admit (no offense) that my brain combined the topic of rap and the fact that you are Dutch to who's probably the most famous Dutch rappers - MC Miker G & DJ Sven with their famous 80s Holiday Rap. 😂 Now feel free to include a joke about Germans in one of your next videos, I can take it....
Great video!!! Ive been overthinking aboout how the hell this line of code affect my runtime everytime i define a 3d+ array, im using python but its issue of being slow is haunting me 😂 every damn time, it wasnt a long ago when i ffor the first time heard ahout rust and it memory safety. Your videos really help me through SO MUCH REALIZATION OF HOW SHOULD WRITE MY CODE, it was your video that made me ve been type annotating (and some refactor) my code, cz i need different balance of static-and-dynamic code in different places in my programs, and btw, im a geophysics undergrad so 3d+ array is everywhere in my code. Iv been considering to join your youtube subscriptions as your start videos about rust.
Excellent. I was discussing the python slow argument with my teacher a time ago... Related to a accountability gui program I was developing. He's position was that C++ is thousands of times faster. But, what's the real deference between a 0.000002 secs and 0.005 secs of response time after you press a button??? It's unnoticeable!! And getting the same software running is a lot faster on python❤ so... I won 😅
Wow, you introduced the spaghetti memory :D And I love you mentioned Rust, its solution for that is really brilliant. I, personally like to make prototypes in Python, but it consumes so much memory, sometime you need to call the GC just to free up the memory faster, and GIL ties your hand, so multiprocessing and maybe asynch programming can be an option, but communication between processes is still "hard", in which situation I prefer messaging architecture, so i.e., ZMQ library can be a good option. However building a reliable messaging architecture with Python + ZMQ + multiprocessing + asyncio.... can be challenging compared to a "better" designed language that can deal with OS threads. But, sure, it depends. I prefer safe, compiled codes because I need performance in my job. And I also experienced that the "fast-to-market" approach using cheaper mediocre programmers... will be very expensive soon when you have to rebuild everything and then, your client may loos their advantages. Yeap, programming is not for everyone.
It's not just std::unique_ptr which helps with memory management. Also the containers, namely std::vector are a direct replacement of the new and delete[]. Combine these two and you never need to even use those operators.
Brilliant! I prefer Python as a one-man shop because its memory management is as robust as it is transparent. I have enough fires to put out everywhere else. 😅 Like everything you can have it fast, cheap, and good, but only two of the three at a time.
Using Lego blocks instead of wood to demonstrate each type's size, how they fit into memory, and how many positions to skip with words to fit different types together would be very helpful. You could create another video to explain this fundamental concept in the context of Rust and its ownership concept with Lego!
This is why I think it's good for your first adult language to be plain ol' C? To implement a few basic algorithms and data structures before moving on? Then you know what the other higher level imperative languages are doing under the hood. I'm sure some folks will disagree...
I'd never say I use a language because I'm lazy. I mean, I AM lazy but that's not the reason we have high level language. Order, clarity, maintainability, security and lower time reuqired to develop are perfectly good tradeoffs for execution speed in many cases.
Im bit confused about stack. What if I allocate memory for a global variable from a function. Function ends and it should pop the function, but isnt global variable gonna be above the function in stack?
@@talicopowi'm afraid that is an implementation detail which varies by operating system, language, and data type. in some languages, especially interpreted ones, the only thing special about global variables is their scope, and the variables are placed on the heap, just like for any other routine. the difference being that the function in question is the main function, which does not get released until the program ends, and otherwise is managed just like any function. when the language uses compilation, and the operating system allows shared libraries, you end up with the code getting one section of immutable memory which can then be declared read only and shared between programs so you don't need to have multiple copies. in modern compilers, like llvm, it was realised that there is a subclass of global variables that also share this dynamic, and thus can be stored in another block treated the same way. this needs support in the operating system to be able to handle this immutable data block in shared libraries in this way. not every global variable is immutable, and in interpreted languages, the ability to determine this may be undecidable unless the language specifically supports declaring the variable to be this way. the same also applies to local variables. this becomes even worse if one of the main advantages of interpreted languages, the access to the evaluation function, is provided to the programmer, as at that point all memory access not declared to e immutable becomes dynamic, so the size of this block when you cannot declare a variable this way becomes zero. you then also have an additional problem that garbage collection has to be either on demand, or incremental. on demand halts all program execution until a fairly full sweep of memory has bean completed, which causes issues for real time programming, which requires the timings to be deterministic. the only solution to this is to do it incrementally, but the problem,with that is we have not been doing it for long, so the solutions are still at a fairly simplistic level in most implementations. also, while reflections and other methods of looking at internal detail of object oriented programs adds lots to the power of debugging in a language, it does so by breaking a lot of the guarantees needed to allocate the global variables to the immutable block. automated memory management is brilliant, but even when the programmer is granted the ability to tell the language to do things differently, it is very complicated. it requires systematic support at all levels from the bios up to the runtime execution of the specific program, or it does not work as well as the proponents hype it up to work. in the end, it it the programmer who knows best how the code is intended to be used, while the language should enable them to clarify that intent and enforce it with the help of lower level parts of the system.
variable handling in programs is complicated, and in functions it is even harder. this has to do with two key properties of a variable, scope and mutability. when you declare a global variable in the main function, you know the scope is going to be global. if it is a value like pi, you also know it is not supposed to change, so in a compiled language you can allocate it to an immutable data block with global scope, and hope that the library management code supports and enforces this being a single copy of read only data. when you then pass pi to your function, it can either be as a global variable, or as a parameter to thar function. if the language uses call by value, you then know that it will have a scope of the function lifetime, and it will not be returned to the same variable. as it is a copy of the data, any changes will only last the lifetime of the function, so you can store it on the stack. even better if nothing in the function writes to it, you can also decide at analysis time it is immutable. the same also applies with any other variable you explicitly declare to be local or immutable, so it can also go on the stack.anything that has to survive the termination of the function has to be treated by the function as global, but can be explicitly local to any calling function, or can be local to the library. depending on support within the language and the operating system, knowledge that something is global and immutable can be used to minimise total memory usage, and language support should be provided to enable the programmer to explicitly declare both scope and mutability, but most languages don't support that functionality. to the extent that this is not supported, the language has to guess, but currently the algorithms which exist to support such guessing are fairly primitive. also the way the guessing is done tends to be both language and implementation specific. the guessing gets even harder if the language is interpreted, and even more so if you have complex objects with variable length data types in them. in some languages like the original implementation of lisp, even the program code is not guaranteed to remain the same for the duration of the program, as a function is just another piece of data which can be changed by another function. anything which is correctly guessed to be read only and of fixed scope can go on the stack, which includes some global variables. literally everything else must go on the heap, at which point the problems of garbage collecting the heap get further complicated by the same problems. you can only remove something from the heap if you know it is not needed anymore. for simple but advanced data structures you can use reference counting to determine that it has no users, and rapidly collect that part of the heap back into free space. if you know that in the first part of the program you are going to load in some data, use it to build another data structure used by the second part, and is then no longer needed by the rest of the program, you could free off that part of the heap at that point, but only if you can tell the language it is safe to do so. otherwise it is back to guessing, and if you cannot be sure you have to keep it around. at the operating system level it is even worse, because it has to deal with every heap and every stack for every running program, and handle virtual memory for when you run out. memory management is not simple, and won^t be for a long time, and comes with large costs whatever solution you choose.
"In Python you don't have to worry about memory management at all" That is not completely true. Circular references between objects can still cause memory leaks, that is why weakref exists.
As a comment I would say performance is ALWAYS a factor for software development, but it's not everything. A piece of code can run 20x slower than C and still solve the problem in an acceptable time, while requiring a fraction of the effort (and cost). Engineering is never about always using the perfect solution. In that case all roads would be perfect lines crossing mountains and rivers and cities. Instead is finding the optimal way to solve a problem with limited resources.
I've been told Python was nothing more than a toy, especially at the "enterprise level", but I think it was more an issue of gatekeeping than anything else.
you are awesome man! ı thınk we are at the same age. everything comes with a price.keep playing with the robots.otherwise where is the fun of it to burn your brain every day.
If you represent pointers with strings and most programming languages represent strings with pointers then how would you represent strings with physical strings 😂😅
