Readit NewsBut it would be a pretty good way to discredit me.
I am pretty sure that "мне по хрену" is a parody on "мне по плечу" (literally "fits my shoulder" but means "doable to me / within my powers"). Russian people coin new expressions with such witticisms all the time.
So, reproducing the same parody in English, one could say "fits my wiener". Horseradish here being an obscenity-avoiding euphemism for c*ck (like English "wiener"), not the plant (just like all the sausages and cucumbers in the other languages).
As I native, I would assume that "мне по хрену"/"мне похрен" is an euphemism of the more rough variant "мне похуй" (it is up to my dick, same height as my dick).
> Instead of calling malloc 1000 times to allocate 1000 small pieces (like 16 bytes sized each), malloc is called once and then all the small pieces are carved from the big memory block.
No one who has any idea about performance is saying lots of memory allocations are ok. It sounds like what you are doing though is allocating arrays but then using them for 'arena allocators' when you could just use them directly and use indices for ordering if you need that.
> The arena allocators are also popular in game development. Memory is allocated from the arena allocator during frame processing (16 ms), and all this allocated memory is deallocated at once at the end of the frame.
I would ask why the memory needs to be deallocated at the end of each frame. A C++ vector can be cleared without releasing its capacity. What you really want is to have all the memory that you need allocated once so it can be reused over and over easily. There is no reason to involve an allocator on a frame to frame basis of a video game unless you go over what you already thought you would need.
If you have 'millions' of 'memory managers', why not just use a few big arrays? It really seems like an over complication of a problem that doesn't need to be difficult. I'm surprised no one would take the time to clean that out if there are terabytes of memory used and multiple days for single program runs.
I think you are way off track. The point here is that whatever you are doing is unnecessary. You don't need an arena and probably don't need a linked list. You are using an arena allocator as an array already if you are never freeing anything. Just make fewer large allocations.
> does not reuse memory for simplicity (it allocates only forward, like a stack)
First, stacks can shrink when items are popped off. Second, if you are using an 'arena allocator' and a linked list on top of it when you could actually just allocate memory into an array are you really gaining simplicity? You are purposely not reusing memory and have a program using terabytes of memory and running for multiple days. Is that really simplicity?
Pretty much everything you have said so far is an enormous red flag, but the good news is that there are probably ways where you can use orders of magnitude less time and memory while making the program more straight forward.
The arena allocators are also popular in game development. Memory is allocated from the arena allocator during frame processing (16 ms), and all this allocated memory is deallocated at once at the end of the frame.
I think you are way off track. The point here is that whatever you are doing is unnecessary. You don't need an arena and probably don't need a linked list. You are using an arena allocator as an array already if you are never freeing anything. Just make fewer large allocations.
> does not reuse memory for simplicity (it allocates only forward, like a stack)
First, stacks can shrink when items are popped off. Second, if you are using an 'arena allocator' and a linked list on top of it when you could actually just allocate memory into an array are you really gaining simplicity? You are purposely not reusing memory and have a program using terabytes of memory and running for multiple days. Is that really simplicity?
Pretty much everything you have said so far is an enormous red flag, but the good news is that there are probably ways where you can use orders of magnitude less time and memory while making the program more straight forward.
If you need a linked list, use an array with indices and you can cut the size in half if you don't need 64 bit integers. If it has to be enormous, make a linked list of arrays for better locality.
Which means that using array over this arena would waste more memory (due to array resizing) than linked list. When array is resized, the unused memory from the old array will stay unused until the whole arena is deallocated.
That means linked lists are increasingly relegated to toy problems and unusual domains. They're no longer really a practical tool to organize data - it would be better in many cases to use an array and copy the entire contents on insert.
I agree that linked lists could be optimized, but usually they are not the worst offender. The biggest gains in performance usually happen when an accidental O(n^2) slowdown is replaced with a correct n*log(n) version.
If all our electricity came from renewable power then sure, I agree. But most does not. So, this seems like putting the cart before the horse. Why not focus on improving how we generate electricity before we tear out all the gas?
My undergrad degree was electrical engineering. Basically, it seems visible to everyday people, and theatrical, but not that helpful or practical. Happy to hear how I'm wrong. I am certainly very concerned about the environment.
https://www.youtube.com/watch?v=_yMMTVVJI4c