For people disagreeing on the stack grown upwards (address) in the animation. As someone else commented: "Growing downwards is a convention from when computers had small memories and the stack was placed at the end of the data segment... nowadays the stack can be anywhere, but the convention stuck on, at the end of the day it makes no difference".
It's just as bad in real life; uptown, downtown. Up because why? North? South? Towards the mountains, or ocean? Meh, some arguments are really not worth the trouble, you adapt and move on; unless it is family, then frankly it's war. ☺
Realistically, up vs. down is kinda a natural vision of what is happening simply because for up, the number increases, and for down it decreases. Computers, for the most part do not really care, as long as there is memory there; they can go a little crazy when they start looking at ROM, I/O, or a lack of any memory. Of course there are some devices that have instruction sets that are tuned to work a given way, pre/post increment/decrement; push and pop specifically relating to stack operations still do their thing without much care, but the convention used for a given architecture is important if you use different devices and need to keep things straight in your own head and program logic.
there is severe lack of educational material on youtube that teach conceptual subject of software and programming, I'm glad I found your channel keep up the good work my friend !
Definitely. There’s an overwhelming abundance of good videos for surface level beginner material because that’s where you get the most viewers. Once you get deeper into a topic there quickly becomes only a select few creators that are willing to make more difficult videos for a much smaller audience that is at that level.
People who explain complex things in this simple way are considered a rare coin. You have gained a large number of subscribers with only three videos. Please continue, perhaps this channel will achieve great success.
Only 3 minutes in, but I've had dreams of a youtuber with such a beautiful and minimalistic style that doesn't just go over brief basics. Thank you! Edit: It's so deeply upsetting that the best and most interesting learning channels get such little attention
@@Scrawlerismit's basics that others talk around or overcomplicate, Jorge explains it better in my opinion. and the fact it's an AI voice isn't a big issue in my opinion, maybe someone that doesn't speak English very well is trying to make these videos and keep them easily understandable? maybe someone with a disability? how about someone that just doesn't have a good microphone or quiet enough space to record? as long as the voice isn't annoying, which in this case it isn't, I'm not mad about using AI generated voices. of course channels producing slop and only using AI voices to save time are an exception to that, but Jorge puts a bit more effort into his videos than those guys.
These are some of the fundamentals that should be covered on any software development educational setting, specially when they're presented in such a visual fashion. Thank you for making this.
I really appreciate how considerable you are for mobile viewers. Many programming youtubers just show their computer screen and the letters of the code become miniscule
Thank you dearly for going over everything you did. Please don't ever feel pressured to summarize or assume the viewer knows, if everybody assumes that everybody already knows (as much of the programming world seems to do) information becomes insular and difficult to access. You're doing an amazing public service.
This was the PERFECT length and complexity for an introduction to this topic! Concise, yet doesnt presuppose a ton of knowledge, while also not delving into a bunch of side comments on details/scenarios that do nothing but stroke the creator's ego while confusing the audience :) JUST enough to know where the OS fits, types of memory, stack size constraints, etc., to understand the implications on performance and utilization, while still focusing solely on the stack itself. It leaves the viewer with tons of questions to learn more, but few to no questions about the content presented here. Bravo!
I'm learning about memory allocation in c++. (self taught). I have watched numerous videos on stack / heap. They are all very confusing and the fact that you did this so well in such a short time is of great value to me. I know have a understanding of whether i want to choose stack or heap. I also understand why i would use the smallest primitive type possible so that the cache is not wasted. Very greatful. Thankyou
Incredible video! As a 4th year CS major, I haven’t seen such a detailed and intuitive description of the stack in any of my classes. Looking forward to the heap video!
This channel is like a breath of fresh air for someone like me who's trying to learn Rust but hasn't studied CS formally or been properly exposed to the fundamentals. I'm not a bootcamp graduate, I'm just a self-taught frontend dev who's trying to break into systems-level development. Keep up the great work ❤
I've been looking for some explanation like this for years, so I could understand some concepts which didn't live my mind for all that time. And this channel just appeared in my recommendations. Thanks for very informative video.
I wish all programming channels use this style in delivering information. The explanation is perfect. The animation is perfect and aids comprehension, and the voice clarity, and thoughts are well organized. I am impressed by your videos so much. Keep it up. and Thank you from the bottom of my heart.
It's just great! I watched other videos about the stack, understood how it works, but there were a lot of questions, and in this video you just visualized everything perfectly and explained it! I'm really looking forward to a video about a heap
if teaching something an art, you are the artist. I speak python and now a days learning c++ just for fun and your videos explain a lot of things here.
This was such an amazing video. I really believe the way this video articulated each point and built up to the answer. The pace was also great. Please keep up these sort of educational low level videos!
I’ve always been interested in programming on a conceptual level, but never really had the time or resources to research them myself (I’m just a hobbyist, who’s learning in my free-time). Your videos are very fun and interesting to me and I feel like I’m learning a lot from them. I’m very excited to see more in the future!
Wow this was awesome! In all of the discussions on stacks and heaps I have heard online and in university I’ve never heard anybody explained that the CPU has a stack register. I can believe I didn’t know that. Makes a lot more sense why the access is so fast.
Your style of teaching is good. By starting with a misinformed premise, then correcting it, using it as cure against "this is why we don't just do that". This is typically the reason why I don't understand many concepts, not just in compsci. "why doesnt it just do *this*" and then I can't accept the information given to me because I think it is wrong information. This is important, because the way we learn is by building a tower of understanding using smaller blocks. If any of those blocks are wrong or misinformed, then the whole tower will fall down.
One little detail: recursion can be as good as iteration, it is less efficient and easely causes overflow in langauges languages like c++ and rust because they aren't optimised for it, and they shouldn't be. just, important to understand, recursion isn't inherintly worse than iteration. It would cause no issues in fp languages.
I'm more or less an absolute beginner in this topic and don't know too much about computer science, but I love this video! I still have a couple question and it would be great if somebody could answer some of it! 1. Is it true: The main reason why a stack structure is used is to prevent fragmentation. While it works by the "last in - first out" - principle I can still access all the data at any point without push/pop any values. 2. Where is the heap when preallocating memory? Is it a part of the preallocated memory or is it just the stack and the heap is an completely individual region? If the preallocated memory is shared by both stack and heap (but seperated), can you influence how much is reserved for the stack? 3. Is preallocating memory something you usually actively do or is it something automatically done for you? My guess would be that every program, without specifying it, allocates memory, but to get the most out of it (large enough to prevent unnecessarily requesting more memory, while not being excessively large) you can optimise the choice of how much memory to preallocate.Is it true and if not, what's really happening? 4. Can you increase the stacks size? Probably yes but it's not straight forward, because you would need more contiguouse memory right next to the stack, which I would think is unlikely (especially if 2. is correct and the heap sits right next to the stack). (Little bit OT question and some unnecessary thoughts on it: Could you migrate the entire stack to a different, larger, contiguouse memory region [and does it make sense/is it used in practice]? From how I understand the stack-datastructure also no, because a direct migration would turn the stack upside down. Opt1: So either you would have to use a stack structure on the migrated stack, where the stack pointer counts downwards or Opt2: when migrating you start writing downwards beginning with the future stack pointer to the target stack origin. Opt3: you do some buffer stuff with or maybe even without using additional "support memory".)
This video is great also for those who already understands the concepts, because they always struggles to explain memory management of OS due to its complexity.
Very good video, the only point missing is why their is padding and memory alignment. The answer is that it is still cache related, but it's a little more complex so understandable it was not mentioned.
The stack usually grows downward from before the kernel, giving it plenty of space, and reducing the chance of a stack overflow. Theoretically, you could get the stack to loop back around, but even then, data grows upwards from right after the kernel, so you would have to fill your stack a lot, so that it loops around (I have seen examples where that is 524,288 memory locations, and that’s for a raspberry pi), and then have so many files that it is feasible that the stack will overwrite one.
Another great video! However, I think you confused the Return Link and a Returned Value. Generally, you have both. The Return Link is the address to return to of the calling routine. In other words, the Return Link stores a copy of the Program Counter pushed onto the top of stack as part of calling the sub-routine so the CPU knows where to resume execution after the sub-routine call finishes. Whereas you showed the Returned Value allocated for the called sub-routine to store its results, but called it the Return Link.
Nice video. Just one thing, the SP usually decrease when STACK increase. Since the stack grows to the top, the more it grows, the more the SP point to a lower adress.😄
Dude, finding your channel was awesome. As a chemist who likes to code the repetitive homework stuff, learning these concepts is very nice insight. Thaaaaanks!
i am eagerly waitin for more your content, after working 9 years in the industry as app and web developer, I want to dive in low level programming, but only two channels I got which are educational, you and low level programming. keep posting
Excellent work, pure content with simple description and impressive animation. You hit the point with every sentence. I'm looking forward to the "heap"
I think it's worth elaborating on the relationship between the stack and the cache. For most applications, the cost of allocating and deallocating memory isn't actually a big proportion. What really affects performance is that arrays with short and fixed lengths declared directly inside functions are usually kept in the L1 Cache. Since it's the closest storage to the registers, even random read and write operations are super fast; whereas for space allocated on the heap, which is typically larger, it tends to be kept in higher-level Cache or even in MEM, but basically never in the L1 Cache. A simple experiment can prove this: allocate as much memory as possible of the same size on both the stack and the heap, and then perform matrix multiplication or matrix-vector multiplication calculations on them, and the performance difference is quite clear～
I am very happy that i found your channel. Excellent material, great explanation and in a reasonable time. 15 minutes per video i find it a sweet spot for this kind of material. Maybe you plan to do some videos on operating systems (kernel). That will be great. Thanks for the great videos!
As a professional software performance engineer, I'd say that if you are worrying about the size of individual variables on the stack, then you've probably done something wrong. It's good to understand these mental models, and yes, it helps you on the way to having a detailed mental model of software execution -- I learned a ton in the operating systems class where we built our own kernel from scratch, including setting up per-thread stacks -- but be very hesitant to over-eagerly deploy this knowledge and (over-)optimize any piece of software that you haven't already profiled and decided needs optimization. I can't think of any real-world examples where stack memory accesses were a significant factor in a software system's performance. Memory allocation is also surprisingly subtle, and with tcmalloc, is very cheap in the common case, but with longer tail latency whenever a new slab needs to be allocated. Memory allocation often tries to maximize cache hit rates by packing many small allocations near each other. Still, if something can be done on the stack, that's much more predicable, and strictly lower overhead, so I like to avoid allocations when I don't need them.
I’m sure that this videos are very hard to make, especially with all the illustrations and the animation but I have to say that you explain those topic in a very good way that I can easily understand. Keep the good job and I am waiting to see more of these videos in this topics which are very interesting
Thank you very much~ I totally love this video. I finally make myself clearly understand these foundation knowledge;) I have been told again and again that allocating in stack is faster than in heap but no one try to tell me why before you XD. Thanks thanks thanks~
Most of this stuff I already knew. But I was always concerned about knowledge holes. The way you explain things in your heap video and ESPECIALLY this one reassured me of the things I knew, explained things I never questioned just enough to allow me to piece the rest together by myself and explain things I didn't know before so well I could just pick them up without issue. If I had to suggest one thing it would be to make followup episodes on topics to explain more advanced concepts. Like in which direction does the stack grow and why? How do function calls store data on the stack to return? What are stack cookies and how do they contribute to security against buffer overflows? How does malloc organize the heap? Stuff like that for example. You don't see this often on TH-cam at all. Take my sub! If I had the money I would become a member without second thought.
Great explanation of the topic. I understand the simplification needed to make this easy to understand. But not mentioning alignment gives a wrong impression about packing.
I don't know what I'm doing but it's probably right cuz i got this video in my algorithm. I can't believe how low the subscribers are on this channel when the quality of your content is so high. The minimalistic style of animation is also a huge relief as compared to others who focus more on the animation than the explanation. This was a breeze of fresh air. Excited for the video about heap!!
Very concise and logical pill of knowledge on topic with nice and clear animations. Very good job! Level of expected prior knowledge ideal for topic. Againg great job sir! No need to excuse for simplifications, level is exacat how should be for this form and topic.
This video is so good! I have not seen anyone explain this in such an intuitive and complete yet concise way. This channel is a hidden gem I've found and I'm on my way to binge watch all of these videos Although, I didn't think it would have bothered me, but the TTS is just a tad bit monotonous and I can find myself getting lost and having to rewind 🥹🥹 I hope there is some option to add some personality to it but in any case, that's not going to stop me from all of this knowledge to be mined!! Kudos to you... Keep it up my man!
I will complete my degree in CS in a month. I wish I could find your channel in past years where I've been given some hardware heavy lectures such as Computer Organisation etc.
Good video. I just want to say that local scalar variables might not even end up in the stack. If their locality is small enough the compiler might decide to dedicate CPU registers for them. That’s why you sometimes get “this variable is optimized away” when trying to inspect it in a debugger.
Understanding the stack also lets you understand why tail-call recursion can avoid overflowing the stack, because the called function's stack frame just replaces the calling function's stack frame, instead of filling up the entire stack it just keeps reusing the same bit of memory.
Great video, just one point i missed that could be added: The stack grows downwards, so in your example to get the next address you have to -1 and not add 1.
I was waiting for someone commenting on this. If you take a closer look at 9:03 there's a note referring to this. The stack growing downwards is a convention not a must, it actually depends on the architecture. My bad for not mentioning it in the audio.
I noticed that with the diagram, the stack pointer doesn't usually point to a valid variable (unless the last variable pushed was 1 byte in size). I concluded that this must be the reason the stack normally grows down, because then the sp will point to the last variable which was pushed, so the math should be simpler
I am no expert, but: The OS does know what memory you are and arent using, if you were to allocate a GB worth of memory, all that would happen is you would get it mapped to the virtual address space of the process. The moment you read/write to it is when the OS actually goes through the work of fetching it and loading it into memory. And, conversely, if a page remains unused for long enough, i.e. it goes cold, the OS will back it up in disk. This way, if someone else ask for memory and starts using it, the unused pages can be discarded, as they are backed up in disk, and new ones can be loaded. Even if a process is asking for vast amounts of memory, the OS wont do much unless the process actively uses said memory, and if it uses it very infrequently, it will still not impede the rest of the processes much. This helps to prevent poor programming from stalling your machine (not that it wont, but it does make it harder).
Yes, this is very accurate. Although, I'd still argue the OS being aware of commonly accessed memory not necessarily means used memory. In C for example you can access memory (that belongs to your program) where you haven't written anything and nothing will happen, the OS only interrupts if you try to access memory that is not yours.
This is a great video! However I think you might be skipping over the function of the translation lookaside buffer (TLB) which fixes a lot of the memory fragmentation issues you mentioned. The OS presents a completely contiguous memory address space to each process. Thats why the stack can appear contiguous to a program despite growing without a known bound (like for recursive algorithms).
IIRC, allocation of big swaths of virtual memory, on stack or on heap, doesn't necessarily crash at the point of allocation, because actual memory pages can be assigned later, when you try to read or write in them.
hey your explantions are so good... please speak about virtual memory too in a next video ... thank you so much for making such amazing content and keep continuing doing the good work.. cheers
![[MV] A leap of faith...ความเชื่อใจครั้งสุดท้าย (From "Petrichor the series")](http://i.ytimg.com/vi/U1piZH2CNXA/mqdefault.jpg)
For people disagreeing on the stack grown upwards (address) in the animation.
As someone else commented:
"Growing downwards is a convention from when computers had small memories and the stack was placed at the end of the data segment... nowadays the stack can be anywhere, but the convention stuck on, at the end of the day it makes no difference".
That's a silly thing to disagree with. Up, down, it's a subjective choice unless you define which way the address range is incrementing.
Also I think you confused internal and external fragmentation
It's just as bad in real life; uptown, downtown. Up because why? North? South? Towards the mountains, or ocean? Meh, some arguments are really not worth the trouble, you adapt and move on; unless it is family, then frankly it's war. ☺
What you used to animate this video?
Realistically, up vs. down is kinda a natural vision of what is happening simply because for up, the number increases, and for down it decreases.
Computers, for the most part do not really care, as long as there is memory there; they can go a little crazy when they start looking at ROM, I/O, or a lack of any memory.
Of course there are some devices that have instruction sets that are tuned to work a given way, pre/post increment/decrement; push and pop specifically relating to stack operations still do their thing without much care, but the convention used for a given architecture is important if you use different devices and need to keep things straight in your own head and program logic.
there is severe lack of educational material on youtube that teach conceptual subject of software and programming, I'm glad I found your channel keep up the good work my friend !
Nah you just need to know how to search properly and you will find gems
Definitely. There’s an overwhelming abundance of good videos for surface level beginner material because that’s where you get the most viewers. Once you get deeper into a topic there quickly becomes only a select few creators that are willing to make more difficult videos for a much smaller audience that is at that level.
There's some excellent material, e.g. MIT OpenCourseWare. Of course quality is rarely recognized, let alone promoted.
There is actually a huge depth of information. Just look around and maybe try and figure out exactly what to look for
there is lack of people who care about it, i think there is plenty of content, though quality is not as in this video...
People who explain complex things in this simple way are considered a rare coin. You have gained a large number of subscribers with only three videos. Please continue, perhaps this channel will achieve great success.
Only 3 minutes in, but I've had dreams of a youtuber with such a beautiful and minimalistic style that doesn't just go over brief basics. Thank you!
Edit: It's so deeply upsetting that the best and most interesting learning channels get such little attention
its the basics delivered to you by an ai voice lol. its nice but its not that nice.
@@Scrawlerismit's basics that others talk around or overcomplicate, Jorge explains it better in my opinion. and the fact it's an AI voice isn't a big issue in my opinion, maybe someone that doesn't speak English very well is trying to make these videos and keep them easily understandable?
maybe someone with a disability? how about someone that just doesn't have a good microphone or quiet enough space to record?
as long as the voice isn't annoying, which in this case it isn't, I'm not mad about using AI generated voices. of course channels producing slop and only using AI voices to save time are an exception to that, but Jorge puts a bit more effort into his videos than those guys.
These are some of the fundamentals that should be covered on any software development educational setting, specially when they're presented in such a visual fashion. Thank you for making this.
Masterly done, the best video about the stack. A gem. Unfortunely not all people are made to teach.
I really appreciate how considerable you are for mobile viewers. Many programming youtubers just show their computer screen and the letters of the code become miniscule
Thank you dearly for going over everything you did. Please don't ever feel pressured to summarize or assume the viewer knows, if everybody assumes that everybody already knows (as much of the programming world seems to do) information becomes insular and difficult to access. You're doing an amazing public service.
Code salesman: **Slaps roof of stack**
"This bad boy can fit so much data in it."
This was the PERFECT length and complexity for an introduction to this topic! Concise, yet doesnt presuppose a ton of knowledge, while also not delving into a bunch of side comments on details/scenarios that do nothing but stroke the creator's ego while confusing the audience :)
JUST enough to know where the OS fits, types of memory, stack size constraints, etc., to understand the implications on performance and utilization, while still focusing solely on the stack itself. It leaves the viewer with tons of questions to learn more, but few to no questions about the content presented here. Bravo!
I'm learning about memory allocation in c++. (self taught).
I have watched numerous videos on stack / heap. They are all very confusing and the fact that you did this so well in such a short time is of great value to me.
I know have a understanding of whether i want to choose stack or heap. I also understand why i would use the smallest primitive type possible so that the cache is not wasted.
Very greatful. Thankyou
Incredible video! As a 4th year CS major, I haven’t seen such a detailed and intuitive description of the stack in any of my classes. Looking forward to the heap video!
Excellent, as an embedded software dev, these kind of videos are a rare gem. Keep em coming
THIS CHANNEL IS A FIELD OF GOLD! GOLD! GOLD! GOLD I TELL YA! GOOOOLLLLLDDDD!
This channel is like a breath of fresh air for someone like me who's trying to learn Rust but hasn't studied CS formally or been properly exposed to the fundamentals. I'm not a bootcamp graduate, I'm just a self-taught frontend dev who's trying to break into systems-level development. Keep up the great work ❤
If you want to work with embedded systems, I would suggest you take an overview of OS and COA.
Amazingly done. I finally understand what on earth the stack even means. Why its so fast is secondary. Thank you for this !
I've been looking for some explanation like this for years, so I could understand some concepts which didn't live my mind for all that time. And this channel just appeared in my recommendations. Thanks for very informative video.
I wish all programming channels use this style in delivering information. The explanation is perfect. The animation is perfect and aids comprehension, and the voice clarity, and thoughts are well organized. I am impressed by your videos so much. Keep it up. and Thank you from the bottom of my heart.
It's just great! I watched other videos about the stack, understood how it works, but there were a lot of questions, and in this video you just visualized everything perfectly and explained it! I'm really looking forward to a video about a heap
This channel is GOLD 🔥! Now I know what the Cache, Swap etc is. True gold! Please keep making these videos ❤
if teaching something an art, you are the artist. I speak python and now a days learning c++ just for fun and your videos explain a lot of things here.
Great vid! I have always wondered why I can't add to an array, this makes it perfectly clear to me
Your clear explanations and diagrams in video are very intuitive! I have comprehend a lot of things than my university experience.. appreciate that!!!
This was such an amazing video. I really believe the way this video articulated each point and built up to the answer. The pace was also great. Please keep up these sort of educational low level videos!
That was the best explanation of memory stack I have ever seen.
I’ve always been interested in programming on a conceptual level, but never really had the time or resources to research them myself (I’m just a hobbyist, who’s learning in my free-time). Your videos are very fun and interesting to me and I feel like I’m learning a lot from them. I’m very excited to see more in the future!
These videos are so clear and concise. Amazing work, keep it up
I love your teaching style and sense of humo...
More videos please! Your method keeps me from being overwhelmed.
Wow this was awesome! In all of the discussions on stacks and heaps I have heard online and in university I’ve never heard anybody explained that the CPU has a stack register. I can believe I didn’t know that. Makes a lot more sense why the access is so fast.
There are also register stacks. e.g. in SPARC. I could try to explain it in a comment but the Wikipedia article does it better.
Your style of teaching is good. By starting with a misinformed premise, then correcting it, using it as cure against "this is why we don't just do that". This is typically the reason why I don't understand many concepts, not just in compsci. "why doesnt it just do *this*" and then I can't accept the information given to me because I think it is wrong information. This is important, because the way we learn is by building a tower of understanding using smaller blocks. If any of those blocks are wrong or misinformed, then the whole tower will fall down.
i really like how elaborately you explain these concepts, as someone just getting into systems programming, your videos are really helpful to me
One little detail: recursion can be as good as iteration, it is less efficient and easely causes overflow in langauges languages like c++ and rust because they aren't optimised for it, and they shouldn't be.
just, important to understand, recursion isn't inherintly worse than iteration. It would cause no issues in fp languages.
Great video! Liked after hearing the proper use of the word “datum” at 8:28. 😉
You have earned my subscription, that was a better crash course than my SOEN classes
the end plot twist and cut is S tier
I'm mainly only receptive to video educational content and I found yours to specifically resonate with my learning style. Earned a sub, well done.
I'm more or less an absolute beginner in this topic and don't know too much about computer science, but I love this video!
I still have a couple question and it would be great if somebody could answer some of it!
1. Is it true: The main reason why a stack structure is used is to prevent fragmentation. While it works by the "last in - first out" - principle I can still access all the data at any point without push/pop any values.
2. Where is the heap when preallocating memory? Is it a part of the preallocated memory or is it just the stack and the heap is an completely individual region? If the preallocated memory is shared by both stack and heap (but seperated), can you influence how much is reserved for the stack?
3. Is preallocating memory something you usually actively do or is it something automatically done for you? My guess would be that every program, without specifying it, allocates memory, but to get the most out of it (large enough to prevent unnecessarily requesting more memory, while not being excessively large) you can optimise the choice of how much memory to preallocate.Is it true and if not, what's really happening?
4. Can you increase the stacks size? Probably yes but it's not straight forward, because you would need more contiguouse memory right next to the stack, which I would think is unlikely (especially if 2. is correct and the heap sits right next to the stack).
(Little bit OT question and some unnecessary thoughts on it: Could you migrate the entire stack to a different, larger, contiguouse memory region [and does it make sense/is it used in practice]? From how I understand the stack-datastructure also no, because a direct migration would turn the stack upside down. Opt1: So either you would have to use a stack structure on the migrated stack, where the stack pointer counts downwards or Opt2: when migrating you start writing downwards beginning with the future stack pointer to the target stack origin. Opt3: you do some buffer stuff with or maybe even without using additional "support memory".)
This video is great also for those who already understands the concepts, because they always struggles to explain memory management of OS due to its complexity.
Superb video, thank you so much, love from India 🇮🇳🇮🇳🇮🇳
Best low level content on this platform. No question
Very good video, the only point missing is why their is padding and memory alignment. The answer is that it is still cache related, but it's a little more complex so understandable it was not mentioned.
this is some phenomenal explaination, i think its even better than my uni courses, well done, looking forward for more videos from you
The stack usually grows downward from before the kernel, giving it plenty of space, and reducing the chance of a stack overflow. Theoretically, you could get the stack to loop back around, but even then, data grows upwards from right after the kernel, so you would have to fill your stack a lot, so that it loops around (I have seen examples where that is 524,288 memory locations, and that’s for a raspberry pi), and then have so many files that it is feasible that the stack will overwrite one.
Exceptionally Great explaination with examples. Keep teaching stuff like this.
Wow, the way you explain and the quality of your work is amazing, i really appreciate it 🎉🎉🎉
the best teacher ever 😍😍😍🥰🥰
Another great video! However, I think you confused the Return Link and a Returned Value. Generally, you have both. The Return Link is the address to return to of the calling routine. In other words, the Return Link stores a copy of the Program Counter pushed onto the top of stack as part of calling the sub-routine so the CPU knows where to resume execution after the sub-routine call finishes. Whereas you showed the Returned Value allocated for the called sub-routine to store its results, but called it the Return Link.
This TH-camr is cracked mannn let’s go!!! Such a beautiful presentation of knowledge, thanks man! Keep doing what you doing brother 💪❤❤❤❤
Your videos are invaluable ... You have all my respect.
Nice video. Just one thing, the SP usually decrease when STACK increase. Since the stack grows to the top, the more it grows, the more the SP point to a lower adress.😄
Dude, finding your channel was awesome. As a chemist who likes to code the repetitive homework stuff, learning these concepts is very nice insight. Thaaaaanks!
If my lecturer had taught computer architecture like this, i would have really loved this subject :3
Best video I’ve seen in a while. Perfect blend between programming and hardware information.
Peak of computer science knowledge explanations.
i am eagerly waitin for more your content, after working 9 years in the industry as app and web developer, I want to dive in low level programming, but only two channels I got which are educational, you and low level programming. keep posting
Great video, thanks for sharing this knowledge.
Excellent work, pure content with simple description and impressive animation. You hit the point with every sentence. I'm looking forward to the "heap"
waaaaaaauw!!!!! neighter in university nor in any other place nobody explains that how stack works and how processor cache works. you're awesome bro.
I think it's worth elaborating on the relationship between the stack and the cache. For most applications, the cost of allocating and deallocating memory isn't actually a big proportion. What really affects performance is that arrays with short and fixed lengths declared directly inside functions are usually kept in the L1 Cache. Since it's the closest storage to the registers, even random read and write operations are super fast; whereas for space allocated on the heap, which is typically larger, it tends to be kept in higher-level Cache or even in MEM, but basically never in the L1 Cache. A simple experiment can prove this: allocate as much memory as possible of the same size on both the stack and the heap, and then perform matrix multiplication or matrix-vector multiplication calculations on them, and the performance difference is quite clear～
What a concise explanation accompanied by a very intuitive graphics! Kudos to you!
Please continue delivering this kind of high quality videos 😊
This is amazing, looking forward to learn more about optimisation and security
the best explanation i have ever listened
Came here to learn about the stack, ended up learning the meaning of StackOverflow's logo.
I enjoy watching your videos and love the way you explain major concepts! Please make more!
I am very happy that i found your channel. Excellent material, great explanation and in a reasonable time. 15 minutes per video i find it a sweet spot for this kind of material. Maybe you plan to do some videos on operating systems (kernel). That will be great. Thanks for the great videos!
As a professional software performance engineer, I'd say that if you are worrying about the size of individual variables on the stack, then you've probably done something wrong. It's good to understand these mental models, and yes, it helps you on the way to having a detailed mental model of software execution -- I learned a ton in the operating systems class where we built our own kernel from scratch, including setting up per-thread stacks -- but be very hesitant to over-eagerly deploy this knowledge and (over-)optimize any piece of software that you haven't already profiled and decided needs optimization. I can't think of any real-world examples where stack memory accesses were a significant factor in a software system's performance. Memory allocation is also surprisingly subtle, and with tcmalloc, is very cheap in the common case, but with longer tail latency whenever a new slab needs to be allocated. Memory allocation often tries to maximize cache hit rates by packing many small allocations near each other. Still, if something can be done on the stack, that's much more predicable, and strictly lower overhead, so I like to avoid allocations when I don't need them.
I’m sure that this videos are very hard to make, especially with all the illustrations and the animation but I have to say that you explain those topic in a very good way that I can easily understand.
Keep the good job and I am waiting to see more of these videos in this topics which are very interesting
Your style of explaining is quite comfortable to follow and easy to understand. Keep making these videos. Already subbed !
Thank you very much~ I totally love this video. I finally make myself clearly understand these foundation knowledge;) I have been told again and again that allocating in stack is faster than in heap but no one try to tell me why before you XD. Thanks thanks thanks~
How much background work and knowledge does it take to explain it so neatly? It's pretty amazing.
This takes me back to highschool, haven't touched C in decades :)) Might have to start a project for old times sake
Loved this video. Great explaination, high video quality and a wonderful illustration!
Very eloquent and detailed explanation. I liked the animation too. Keep it up!
Most of this stuff I already knew. But I was always concerned about knowledge holes.
The way you explain things in your heap video and ESPECIALLY this one reassured me of the things I knew, explained things I never questioned just enough to allow me to piece the rest together by myself and explain things I didn't know before so well I could just pick them up without issue.
If I had to suggest one thing it would be to make followup episodes on topics to explain more advanced concepts. Like in which direction does the stack grow and why? How do function calls store data on the stack to return? What are stack cookies and how do they contribute to security against buffer overflows? How does malloc organize the heap? Stuff like that for example.
You don't see this often on TH-cam at all. Take my sub! If I had the money I would become a member without second thought.
Great explanation of the topic. I understand the simplification needed to make this easy to understand. But not mentioning alignment gives a wrong impression about packing.
I think this is the first video I've ever seen from this channel. Really liked it.
I don't know what I'm doing but it's probably right cuz i got this video in my algorithm. I can't believe how low the subscribers are on this channel when the quality of your content is so high. The minimalistic style of animation is also a huge relief as compared to others who focus more on the animation than the explanation. This was a breeze of fresh air. Excited for the video about heap!!
This is a very well-made video about stacks. Nicely done. 5 gold stars for you.
Very concise and logical pill of knowledge on topic with nice and clear animations. Very good job!
Level of expected prior knowledge ideal for topic. Againg great job sir!
No need to excuse for simplifications, level is exacat how should be for this form and topic.
Totally forgot that from my computer engineering class, as mindblown as in the auditorium back then :)
This video is so good! I have not seen anyone explain this in such an intuitive and complete yet concise way. This channel is a hidden gem I've found and I'm on my way to binge watch all of these videos
Although, I didn't think it would have bothered me, but the TTS is just a tad bit monotonous and I can find myself getting lost and having to rewind 🥹🥹 I hope there is some option to add some personality to it but in any case, that's not going to stop me from all of this knowledge to be mined!!
Kudos to you... Keep it up my man!
Today I understand why use stacks or how memory allocation works 🎉
your video is best it😊
great job, what are your usual gotos to learn around this topics?
Awesome video, it's blissful😊.
Thank you❤❤.
This is very educational, the type of knowledge that I am not taught. Please do a video about the CPU
Amazing visual representations! Are you using motioncanvas?
Believe it or not, it's just Power Point slides.
I will complete my degree in CS in a month. I wish I could find your channel in past years where I've been given some hardware heavy lectures such as Computer Organisation etc.
Whe need more resources like this. As a autodidact, learning about computer memory can be tricky, especially because my first language was python.
Good video. I just want to say that local scalar variables might not even end up in the stack. If their locality is small enough the compiler might decide to dedicate CPU registers for them. That’s why you sometimes get “this variable is optimized away” when trying to inspect it in a debugger.
Understanding the stack also lets you understand why tail-call recursion can avoid overflowing the stack, because the called function's stack frame just replaces the calling function's stack frame, instead of filling up the entire stack it just keeps reusing the same bit of memory.
Great video, just one point i missed that could be added: The stack grows downwards, so in your example to get the next address you have to -1 and not add 1.
I was waiting for someone commenting on this. If you take a closer look at 9:03 there's a note referring to this.
The stack growing downwards is a convention not a must, it actually depends on the architecture.
My bad for not mentioning it in the audio.
i bet there are archs with a growing up stack; i just never used any of thees. For me its n atural that the stack goes down and the heap goes up ;)
I noticed that with the diagram, the stack pointer doesn't usually point to a valid variable (unless the last variable pushed was 1 byte in size). I concluded that this must be the reason the stack normally grows down, because then the sp will point to the last variable which was pushed, so the math should be simpler
Although I know the topic, it's interesting to watch this video. I like visualisations. Thanks, waiting for heap!
loved your contents i prefer more links /references for further reading...it will help peoples interested to dive deep in the topic
I am no expert, but:
The OS does know what memory you are and arent using, if you were to allocate a GB worth of memory, all that would happen is you would get it mapped to the virtual address space of the process. The moment you read/write to it is when the OS actually goes through the work of fetching it and loading it into memory. And, conversely, if a page remains unused for long enough, i.e. it goes cold, the OS will back it up in disk. This way, if someone else ask for memory and starts using it, the unused pages can be discarded, as they are backed up in disk, and new ones can be loaded. Even if a process is asking for vast amounts of memory, the OS wont do much unless the process actively uses said memory, and if it uses it very infrequently, it will still not impede the rest of the processes much.
This helps to prevent poor programming from stalling your machine (not that it wont, but it does make it harder).
Yes, this is very accurate. Although, I'd still argue the OS being aware of commonly accessed memory not necessarily means used memory. In C for example you can access memory (that belongs to your program) where you haven't written anything and nothing will happen, the OS only interrupts if you try to access memory that is not yours.
Thank u for sharing this much brilliant knowledge. I’ve learned a lot from this video. Appriciate it 🥰
This is a great video! However I think you might be skipping over the function of the translation lookaside buffer (TLB) which fixes a lot of the memory fragmentation issues you mentioned. The OS presents a completely contiguous memory address space to each process. Thats why the stack can appear contiguous to a program despite growing without a known bound (like for recursive algorithms).
Great video, great explanation. I didnt know anything about this and i learnt a lot.
IIRC, allocation of big swaths of virtual memory, on stack or on heap, doesn't necessarily crash at the point of allocation, because actual memory pages can be assigned later, when you try to read or write in them.
hey your explantions are so good... please speak about virtual memory too in a next video ... thank you so much for making such amazing content and keep continuing doing the good work.. cheers