Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory Allocation

samwho.dev

Post reply on HN
Print view View original

31–40 of 182 posts

Re: Memory Allocation

#31

Post by williamcotton »

samwho wrote: post #23
davidgrenier wrote: post #21

Earlier quoted context omitted.

Oh another thing, I'm not a fan of the premise: "As a general-purpose memory allocator, though, we can't get away with having no free implementation." I have a belief that the future of software are short-lived programs that never free memory. Programs allocate and terminate. Short-lived program communicate with each other via blocking CSP-style channels (see Reppy's Concurrent Programming in ML). If you could also e…

It's funny, I saw and retweeted this while writing this post: https://twitter.com/samwhoo/status/1650572915770036225?s=20 Not sure the future you describe is where we'll end up, haven't given it a huge amount of thought. Would be interesting to see, though. Things like web servers could probably get away with doing some sort of arena allocation per request (I'd be surprised if some don't already do this).

Apache does this! And I do this in my own C web framework:

https://github.com/williamcotton/express-c/blob/master/deps/...

Re: Memory Allocation

#32

Post by samwho »

ozfive wrote: post #30
junon wrote: post #27

Seems to be a bug on the first interactive graph, at least for me. Unless I'm misunderstanding the point of the graph, `malloc(7)` only allocates 2 bytes.

I came here to see if anyone else noticed this and am confirming that there is a bug in the first slider on malloc(7). Indeed it only allocates two bytes instead of seven.

Good spot! Thank you. Fix on its way out now. :)

Re: Memory Allocation

#33

Post by saagarjha »

davidgrenier wrote: post #21
samwho wrote: post #17

Earlier quoted context omitted.

Well shit. I think you're right.

Oh another thing, I'm not a fan of the premise: "As a general-purpose memory allocator, though, we can't get away with having no free implementation." I have a belief that the future of software are short-lived programs that never free memory. Programs allocate and terminate. Short-lived program communicate with each other via blocking CSP-style channels (see Reppy's Concurrent Programming in ML). If you could also e…

It's not general purpose, and lots of programs that were designed to be short-lived often end up not being so in the future. People used to point at compilers as a typical example of this kind of thing, well, now we have compilers as libraries sitting resident in every popular developer tool.

Re: Memory Allocation

#34

Post by carlmr »

junon wrote: post #27

Seems to be a bug on the first interactive graph, at least for me. Unless I'm misunderstanding the point of the graph, `malloc(7)` only allocates 2 bytes.

True, it might be cut-off from screen?

Re: Memory Allocation

#35

Post by vidarh »

davidgrenier wrote: post #21
samwho wrote: post #17

Earlier quoted context omitted.

Well shit. I think you're right.

Oh another thing, I'm not a fan of the premise: "As a general-purpose memory allocator, though, we can't get away with having no free implementation." I have a belief that the future of software are short-lived programs that never free memory. Programs allocate and terminate. Short-lived program communicate with each other via blocking CSP-style channels (see Reppy's Concurrent Programming in ML). If you could also e…

My first large scale web application was a webmail service built in C++ (!) where I early on decided we'd ditch nearly all freeing of memory, as it was running as a CGI, and it was much faster to just let the OS free memory on termination. The exception was for any particularly large buffers. Coupled with statically linking it, it reduced the overhead sufficiently that running it as a CGI performed well enough to save us the massive pain of guaranteeing sufficient isolation and ensuring we were free of memory leaks.

Especially in a request/reply style environment, long running application servers is largely a workaround for high startup costs, and it's only a "bad idea" in the instances where removing that high startup cost is too difficult to be practical. Overall I love avoiding long running programs.

Re: Memory Allocation

#36

Post by samwho »

carlmr wrote: post #34
junon wrote: post #27

Seems to be a bug on the first interactive graph, at least for me. Unless I'm misunderstanding the point of the graph, `malloc(7)` only allocates 2 bytes.

True, it might be cut-off from screen?

Nah, I just failed at basic arithmetic :D

I wrote this:
Instead of this:

Re: Memory Allocation

#39

Post by samwho »

junon wrote: post #38

This is really, really well done. Also, the allocator playground[0] is really cool. Will be my go-to when teaching this topic moving forward :) [0] https://samwho.dev/allocator-playground/

Thanks so much, I really appreciate it.

I'm glad you like the playground. If you don't mind me asking, what/where/how do you teach? I was actually hoping to get the attention of educators with this tool to see if it would make sense in, e.g., undergrad CS courses.

Re: Memory Allocation

#40

Post by RamiAwar »

I love this! I wish it existed back when I was writing my first memory allocators in university or when building a custom EntityComponentSystem implementation.

I'd love to also see applications of custom memory allocations. I know about usecases in building game engines and the importance of hitting cache there, but I'm not sure where else in the world this would be as useful.

Post reply on HN