from the 640k-of-small-arrays-ought-to-be-enough-for-anyone dept.
Techno-optimist and a free-speech advocate Daniel Lemire asks:
In an earlier blog post, I reported that the memory usage of a small byte array in Java (e.g., an array containing 4 bytes) was about 24 bytes. In other words: allocating small blocks of memory has substantial overhead.
What happens in C++?
To find out, I can try to allocate one million 4-byte arrays and look at the total memory usage of the process. Of course, the memory usage of the process will include some overhead unrelated to the 4-byte arrays, but we expect that such overhead will be relatively small.
Results are: GCC 8, Linux x86 - 32 bytes, LLVM 14, Apple aarch64 - 16 bytes. GitHub link to code he used.
Previously: Beyond C++: The promise of Rust, Carbon, and Cppfront
Related Stories
In some ways, C and C++ run the world. You'd never know it from all the hype about other programming languages, such as Python and Go, but the vast majority of high-performance mass-market desktop applications and operating systems are written in C++, and the vast majority of embedded applications are written in C. We're not talking about smartphone apps or web applications: these have special languages, such as Java and Kotlin for Android and Objective-C and Swift for iOS. They only use C/C++ for inner loops that have a crying need for speed, and for libraries shared across operating systems.
C and C++ have dominated systems programming for so long, it's difficult to imagine them being displaced. Yet many experts are saying it is time for them to go, and for programmers to embrace better alternatives. Microsoft Azure CTO Mark Russinovich recently made waves when he suggested that C and C++ developers should move to Rust instead. "The industry should declare those languages as deprecated," Russinovich tweeted.
Many developers are exploring Rust as a production-ready alternative to C/C++, and there are other options on the horizon. In this article, we'll consider the merits and readiness of the three most cited C/C++ language alternatives: Rust, Carbon, and cppfront. First, let's take a look back through the history and some of the pain points of C/C++.
(Score: 4, Informative) by istartedi on Monday December 19, @12:30AM (1 child)
People that have been writing C for a long time know about this--it tends to be the implementation of malloc and/or the operating system that requires overhead and if you know you need a lot of little dynamic objects you roll your own mempool. The GNU people even have a generic library that goes by the very name so it leads to the question "why isn't malloc just using a mempool" and the answer is that the standard library would have to have something more than malloc, such as poolmalloc(pool, bytes) or something that specifies which pool you want and... the C standards people didn't want to go that way so you have to roll your own if this is an issue. In general avoid lots of little dynamic objects if you can, but if it's a game full of tiny critters or something that get created and destroyed all the time *and* memory performance is critical then custom mempools have alwasy been the answer AFAIK; but there's so much goht-dang memory on systems these days it's generally not an issue. If you're slow, profile memory as well as cycles though and *then* optimize. Most people never need to do it.
Appended to the end of comments you post. Max: 120 chars.
(Score: 2) by JoeMerchant on Monday December 19, @02:44AM
> it's a game full of tiny critters or something that get created and destroyed all the time
I made one of these back around 2004, was super impressed with how absolutely rock solid malloc/free was when you used it correctly, that sim would run for months constantly creating and destroying little 100ish byte objects (sizes varied from 6 to 240 on most objects), the sim was boxed so it never used more than about 85% of available memory and it just chugged along without ever choking on itself. I also used this sim as a test comparison between cygwin and native Linux, was super impressed with cygwin performance, coming in over 98% of the speed of native Linux (as long as I didn't let Windows update itself or anything else silly like that.)
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 2) by gnuman on Monday December 19, @02:39AM (1 child)
or not really. If you are allocating 4 bytes, first, you should consider that keeping track of your allocation is 8 bytes on modern systems. In that case, you probably should re-evaluate your algorithm.
Anyway.....
(Score: 1) by shrewdsheep on Monday December 19, @08:31AM
I would expect 16: address + length
(Score: 3, Funny) by Rosco P. Coltrane on Monday December 19, @02:39AM (5 children)
Who the hell allocates memory these days? You make an array class, then a extended array superclass, then you make as many instances as you need, the memory is magically allocated perfectly and the garbage collector takes care of freeing it and gathering the splinters into a magically efficient large block allocation. then you throw more RAM modules at the machine when it starts swapping.
Get with the times man...
(Score: 2) by JoeMerchant on Monday December 19, @02:48AM (1 child)
>the garbage collector takes care of freeing it and gathering the splinters into a magically efficient large block allocation
Yeah, except when it doesn't. See: Micropython on the RasPi Pico while using threads.
Україна досі не є частиною Росії Слава Україні🌻 https://news.stanford.edu/2023/02/17/will-russia-ukraine-war-end
(Score: 0) by Anonymous Coward on Monday December 19, @05:28AM
Whoosh...
(Score: 4, Funny) by driverless on Monday December 19, @08:23AM (1 child)
then you drop them into cells of an Excel spreadsheet which you embed in a Word document and email to the other person whose secretary prints it out for him and then OCRs it back again with only a small percentage of the data lost.
What were we talking about again?
(Score: 2, Informative) by shrewdsheep on Monday December 19, @08:35AM
Well, you have to give them that they are following best security practice.
(Score: 2) by legont on Tuesday December 20, @07:16AM
Not so fast, bro. In the end you always have to research how the garbage collector works and then rewrite your code in such a way that garbage collection is triggered at precise times such as low trading execution volume. It's doable but way harder than to allocate memory the old fasion way.
How do you go about hacking garbage collector exactly? Well, you used to hire a couple of Russians, but I don't know if it works any more given the political situation.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 3, Insightful) by maxwell demon on Monday December 19, @05:05AM (3 children)
The memory usage of a 4 byte array in C or C++ is exactly 4 bytes. It may additionally require up to three bytes of padding if the array is of a type with corresponding alignment.
Now an allocation of 4 bytes takes much more memory. But that's unrelated to the size of an array, that's allocation overhead. But then, if you have many small allocations in C or C++, there's probably something wrong with your code.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Monday December 19, @02:18PM (2 children)
No, both the C and C++ standards are very clear that arrays do NOT have any padding.
(Score: 3, Informative) by VLM on Monday December 19, @04:27PM
This whole thing comes up in arrays of serialization stuff for network packets and things like that.
A struct with a char and an int would sizeof() to 8 to align
The identical struct with __attribute__((packed)); would sizeof to exactly 5 bytes to fit in a network packet or whatever serialization nonsense. There's also pragma pack.
I'm far too lazy to look up if this is a C standard, a new C standard, or a GCC thing.
ESR has a zillion page long web page about the joys of structure packing.
http://www.catb.org/esr/structure-packing/ [catb.org]
Its one of those C things where if you know what you're doing you can write code that's as fast as hand coded assembly, but if you aren't an expert you can shoot your own foot as fast as hand coded assembly.
(Score: 2) by maxwell demon on Monday December 19, @05:37PM
There is no padding between the elements of an array. But there may be padding to align the complete array.
For example, on a system where short has size and alignment 2, the array short a[2] has size 4 and alignment 2, and therefore may need one padding byte in order to align it on an even address.
In particular, given
on such a system you'll have sizeof(X) = 1 but sizeof(Y) = 6 which shows the single byte padding required for the array in this case.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Informative) by legont on Monday December 19, @05:17AM (2 children)
C allocates the exact number of bytes asked (with whatever the OS minimum chunk) plus the length of the allocated block (again whatever the OS minimum) just to the left of the data. BTW, that's how free knows how much memory to free.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.
(Score: 3, Interesting) by maxwell demon on Monday December 19, @05:45PM (1 child)
Actually C typically allocates a multiple of the largest alignment of any type, even if you requested a non-multiple size, which means it often allocates a bit more than you requested. This is because the memory returned by malloc must be correctly aligned for any type that fits within the requested size, and the easiest way to guarantee that is to make all allocations a multiple of the maximum alignment.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by legont on Tuesday December 20, @07:08AM
Your lingo is likely more correct, but that's exactly what I meant. C would allocate "maximum alignment multiple" for the 4 bytes plus the length of it to the left of the returned pointer.
"Wealth is the relentless enemy of understanding" - John Kenneth Galbraith.