How important is understanding heap vs stack memory allocation?

Who knows--I'm a python developer after all.

Also I completed by first alife simulation. Took me from 7 pm yesterday to 10.30am this morning.

Feels good. I'm at the part of familiarity with the language that my thoughts are pretty much directly parsed and translated into code, without any effort.

Alife's just for the standard math shitposting though. Was fun regardless.

Aye, tag po-lice here
Can I see your devrant tag license?

@melezorus34 those aren't even the worst tags I've written.

I'm completely incapable of writing useful tags!

How important? Extremely.
How urgent? Not at all. This is typically the kind of knowledge that finds you when it becomes relevant.

@lorentz "This is typically the kind of knowledge that finds you when it becomes relevant."

Oh hell, I guess it's relevant right about--now.

Theres probably a derogatory word for people who write interpreters..for assembly languages.

Took a parameter mutation approach.

Halfway through I realized I should have had a 'microcode' type environment instead where each organism is represented by a miniprogram that has access to a limited number of virtual registers and/or a stack. And each cycle I randomly generate organisms, and mutations of those, while measuring fitness against the task (prime factorization, lol).

Why come up with the parameters myself, least of all the formulas, when the artificial life can do that for me? It's a bigger space of simulation, but if I give it access to proper high level operations in the form of individual opcodes, then it should evolve quicker.

Also you're like a number theory hero, I can't imagine bullshit implementation details stopping you from doing anything.

@lorentz "number theory hero"

no I recognize thats just a horrible delusion of mine, but hey, we all get one free don't we?

Hard to worry about implementation when we have so much free ram, that if they got a glimpse of 2023, 1970s scientists building ibm supercomputers would cry themselves to sleep knowing what we waste it on.

In managed languages like Python? Not at all. You can completely ignore the difference as your runtime takes care of that implementation detail for you.

In languages where you have to decide yourself where stuff is stored? Very important. Stack space is normally freed before (local variables) or after (results) returning from a function.

Tag-wise this would have been a "question" btw.

@Oktokolo It was actually just a question for affect, humor. Hence the self-depreciation.

Us python devs may not have static typing, but we haven't lost our sense of humor.

@Wisecrack Now that's unexpected.

@Oktokolo

try:

humor()

except RuntimeError:

print("shit I guess you're out of luck!.")

paaassssssssssssss

@Wisecrack Got an IndentationError.

@Oktokolo

try:

indentation()

except IdentationError:

print("this is definitely the one...")

In python, it doesn't really matter. It's hard to make performant code purely in python.

Both stack and heap are places to store data, but stack is faster due to cache locality. ie its just going to have a 2 byte offsets to reference data allocated in the stack vs 64 bit address to reference the heap memory that might live elsewhere.

I mean they are not that complicated.
I do alot reverse engineering and in assembler it is extremly obvious which is which.

Stack is good for stuff that is short-lived because there is no allocation overhead, but it's only for small(ish) data. Heap is good for any data, but has allocation overhead, so not for short-lived stuff such as in loops.

Consequence for SW design: avoid short-lived, large data. Move the allocation out and reuse the allocated memory in the short-lived path.

Also... "Us python devs may not have static typing," and it shows with the tagging.

@Wisecrack Nah, still get the IndentationError - right on the "indentation()" line. Do i need to add curlies around the try block or terminate the statement with a semicolon?

@Oktokolo that's the joke my friend. That's the joke.

@Wisecrack Nah, it says IndentationError 😇

@Oktokolo and worse I misspelled it.

@Fast-Nop good point. expanding on that stack allocation is merely incrementing the stack pointer RIP for x64 and free'ing it is decrementing the stack pointer.

Whereas for heap allocation is a syscall which is relatively expensive, requires kernel to look for free regions in the memory before being able to use it. That's why you hear about memory pooling to make it faster