>https://microsoft.github.io/mimalloc/bench.html>https://www.phoronix.com/news/Pogocache-1.2-Released
Because the clanker does it for me
why would I use malloc at all?
>>109935658because you want a block of free heap memory. duuuh
I doubt that it performs better than jemalloc
>>109935539whatever my toolchain does by default is fast enough for me
>>109935999That doesn't make any sense. The memory is free until you malloc. It only becomes free again when you free it.
I dont use malloc. What is the use case for allocating an arbitrary amount of memory? The max size should be known or else your code logic is just broken, make an array and the compiler takes care of the rest
>>109935539Because I need global coherence so that memory is guaranteed to be returned to the OS in short order, and I'm not some OOP babby who can't into bulk operations or domain specific allocation strategies so I barely ever call malloc making speed completely irrelevant.
>>109935539Because if I need an optimized malloc version then I'm doing something wrong. MALLOC SHOULD NOT BE OPTIMIZED, IT'S YOU WHO SHOULD OPTIMIZE THE MEMORY ALLOCATIONS.malloc is a shitty interface for an allocator IT REQUIRES BOOKKEEPING SOME DATA ABOUT THE ALLOCATED SEGMENT and because of that it wastes memory.
>>109936539>make image editorhow much memory do you allocate?
>>1099366016 trillion. predictable behavior across all machines.
>>109936601Whatever is in the header. Variable length arrays are what you want to use instead of malloc
Can I program in c without any allocation at all?
>>109936810yeah, 6 trillion should be enough for evrSegmentation fault (core dumped)
>>109936867>For best performance in C++ programs, it is also recommended to override the global new and delete operators. For convenience, mimalloc provides mimalloc-new-delete.h which does this for you -- just include it in a single(!) source file in your project. In C++, mimalloc also provides the mi_stl_allocator struct which implements the std::allocator interface.>#include "mimalloc-new-delete.h" once in main.cpp> new Foo(); >std::vector>std::unordered_map>make_unique / make_shared>mimalloc takes over instead of your default allocatorSo it's not just for mi_malloc and mi_free calls but takes over all heap operations
>>109936867>Variable length arraysThese are deprecated, chud.
Because I use hardened_malloc instead.
>>109936943No sane compiler allocates variable length arrays on the heap
>>109936539>want to construct struct>want to use said struct elsewhere>want to clean up said struct after you're done with it
>>109935539The kinds of programmes I write tend to use bump allocators over memory handed to me by mmap, dunno when I last used malloc.Thus: usecase?
>>109937082std::unique_ptr (if lifetime is determined by one object)std::shared_ptr/weak_ptr (if lifetime is determined by multiple objects)
>>109937098in Cin C++ you'd use a class, not a struct
>>109937090malloc is a relic from when UNIX processes had a single break growing towards the stack, so they needed centralized memory allocation infrastructure in libc. mmap effectively renders malloc pointless except as a quick and dirty prototyping tool. Only "people" producing slOOP care about malloc performance.
>>109937104What kind of class are you talking about? because a C++ class is just a struct with all members public by default. And you'd still use smart pointers regardless.
>>109936881must be. niggas doing safety-critical embedded stuff are basically banned from allocating.
>>109937130>Only "people" producing slOOP care about malloc performance.I don't think they care about that neither
>>109937162I have the displeasure of dealing with them from the libc side and I promise you they care a lot, because they believe it will fix the performance of their retarded architecture.
>>109937130(s)brk is a relic from those times, malloc itself is useful if you have lots of objects with individual lifetimes.Or, alternatively, you can use malloc to allocate the original arena, it's not meaningfully slower.But that's precisely something I try to avoid, and even then, you're better off using C++/Rust with their managed pointers at that point.
>>109937137Oh, but you're allowed to allocate a static array and then hand out chunks from that;)Provided that handing out never appears in any unbounded loop or in any recursive chain... (which, more often than not, are disallowed to begin with)
>>109936411No.The memory belongs to a rabid naegro that tries to bite your hand whenever you try to touch the memory.Calling malloc breaks the niegro's legs so you can take the memory and use it.Calling free throws the memory back to the noegro like giving scraps of bread to a stray mutt.
>>109937194Why would you use malloc for that? mmap yourself some memory and dole that out, or if you might need a lot of contiguous memory, mmap yourself a shitton of address space and extend the RW mapping further into it when needed. Are you allocating things of a constant size? Great, use a bitmap to keep track of free slots in a minuscule fraction of the memory overhead and time malloc takes to sift through bins or freelists or thread-local caches or whatever other bullshit trick it's employing to serve its overly generic memory management interface.Testing something out real quick and don't give a shit? Fine, use malloc.Thinking about object lifetimes? Smart pointers? Stop. Get some help.
>>109935999I ask my arena allocator built around mmap to give me that
>>109937217>Calling free throws the memory back to the noegroNo, there's not guarantee that calling free will throw back the memory to the negroe
>>109937204Can you post a repo or some source code/project that does this well?Programming just using the stack is difficult when you have to load mbs of data without much parallelism
>>109936943Just link with -lgc you newb. Problem solved.
>>109937513Not really, most of that stuff, certainly what I work with, is proprietary.Sure, but you don't really dynamically load data when doing embedded, all the data you could have is either already on ROM or has a known bounded size, in which case you can just declare a static array.
>>109935539because rust+snmalloc is the super combo (unless something new came out in the last 18 months).mimalloc is still good enough though.
>>109935539When I want a fast malloc I implement my own.
>>109935539for me, it's calloc(3)
>>109936881Sure, just use fixed size arrays instead of pointers to dynamic memory.Might not work well for all use cases out there, but works just fine for many.
>>109935539Solution to a problem data-oriented programming doesn't have.
