[Development] Stack Vs Heap Memory Allocation | page 1 2
|
---|
|
---|
| | Samuel Devulder
Posts 248 20 Mar 2020 12:54
| So, you never heard of static storage in C. Storage classes (register, auto, extern, static) are within the basics of the language. BSS is just the asm version of it.
| |
| | Olle Haerstedt
Posts 110 20 Mar 2020 16:59
| Samuel Devulder wrote:
| So, you never heard of static storage in C. Storage classes (register, auto, extern, static) are within the basics of the language. BSS is just the asm version of it.
|
That has a very easy explanation: I don't know C. Nor ASM.
| |
| | Olle Haerstedt
Posts 110 23 Mar 2020 22:15
| Fun fact: AmiBlitz seems to use a pool for their array implementation: https://github.com/AmiBlitz/AmiBlitz3/blob/master/Sourcecodes/Amiblitz3/BlitzLibs/ACIDLIBS/arrayslib.ab3#L100
| |
| | Stefan "Bebbo" Franke
Posts 142 25 Mar 2020 12:04
| Thumb rule: If the memory is no longer in use when your function returns, use the stack. The only exception: Your stack is limited and maybe not large enough. Q: Why use the stack? A: there is no alloc/free cost, no overhead => fastest way Q: What if the stack is limited? A: if you know the max required stack size, enforce that stack size - check the stack size and abort with an appropriate message: "set stack to ..." "start me using the icon - and the icon sets the stack size" - use swapstack Q: What if the stack can't be used? A: Use the memory management of your preference :-)
| |
| | Olle Haerstedt
Posts 110 25 Mar 2020 21:22
| Stefan "Bebbo" Franke wrote:
| Thumb rule: If the memory is no longer in use when your function returns, use the stack. The only exception: Your stack is limited and maybe not large enough. Q: Why use the stack? A: there is no alloc/free cost, no overhead => fastest way Q: What if the stack is limited? A: if you know the max required stack size, enforce that stack size - check the stack size and abort with an appropriate message: "set stack to ..." "start me using the icon - and the icon sets the stack size" - use swapstack Q: What if the stack can't be used? A: Use the memory management of your preference :-)
|
Not so common to enforce a specific stack size on Amiga, right? But definitely possible. And especially if it speeds things up. Next step would be to not use any dynamic data structures, like linked lists. E.g., if the hero can shoot max 5 bullets at any time, then keep an array of size 5 ready and keep looping it, ignoring empty cells. Doing priority queues or trees this way I don't know how atm.
| |
| | Olle Haerstedt
Posts 110 25 Mar 2020 21:46
| I really like this quote: "The trick is to not use the same allocator when the lifetime is different. Some resources are allocated once and basically never freed. Some resources are allocated per level and freed all at once at the end. Some resources are allocated during a frame and freed all at once when a new frame starts. And lastly, a few resources are allocated and freed randomly, and here the cost of fragmentation is manageable because we're talking about a few small chunks (like network packets) " From: EXTERNAL LINK
| |
| | Stefan "Bebbo" Franke
Posts 142 25 Mar 2020 21:57
| Olle Haerstedt wrote:
| I really like this quote: "The trick is to not use the same allocator when the lifetime is different. Some resources are allocated once and basically never freed. Some resources are allocated per level and freed all at once at the end. Some resources are allocated during a frame and freed all at once when a new frame starts. And lastly, a few resources are allocated and freed randomly, and here the cost of fragmentation is manageable because we're talking about a few small chunks (like network packets) " From: EXTERNAL LINK |
easy-peasy mainFx() alloc global stuff (stack or global) call level's function each levelFx() alloc level's stuff (stack or global) play level frame loop free level's stuff free global stuff
And * you must/should not allocate stuff per level. Preallocate everything per level. * free your stuff at game end
| |
| | Olle Haerstedt
Posts 110 25 Mar 2020 22:12
| Stefan "Bebbo" Franke wrote:
| Olle Haerstedt wrote:
| I really like this quote: "The trick is to not use the same allocator when the lifetime is different. Some resources are allocated once and basically never freed. Some resources are allocated per level and freed all at once at the end. Some resources are allocated during a frame and freed all at once when a new frame starts. And lastly, a few resources are allocated and freed randomly, and here the cost of fragmentation is manageable because we're talking about a few small chunks (like network packets) " From: EXTERNAL LINK |
easy-peasy mainFx() alloc global stuff (stack or global) call level's function each levelFx() alloc level's stuff (stack or global) play level frame loop free level's stuff free global stuff
And * you must/should not allocate stuff per level. Preallocate everything per level. * free your stuff at game end |
Yes, that makes sense. And then either use a static buffer or ask OS for a block of memory at program/level start, allocate by incrementing the pointer and free everything at end. All assuming your memory consumption is "reasonable" and pretty simple. :) Advanced algorithms maybe complicate this. What about the memory consumption of the A* algorithm, for example?
| |
| | Olle Haerstedt
Posts 110 25 Mar 2020 22:24
| Another brilliant quote about memory pooling: "there were like 256 possible projectiles in Battlezone(1998) in the world at any time and if something fired 257th an old one just ceased to exist. Particles systems worked that way as well." Now that I like. :D
| |
| | Stefan "Bebbo" Franke
Posts 142 26 Mar 2020 17:03
| Olle Haerstedt wrote:
| Another brilliant quote about memory pooling: "there were like 256 possible projectiles in Battlezone(1998) in the world at any time and if something fired 257th an old one just ceased to exist. Particles systems worked that way as well." Now that I like. :D
|
if you test thoroughly and estimate reasonably, you can work well with the remaining deficits. It is better to have a playable game with a maximum of 256 bullets than a game with an unlimited number that sucks. I hate people who complain, but have not achieved anything themselves.
| |
| | Olle Haerstedt
Posts 110 26 Mar 2020 19:33
| Stefan "Bebbo" Franke wrote:
|
Olle Haerstedt wrote:
| Another brilliant quote about memory pooling: "there were like 256 possible projectiles in Battlezone(1998) in the world at any time and if something fired 257th an old one just ceased to exist. Particles systems worked that way as well." Now that I like. :D |
if you test thoroughly and estimate reasonably, you can work well with the remaining deficits. It is better to have a playable game with a maximum of 256 bullets than a game with an unlimited number that sucks. I hate people who complain, but have not achieved anything themselves.
|
Sure. Don't think it was meant as complaining as much as an interesting time-typical factoid of earlier computing. Most people in the thread seemed to be devs.
| |
|