Live data from Hacker News

Malloc Challenge

vicsydev.blogspot.com

101–109 of 109 posts

Re: Malloc Challenge

#101

Earlier quoted context omitted.

Looking at the implementation of libc4life, I think it's full of gcc-isms. C4DEFER() is this: #define _C4DEFER(code, _def) \ void _def() code; \ bool _def_trigger __attribute__((cleanup(_def))) \ #define C4DEFER(code) \ _C4DEFER(code, C4GSYM(def)) \ So, nested functions and gcc attributes. Nested functions awesome, but they're a gcc extension, and only supported on some architectures anyway, and AFAIK only work if yo…

I had to draw a line somewhere, and C99 with GNU extensions is where it is. Cleanup attributes and anonymous functions are just too useful to leave behind. And since I'm using clang to develop this, I'm pretty sure it supports nested functions just fine.

Hm. Sounds like they added them --- nested functions certainly weren't supported the last time I looked (because, as you say, they're far too useful, and I hated having to give them up).

Have you had any reports about problems on, e.g., OpenBSD, related to needing an executable stack?

Re: Malloc Challenge

#102

Earlier quoted context omitted.

Doesn't the benchmark also just allocate and then immediately free? I think I could specialise for that particular use pattern and make it very fast just for the benchmarks. Will that not work for some reason? A good benchmark might be a replayed set of allocate and free operations from a large real application.

It does, but with random sizes. If think you have a way to make that run faster than the provided implementations, then please show us.

Challenge accepted (if I can find the free time)!

Re: Malloc Challenge

#103

Earlier quoted context omitted.

I had to draw a line somewhere, and C99 with GNU extensions is where it is. Cleanup attributes and anonymous functions are just too useful to leave behind. And since I'm using clang to develop this, I'm pretty sure it supports nested functions just fine.

Hm. Sounds like they added them --- nested functions certainly weren't supported the last time I looked (because, as you say, they're far too useful, and I hated having to give them up). Have you had any reports about problems on, e.g., OpenBSD, related to needing an executable stack?

Could be, it's moving fast. Once I realized I could use nested functions to provide anonymous functions and deferred actions with decent syntax in a semi-standardized way, I was hooked :)

Nothing, but I seldom hang around in the BSD crowd these days.

Re: Malloc Challenge

#104

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…

Any tips or links on how to do this?

Re: Malloc Challenge

#105
post #22
post #9

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

Somebody out there is doing this in production. I guarantee it.

There was a console game (I want to say Sega CD? CD32? or Atari Jaguar?) that reset whole system between level loads because it was cheaper than freeing memory.

Re: Malloc Challenge

#106

I recall reading in the last year or two a recount of how a game developer got their PS3 engine to run at 30 or 60Hz framerate by aggressive triple-buffering of their scenes. One of the interesting bits about the article was their memory allocation scheme. Each game frame they'd allocate a single huge memory pool and then allocate from it by simply incrementing a pointer into the pool. I think this is what you descri…

http://www.gdcvault.com/play/1022186/Parallelizing-the-Naugh... This might be the talk you're referring to.

This is it! Great presentation, thought provoking.

Re: Malloc Challenge

#108
post #52

I recall reading in the last year or two a recount of how a game developer got their PS3 engine to run at 30 or 60Hz framerate by aggressive triple-buffering of their scenes. One of the interesting bits about the article was their memory allocation scheme. Each game frame they'd allocate a single huge memory pool and then allocate from it by simply incrementing a pointer into the pool. I think this is what you descri…

You are describing an arena allocator. Slab is more like a set of free lists per object size.

The GNU people call this "obstacks"; they are in the "iberty" library. (So named because it spells -liberty on a Unixy linker command line).

https://gcc.gnu.org/onlinedocs/libiberty/Obstacks.html

Obstacks provide objects by drawing them from a linear piece of memory incrementally. Additionally, this is treated like a stack: you can free an object, but that also pops all objects allocated since that one.

Re: Malloc Challenge

#109

Earlier quoted context omitted.

Long term maintanance is easier with safer languages.

Everything is easier in safer languages, far from everything is possible.

What do you mean with everything? Because we have seen languages such as D (without GC) and Rust that offer the same possibilities and performance, yet much less opportunity to blow your hand off by accident.
Post reply on HN