Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why does calloc exist?

vorpus.org

Post reply on HN
Print view View original

71–80 of 141 posts

Re: Why does calloc exist?

#71

Post by Manishearth »

caf wrote: post #64
Manishearth wrote: post #54

I've always been surprised that memset is usually just a nonmagical for loop. I used to expect that the OS does things to magically make it faster (running lazily, etc).

CPUs are pretty great at running nonmagical for loops, so you'd have be zeroing a pretty giant block of memory before it made sense to get the OS involved at all.

Of course :) But the OS could get involved for larger blocks of memory.

Also, I wonder if zeroing large chunks of memory would be faster to do in kernel space using real addresses. You can avoid the multiple real memory lookups involved in a single virtual write.

(Of course, we already avoid those often, but it could be useful to avoid entirely. Not sure what the tradeoffs are here)

Re: Why does calloc exist?

#72

Post by kr7 »

IgorPartola wrote: post #70

I don't get it. The two behaviors are completely orthogonal. Why can't I have a malloc() that does lazy copy-on-write for large arrays and why can't I have an error checking malloc() and why can't I have a calloc() that allocates the memory up front and doesn't zero it out? I get the "it's historic" argument, but this seems like a silly distinction. Sounds like what you want to do practically is basically just make y…

> Why can't I have a malloc() that does lazy copy-on-write for large array

malloc will generally do lazy copy-on-write above a certain limit; it was 128kb for glibc last time I checked.

> why can't I have an error checking malloc()

reallocarray is becoming the de-facto standard for that.

> why can't I have a calloc() that allocates the memory up front and doesn't zero it out?

Er, malloc?

Re: Why does calloc exist?

#73

Post by caf »

Manishearth wrote: post #71
caf wrote: post #64

Earlier quoted context omitted.

CPUs are pretty great at running nonmagical for loops, so you'd have be zeroing a pretty giant block of memory before it made sense to get the OS involved at all.

Of course :) But the OS could get involved for larger blocks of memory. Also, I wonder if zeroing large chunks of memory would be faster to do in kernel space using real addresses. You can avoid the multiple real memory lookups involved in a single virtual write. (Of course, we already avoid those often, but it could be useful to avoid entirely. Not sure what the tradeoffs are here)

Paging is still enabled in kernel mode, the kernel uses virtual addresses.

