4 ms·

> it makes the execution times of your binary extremely unstable and high-variance. Not necessarily, it depends on your allocation patterns. The same can be sa

by pg314 10y ago

> it makes the execution times of your binary extremely unstable and high-variance. Not necessarily, it depends on your allocation patterns. The same can be said for using malloc. > Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach Ditto for malloc. > with manual management, you can get real and high performance. Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects. You keep a free list of Point objects that you can recycle. If you need a Point, you first see if there are any in the free list. If so, you pop the first one off the list and reuse it. Otherwise you allocate a new one. When you're done with a Point, you push it on the free list.

jstimpfle 10y ago
>> Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach > Ditto for malloc. malloc != manual management > Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects... But that's not using a GC. It's manual memory management.
- buzzybee 10y ago
  That's aggressively missing the point. If you design the program architecture around manual memory techniques, the runtimes are stable even in a GC. If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable.
  - jstimpfle 10y ago
    But my point was simply that you can't defend GC by contrasting to manual management, if you do manual management. > If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable. First, where did I say "use malloc willy-nilly"? Second, do you have experience with that? I haven't much, but I haven't heard your claim before. Of course "willy-nilly" should not be done with real-time constraints. But I have written a substantial algorithmic program (no RT constraints) in that style when I didn't know better, and it was very well performing. (probably glibc's malloc was optimized for my allocation patterns). The main problem I see with that style is that each malloc has memory overhead, and that it leads to unmaintainable code.
    - Kenji 10y ago
      Actually, to address realtime constraints... In my job, I work on systems with realtime constraints and even in less critical parts (latency of ~100 microseconds is still acceptable) we had to eliminate all malloc calls. Mostly because malloc on our platform essentially acquires one big lock for memory operations and if some other process has that lock, you get nasty delays or even priority inversions. Allocate a big chunk beforehand, preferrably in the form of ring buffers, and then operate on these if you need precise timing and performance.
      - jstimpfle 10y ago
        ... or use a version of malloc on that preallocated thread-local chunk. At least if the only problem is locking overhead.

by pg314 10y ago

jstimpfle 10y ago

>> Not to mention, it has no idea how your program uses memory, such that it is bound to use a generic approach > Ditto for malloc. malloc != manual management > Using a GC does not mean you can't manually manage allocations. E.g. say you are allocating and deallocating a lot of Point objects... But that's not using a GC. It's manual memory management.

buzzybee 10y ago
That's aggressively missing the point. If you design the program architecture around manual memory techniques, the runtimes are stable even in a GC. If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable.
- jstimpfle 10y ago
  But my point was simply that you can't defend GC by contrasting to manual management, if you do manual management. > If you use malloc willy-nilly throughout core algorithms, your runtimes become unpredictable. First, where did I say "use malloc willy-nilly"? Second, do you have experience with that? I haven't much, but I haven't heard your claim before. Of course "willy-nilly" should not be done with real-time constraints. But I have written a substantial algorithmic program (no RT constraints) in that style when I didn't know better, and it was very well performing. (probably glibc's malloc was optimized for my allocation patterns). The main problem I see with that style is that each malloc has memory overhead, and that it leads to unmaintainable code.
  - Kenji 10y ago
    Actually, to address realtime constraints... In my job, I work on systems with realtime constraints and even in less critical parts (latency of ~100 microseconds is still acceptable) we had to eliminate all malloc calls. Mostly because malloc on our platform essentially acquires one big lock for memory operations and if some other process has that lock, you get nasty delays or even priority inversions. Allocate a big chunk beforehand, preferrably in the form of ring buffers, and then operate on these if you need precise timing and performance.
    - jstimpfle 10y ago
      ... or use a version of malloc on that preallocated thread-local chunk. At least if the only problem is locking overhead.