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

Malloc Challenge

vicsydev.blogspot.com

Post reply on HN
Print view View original

11–20 of 109 posts

Re: Malloc Challenge

#11

Post by MichaelMoser123 »

jwatte wrote: post #9

How about: mmap() a few terabytes of virtual space let malloc() be pointer addition and let free() be a no-op?

Except if the program needs to run for a non trivial duration or you need many instances of it at the same time/run at the same time as other processes.

Still you have obstacks where free is a no op - here you allocate off the stack (assuming that you dont need to store pointers after you are done). Ngnix and apache allocate a chunk of memory per connection and free it all when the connection is finished - but this results in high memory fragmentation, also this is not so good if connections take a long time.

Re: Malloc Challenge

#14

Post by codr4life »

morio123 wrote: post #7

What's the incentive? Credits? Give me a break. It's fairly easy to beat the given examples but in the end heap management is heavily dependent on application, client code, platform, hardware and many other criteria. It's a very complex problem space and what matters here is how existing important code behaves and continues to behave given that existing code has most likely made assumptions how the heap is managed. g…

Pushing the state of the art in application level memory management? Too lofty? Come on, it's fun :)

Re: Malloc Challenge

#15

Post by codr4life »

MichaelMoser123 wrote: post #10
codr4life wrote: post #5

Earlier quoted context omitted.

Good call, writing C/C++ without having a grip on memory allocation is a recipe for exactly the kind of disaster we're in right now :)

Depends on the domain - i suspect that this question would cut off qualified application programmers who are not perfectly familiar with lower level/infrastructure code.

Not if they're writing C/C++; it doesn't really matter how hard you try to hide memory management when the whole language is designed around memory and pointers. What kind of programmer is that, anyway? Who can only program specific api's, as long as they don't touch the wrong parts of the language.

Re: Malloc Challenge

#16

Post by vvanders »

MichaelMoser123 wrote: post #10
codr4life wrote: post #5

Earlier quoted context omitted.

Good call, writing C/C++ without having a grip on memory allocation is a recipe for exactly the kind of disaster we're in right now :)

Depends on the domain - i suspect that this question would cut off qualified application programmers who are not perfectly familiar with lower level/infrastructure code.

I would argue that except in the case of legacy software there's no reason to be using C/C++ for something that doesn't care about performance or memory overhead.

Even then it's useful to know how sentinel values and other features work if you don't dig into the performance aspect.

Re: Malloc Challenge

#17

Post by codr4life »

morio123 wrote: post #7

What's the incentive? Credits? Give me a break. It's fairly easy to beat the given examples but in the end heap management is heavily dependent on application, client code, platform, hardware and many other criteria. It's a very complex problem space and what matters here is how existing important code behaves and continues to behave given that existing code has most likely made assumptions how the heap is managed. g…

Further, the complexity and need for flexibility is exactly the problems that I'm trying to deal with here. That's why the challenge encourages splitting the allocator up in Unix-like pieces and stacking them to get the desired features.

Re: Malloc Challenge

#18

Post by codr4life »

jwatte wrote: post #9

How about: mmap() a few terabytes of virtual space let malloc() be pointer addition and let free() be a no-op?

Sure, the idea is that you can have several allocators around for different purposes. One allocator per http handler that reserves enough memory and resets the pointer between request makes the idea more feasible than insisting on the centralized general purpose perspective.

Re: Malloc Challenge

#19

Post by userbinator »

Before I read the article or the comments I thought it would be about rewriting code to not use dynamic allocation, which is IMHO a far more interesting (and challenging to some) exercise. Contrary to common expectations, it often doesn't mean e.g. restricting the lengths of inputs, and can result in simpler, more efficient, and less buggy code. From my experience it is usually those with a background in higher-level languages who overuse malloc().
Post reply on HN