(The kernel's linear mapping of physical memory can take advantage of huge pages though, which means that there might be one or two less levels of page tables involved with those addresses). TLB misses aren't significant if you're bulk-writing to a block of memory anyway, you'll max out the bandwidth of the memory without that being an issue.

Re: Why does calloc exist?

#74

Post by kr7 »

Const-me wrote: post #65

Let’s see what happens after the allocation. With malloc + memset, the OS will likely allocate that memory in huge pages, on PC that would be 2-4MB / page depending on the architecture, https://en.wikipedia.org/wiki/Page_(computer_memory)#Huge_pa... If I calloc then write, the OS can’t give me huge pages because of that copy on write thing. Instead, the OS will gradually give me the memory in tiny 4kb pages. For larg…

A quick test with strace on my machine shows that callocing and mallocing a 2GB buffer results in the exact same mmap system call for both. Neither use huge pages.

Re: Why does calloc exist?

#75

Post by karmakaze »

valarauca1 wrote: post #45
wyldfire wrote: post #37

Earlier quoted context omitted.

I specifically avoided that word because it triggers particular deadlines that people have in mind. If my application requires no more than X ms latency I don't care to handwring over realtime vs soft realtime vs whatever, but it's still critical to fit in the budget. But indeed you can get reliable low-latency products to work on linux, with virtual memory. But like I said pinning is a great way to keep those peaks…

The division you are looking for is Hard Realtime : Embedded system, no virtual memory/OS. Or special OS provisions to let them run. Soft Realtime : Responsive. In the case you are aiming for the second. There are several million things that'll net greater performance. We're talking about saving a matter of nano-seconds in C/C++. How you load your config will have more effect then this. If you want to save $1,000,000…

I didn't think how it's achieved matters to the classification which is by the consequence of missing a deadline according to good ol' Wikipedia:

Hard – missing a deadline is a total system failure.

Firm – infrequent deadline misses are tolerable, but may degrade the system's quality of service. The usefulness of a result is zero after its deadline.

Soft – the usefulness of a result degrades after its deadline, thereby degrading the system's quality of service

Re: Why does calloc exist?

#76

Post by achivetta »

brynet wrote: post #40
syntheticnature wrote: post #24

Earlier quoted context omitted.

reallocarray(3) looks nifty, but until it's available on a wider, ideally more standard-driven basis than just OpenBSD and FreeBSD, it's likely to not see wide uptake.

It's already gaining adoption outside of the BSDs. OS X/iOS seem to have it as part of their libmalloc. Android Bionic libc has it as part of the code they sync from upstream OpenBSD. Many open source projects include their own, or simply bundle the OpenBSD implementation: * mandoc * flex * unbound and nsd * tor * tmux * libbsd * libressl * xorg-xserver * ... The list only continues to grow, several more examples to…

There's code for it in Darwin's libmalloc, but it's not exposed as API.

reallocarray() has some difficulties as an interface, mostly inherited from realloc(). I'm a bigger fan of reallocarr(), but that's NetBSD only. We (the operating systems community) need to find a consensus here, but I'm not convinced that reallocarray() is that consensus yet.

Re: Why does calloc exist?

#77

Post by et1337 »

sowbug wrote: post #61
jblow wrote: post #59

Earlier quoted context omitted.

I don't understand your reply. How is this not a non sequitur?

The output of a modern C compiler is unpredictable in terms of performance. Yet mannykannot suspects you still use such tools. Please explain your inconsistency.

Even if this weren't a fallacious argument, he's actually in the process of replacing Thekla's C/C++ workflow with a custom language called Jai.

Re: Why does calloc exist?

#78

Post by gkfasdfasdf »

wyldfire wrote: post #2

> So basically, calloc exists because it lets the memory allocator and kernel engage in a sneaky conspiracy to make your code faster and use less memory. You should let it! Don't use malloc+memset! On the flip side, if your critical metric is latency then these tricks of calloc's and the OS's are exactly what you try to avoid. memset() the buffer, and if you have the privileges you should mlock() it to prevent it fro…

And if you really want to squeeze the last bit of performance out you could not memset / init the memory at all, and make sure you only read the parts your app has written.

Re: Why does calloc exist?

#79

Post by developer2 »

As a non-moderator, can you please stfu article author with your political piece prefixing the article. If your reaction to being linked to from HN is to push your own political agenda, you are no better - and possibly worse - than the moderators. Using your 15 minutes of fame to edit your article with a preface containing a dozen links unrelated to the article you were linked to for is disgusting. It's not appreciated to click through to an article about calloc, only to find unwarranted political garbage that nobody cares about.

I flagged the article for this. How ironic that were enough people do this, it would be taken as "HN censorship" rather than "normal users saying they are displeased with the manipulative editing of the submitted link".

Quoted for history:

>> Welcome Hacker News readers! Before we dive into the neat memory management esoterica, I want to briefly note that as engineers we have an ethical obligation in our work to consider the "safety, health, and welfare of the public", because if we don't, terrible things happen. This is a challenging responsibility that requires we all stay thoughtful and informed – but that's difficult if popular technical news aggregators choose to censor links and discussions about the societal implications of technology. I sympathize with their moderation challenges, but this idea of creating a politics-free safe space is the cowards' way out, quite literally choosing the "absence of tension" over "the presence of justice". I hope the HN moderators find a way to step up to the responsibility their position entails; in the mean time, you might consider also subscribing to to The Recompiler and Model View Culture, and checking out Safety Pin Box, techsolidarity.org, or Fund Club. Anyway, thanks for listening! We now return to our regularly scheduled calloc-related programming, and I hope you enjoy my essay. And if you like this, you might also enjoy Cory Benfield's related post.

Re: Why does calloc exist?

#80

Post by mikeash »

Const-me wrote: post #65

Let’s see what happens after the allocation. With malloc + memset, the OS will likely allocate that memory in huge pages, on PC that would be 2-4MB / page depending on the architecture, https://en.wikipedia.org/wiki/Page_(computer_memory)#Huge_pa... If I calloc then write, the OS can’t give me huge pages because of that copy on write thing. Instead, the OS will gradually give me the memory in tiny 4kb pages. For larg…

There's no reason the OS can't use huge pages for a calloc. In fact, "give me some zeroed memory" tends to be the only interface exposed by the kernel, since security requires zeroing memory before handing it out to userspace anyway.
Post reply on HN