4 ms·

There are no situations where it makes sense to say that lots of allocations are cheap and only cost a few instructions. If lots of allocations are happening w

There are no situations where it makes sense to say that lots of allocations are cheap and only cost a few instructions. If lots of allocations are happening without freeing, more memory will have to be mapped in anyway on top of the constant pointer bumping - which means that a single allocation of an array would make sense instead. If lots of allocations are happening with freeing, 'objects'/allocations will have to be moved around constantly to cater to the 'cheap' bump allocation. If lots of allocations are happening then all being freed uniformly at the same time, it makes no sense to use lots of allocations since one array allocation would be fine. Basically, making lots of tiny allocations marginally cheaper is a terrible strategy since it will always be a drag on performance since it is a naive and wasteful way to write software.

kragen 6y ago
> There are no situations where it makes sense to say that lots of allocations are cheap and only cost a few instructions. This is so trivially shown to be false that I suspect you are trolling. There is, for example, the situation I showed in https://news.ycombinator.com/item?id=26438596 https://news.ycombinator.com/item?id=26438596. Moreover, as gsg says, this is very generally true of pointer-bumping allocators in modern GCs; SBCL's GC isn't even all that modern.
- CyberDildonics 6y ago
  What you are talking about is the equivalent of adding 1 to the size of a C++ vector with a large capacity on each iteration of a loop. The memory has already been mapped in (through a blocking system call) and it is contiguous. The "allocation" here is just the same uniform increment in an unbroken span of memory already in the process without taking into anything that makes memory allocation problematic for performance. There is no point to the situation you described, it is a nonsense way to do something trivial. If that's what you want, allocate a single array. The fact remains that memory allocation is often huge low hanging fruit for optimization. If it was 'just a few instructions' this would not be true. Garbage collection does not change this. You can read endless threads about 'performance java' people taking about allocating all their memory when their program starts and never inside their loops. The reasons why have mostly been explained (system calls, heaps, copying in GCs, cache effects, TLB effects, etc.) though people have left out other nuances like mapped pages triggering interrupts on their first write to save time in the memory mapping call. I think it will probably help to look into this further, thinking memory allocation is bumping a pointer is a simplification that will confuse any optimization until you understand it and profile.
  - chrisseaton 6y ago
    > There is no point to the situation you described, it is a nonsense way to do something trivial. I mean... it's how real allocators work in real VMs, so it's not nonsense, is it?
    - CyberDildonics 6y ago
      I'm not even sure I understand what you are asking, do you think that memory allocation is always bumping a pointer a uniform amount with no memory being freed, no variance in allocation size and no interlaced lifetimes? You originally said that memory allocation was 'just a few instructions' when the reality is that it is complex and avoiding allocation is the first thing to do when optimizing software. Saying that memory allocation is simple and fast based on a scenario that should never happen because it's useless is a little silly. No, that is not how allocators work.
      - chrisseaton 6y ago
        > do you think that memory allocation is always bumping a pointer a uniform amount with no memory being freed, no variance in allocation size and no interlaced lifetimes? In modern language implementations with moving collectors allocation is literally what I've described in the fast path. Not theoretical. That's literally the instructions used. > You originally said that memory allocation was 'just a few instructions' Here it is in a real industrial compiler and garbage collector, for example. https://github.com/oracle/graal/blob/f9530b0948c58a66845e84ff400f29e5eae84fff/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/AllocationSnippets.java#L57-L71 https://github.com/oracle/graal/blob/f9530b0948c58a66845e84f... It's precisely as I've described.
        CyberDildonics 6y ago
        It is not at all. That's like someone looking at perfect weather, blowing up an air mattress on the beach and wondering why anyone would need a house. You are only on the 'fast path' when a single allocation of an array would have been much faster anyway. It isn't difficult to be 'fast' when accomplishing something trivial that would be even faster if done directly. Why do you keeping saying the same thing while ignoring freeing memory, different lifetimes and wildly different sizes of allocations (which are why memory allocators actually exist)? This idea that memory allocation is cheap is a blight on performance. Are you really allocating memory inside your hot loops and having it not show up when you profile?

kragen 6y ago

> There are no situations where it makes sense to say that lots of allocations are cheap and only cost a few instructions. This is so trivially shown to be false that I suspect you are trolling. There is, for example, the situation I showed in https://news.ycombinator.com/item?id=26438596 https://news.ycombinator.com/item?id=26438596. Moreover, as gsg says, this is very generally true of pointer-bumping allocators in modern GCs; SBCL's GC isn't even all that modern.

CyberDildonics 6y ago
What you are talking about is the equivalent of adding 1 to the size of a C++ vector with a large capacity on each iteration of a loop. The memory has already been mapped in (through a blocking system call) and it is contiguous. The "allocation" here is just the same uniform increment in an unbroken span of memory already in the process without taking into anything that makes memory allocation problematic for performance. There is no point to the situation you described, it is a nonsense way to do something trivial. If that's what you want, allocate a single array. The fact remains that memory allocation is often huge low hanging fruit for optimization. If it was 'just a few instructions' this would not be true. Garbage collection does not change this. You can read endless threads about 'performance java' people taking about allocating all their memory when their program starts and never inside their loops. The reasons why have mostly been explained (system calls, heaps, copying in GCs, cache effects, TLB effects, etc.) though people have left out other nuances like mapped pages triggering interrupts on their first write to save time in the memory mapping call. I think it will probably help to look into this further, thinking memory allocation is bumping a pointer is a simplification that will confuse any optimization until you understand it and profile.
- chrisseaton 6y ago
  > There is no point to the situation you described, it is a nonsense way to do something trivial. I mean... it's how real allocators work in real VMs, so it's not nonsense, is it?
  - CyberDildonics 6y ago
    I'm not even sure I understand what you are asking, do you think that memory allocation is always bumping a pointer a uniform amount with no memory being freed, no variance in allocation size and no interlaced lifetimes? You originally said that memory allocation was 'just a few instructions' when the reality is that it is complex and avoiding allocation is the first thing to do when optimizing software. Saying that memory allocation is simple and fast based on a scenario that should never happen because it's useless is a little silly. No, that is not how allocators work.
    - chrisseaton 6y ago
      > do you think that memory allocation is always bumping a pointer a uniform amount with no memory being freed, no variance in allocation size and no interlaced lifetimes? In modern language implementations with moving collectors allocation is literally what I've described in the fast path. Not theoretical. That's literally the instructions used. > You originally said that memory allocation was 'just a few instructions' Here it is in a real industrial compiler and garbage collector, for example. https://github.com/oracle/graal/blob/f9530b0948c58a66845e84ff400f29e5eae84fff/compiler/src/org.graalvm.compiler.replacements/src/org/graalvm/compiler/replacements/AllocationSnippets.java#L57-L71 https://github.com/oracle/graal/blob/f9530b0948c58a66845e84f... It's precisely as I've described.
      - CyberDildonics 6y ago
        It is not at all. That's like someone looking at perfect weather, blowing up an air mattress on the beach and wondering why anyone would need a house. You are only on the 'fast path' when a single allocation of an array would have been much faster anyway. It isn't difficult to be 'fast' when accomplishing something trivial that would be even faster if done directly. Why do you keeping saying the same thing while ignoring freeing memory, different lifetimes and wildly different sizes of allocations (which are why memory allocators actually exist)? This idea that memory allocation is cheap is a blight on performance. Are you really allocating memory inside your hot loops and having it not show up when you profile?