3 ms·

The benefit of malloc/free (or new/delete) is that you have control over your own memory layout to handle optimizations like cache alignment, keeping relevant d

The benefit of malloc/free (or new/delete) is that you have control over your own memory layout to handle optimizations like cache alignment, keeping relevant data contiguous, deferring pauses that would introduce latency and such.

pron 13y ago
Memory layout is a separate discussion. The kind of layout optimizations you're describing require work, and if you're willing to put in this work, you can do it in GCed environments as well (like the JVM, with finer-grained control coming in future versions). Otherwise, several/most of the JVM's GCs do a very good job of handling this for you. Objects that were allocated consecutively by the same thread will tend to be kept close together in memory.
- banachtarski 13y ago
  That's contiguity but alignment is a different thing. At a certain point though, the two things become one and the same. On the one hand, you could put in layout optimizations in a GC system. On the other hand, you can use things like shared_ptr and effectively write your own GC even. I guess the debate really isn't an A vs B thing. It's just a spectrum and deciding which side of the spectrum you want to start on.
  - pron 13y ago
    > you can use things like shared_ptr and effectively write your own GC even. This is hardly the case, especially on modern multi-core hardware. Writing a GC that works well in a concurrent environment is a huge undertaking. And unless your system is very simple, you'll often be better off with a good general-purpose GC. A shared_ptr introduces a lot of contention.
    - ori_b 13y ago
      The thing is that most garbage generated is thread local. In fact, depending on the program, it's likely that most of it follows a stack discipline, albeit one that's not delimited by function boundaries. A simple GC (or resettable arena allocator) can make use of this knowledge, and be quite a bit faster in those specific cases. It's hard to beat the man years of work in generic GC that works in all cases, but it's not that hard to beat it in specific situations when the application author knows the details of how the application will do the allocations. 99% of the time, writing your own custom allocation strategies is a waste of time. Sometimes, though, it can be a win, allowing you to allocate and free in a matter of tens of CPU cycles with no GC pauses at all.
      - lmm 13y ago
        >99% of the time, writing your own custom allocation strategies is a waste of time. Sometimes, though, it can be a win, allowing you to allocate and free in a matter of tens of CPU cycles with no GC pauses at all. Agreed, but again, if you're willing to put that effort in you can do it in a GCed language.

pron 13y ago

Memory layout is a separate discussion. The kind of layout optimizations you're describing require work, and if you're willing to put in this work, you can do it in GCed environments as well (like the JVM, with finer-grained control coming in future versions). Otherwise, several/most of the JVM's GCs do a very good job of handling this for you. Objects that were allocated consecutively by the same thread will tend to be kept close together in memory.

banachtarski 13y ago
That's contiguity but alignment is a different thing. At a certain point though, the two things become one and the same. On the one hand, you could put in layout optimizations in a GC system. On the other hand, you can use things like shared_ptr and effectively write your own GC even. I guess the debate really isn't an A vs B thing. It's just a spectrum and deciding which side of the spectrum you want to start on.
- pron 13y ago
  > you can use things like shared_ptr and effectively write your own GC even. This is hardly the case, especially on modern multi-core hardware. Writing a GC that works well in a concurrent environment is a huge undertaking. And unless your system is very simple, you'll often be better off with a good general-purpose GC. A shared_ptr introduces a lot of contention.
  - ori_b 13y ago
    The thing is that most garbage generated is thread local. In fact, depending on the program, it's likely that most of it follows a stack discipline, albeit one that's not delimited by function boundaries. A simple GC (or resettable arena allocator) can make use of this knowledge, and be quite a bit faster in those specific cases. It's hard to beat the man years of work in generic GC that works in all cases, but it's not that hard to beat it in specific situations when the application author knows the details of how the application will do the allocations. 99% of the time, writing your own custom allocation strategies is a waste of time. Sometimes, though, it can be a win, allowing you to allocate and free in a matter of tens of CPU cycles with no GC pauses at all.
    - lmm 13y ago
      >99% of the time, writing your own custom allocation strategies is a waste of time. Sometimes, though, it can be a win, allowing you to allocate and free in a matter of tens of CPU cycles with no GC pauses at all. Agreed, but again, if you're willing to put that effort in you can do it in a GCed language.