Why does calloc exist? • Hacker News Board

Re: Why does calloc exist?

#131

Post by binarycrusader » Tue, Dec 06, 2016, 8:56 PM UTC

astrobe_ wrote: post #124

binarycrusader wrote: post #53

Earlier quoted context omitted.

The standard library is usually delivered as part of the operating system on *nix-like platforms.

Making statements as inaccurate as possible without being wrong is a fun game, I guess. My turn: A file explorer is part of the OS because it is installed by default on Windows. A good OS provides a graphical file browser.

As the other respondent posted, the standard library is the only interface to the operating system on some platforms.

For example, on Solaris and various *BSDs, the syscall interface is private or unstable and is explicitly NOT an interface.

So without the standard library, none of the applications could run.

That sure sounds like part of the operating system to me, and fits various accepted definitions such as the one Wikipedia provides.

And yes, I would consider the file explorer included with Windows part of the operating system, as most people I think would also.

The confusion here seems to come from the Linux world, where components are mix and match; where you can pair the kernel with an entirely different base.

That isn't true of many other operating systems; the base distributed set is designed to work together and provide the environment and platform for applications.

Re: Why does calloc exist?

#132

Post by valarauca1 » Wed, Dec 07, 2016, 1:53 PM UTC

karmakaze wrote: post #75

valarauca1 wrote: post #45

Earlier quoted context omitted.

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, there…

Your difference between soft/firm is an arbitrary decision made by a manager, not really a hard/fast If I can't meet this deadline my system is a total technical failure.

You've created a false dichotomy.

Re: Why does calloc exist?

#133

Post by astrobe_ » Wed, Dec 07, 2016, 5:41 PM UTC

binarycrusader wrote: post #131

astrobe_ wrote: post #124

Earlier quoted context omitted.

Making statements as inaccurate as possible without being wrong is a fun game, I guess. My turn: A file explorer is part of the OS because it is installed by default on Windows. A good OS provides a graphical file browser.

As the other respondent posted, the standard library is the only interface to the operating system on some platforms. For example, on Solaris and various *BSDs, the syscall interface is private or unstable and is explicitly NOT an interface. So without the standard library, none of the applications could run. That sure sounds like part of the operating system to me, and fits various accepted definitions such as the o…

There's no confusion at all on my part. The operating system isn't even aware that your application has a heap to begin with. All it knows, is that your program may ask for more memory.

But if you consider a file browser as being part of the OS, I can't help you. You want to adopt a view that profanes have in a technical discussion. That's worse than ignorance.

Re: Why does calloc exist?

#134

Post by kllrnohj » Wed, Dec 07, 2016, 5:55 PM UTC

astrobe_ wrote: post #52

kllrnohj wrote: post #51

Earlier quoted context omitted.

At the same time why would you ever opt to malloc & memset instead of calloc? calloc might have clever optimizations, whereas malloc + memset won't. Intentionally choosing something slower, buggier, and that requires more work on your part is moronic.

Predictability sometimes trumps optimizations. For a striking illustration of this, see timing attacks.

yes, but malloc() isn't predictable either. If you care about predictability you aren't using malloc or calloc.

Re: Why does calloc exist?

#135

Post by Const-me » Wed, Dec 07, 2016, 7:06 PM UTC

mikeash wrote: post #80

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.

This article _creates_ a reason why the OS might not be able to use huge pages for a calloc.

If substantial count of people will read this article, believe what’s written, and [re]design their software under the wrong assumption calloc returns sparse copy-on-write memory buffer at no performance cost — the OSes will no longer be able to use huge pages for a calloc. Because doing that would dramatically increase physical memory usage for such software.

Re: Why does calloc exist?

#136

Post by notacoward » Wed, Dec 07, 2016, 9:43 PM UTC

mikeash wrote: post #10

notacoward wrote: post #7

I always thought it was because of padding. An array of M structures each N bytes long could require more than M*N bytes (certainly has on some architectures I've worked with). But I guess that's not it after all.

C accounts for padding in the size of the individual type. By the time you do sizeof, it's already rounded up to where you can just do M*N. For example: struct S { long a; char b; }; On my computer (64-bit Mac), sizeof(struct S) is 16, due to 7 bytes of padding after b. Since the compiler handles the padding, that means calloc doesn't have to.

Today's compilers. How about the compilers when calloc was first defined? As I said, I've worked on compilers that behaved differently, either always or according to various options. The computing universe has actually become less diverse in some ways than it used to be, so we should be careful of drawing conclusions about old interfaces based on today's monoculture. Is it really impossible for people here to imagine that some of the dozens of platforms that had their own compilers and C libraries chose to do the rounding up in the latter? It would actually be a pretty reasonable choice, for different microarchitectures capable of running the same instruction set and binaries but with different cache subsystems. That way you could make the decision at run time instead of compile time. Many of the early RISC machines did even weirder tricks than that to wring out the last bit of performance on multiple generations without having to recompile.

Re: Why does calloc exist?

#137

Post by binarycrusader » Wed, Dec 07, 2016, 11:57 PM UTC

astrobe_ wrote: post #133

binarycrusader wrote: post #131

Earlier quoted context omitted.

As the other respondent posted, the standard library is the only interface to the operating system on some platforms. For example, on Solaris and various *BSDs, the syscall interface is private or unstable and is explicitly NOT an interface. So without the standard library, none of the applications could run. That sure sounds like part of the operating system to me, and fits various accepted definitions such as the o…

There's no confusion at all on my part. The operating system isn't even aware that your application has a heap to begin with. All it knows, is that your program may ask for more memory. But if you consider a file browser as being part of the OS, I can't help you. You want to adopt a view that profanes have in a technical discussion. That's worse than ignorance.

You are very confused and quite frankly very wrong.

The original claim was the standard library is not part of the OS. However, the standard library is objectively part of the OS on many platforms and so the original claim is factually incorrect.

My so-called "view" reflects the industry accepted definition of an OS, so perhaps you should review your suppositions.

Re: Why does calloc exist?

#138

Post by joemcmahon » Thu, Dec 08, 2016, 1:17 AM UTC

LukeShu wrote: post #33

bluefox wrote: post #3

That's a nice alternative history fiction. Here's an early implementation: https://github.com/dspinellis/unix-history-repo/blob/Researc...

You haven't proven it wrong. Here's the earliest implementation in that repo (in Research UNIX V6; your link in V7): https://github.com/dspinellis/unix-history-repo/blob/Researc... calloc(n, s) { return(alloc(n*s)); } There are several interesting things we learn from poking around V6 though: - `calloc` originated not on UNIX, but as part of Mike Lesk's "iolib", which was written to make it easier to write C programs…

GETMAIN, the malloc() equivalent in MVT-derived IBM OSes, does not always zero memory. IIRC, MVS didn't zero it at all, so you might get anything in there, thus the need for a call that guaranteed zeroed memory for it. (This is from my memory of assembly programming on MVT/MVS up to the 1990s; z/OS apparently[1] does it somewhat differently now, so that some allocations are definitely zeroed.)

[1] http://www-01.ibm.com/support/docview.wss?uid=isg1OA28314

Re: Why does calloc exist?

#139

Post by astrobe_ » Thu, Dec 08, 2016, 6:02 PM UTC

binarycrusader wrote: post #137

astrobe_ wrote: post #133

Earlier quoted context omitted.

There's no confusion at all on my part. The operating system isn't even aware that your application has a heap to begin with. All it knows, is that your program may ask for more memory. But if you consider a file browser as being part of the OS, I can't help you. You want to adopt a view that profanes have in a technical discussion. That's worse than ignorance.

You are very confused and quite frankly very wrong. The original claim was the standard library is not part of the OS. However, the standard library is objectively part of the OS on many platforms and so the original claim is factually incorrect. My so-called "view" reflects the industry accepted definition of an OS, so perhaps you should review your suppositions.

Ok so name a few of the "OS on many platforms" in which one absolutely can't replace the standard library.

Re: Why does calloc exist?

#140

Post by binarycrusader » Fri, Dec 09, 2016, 1:30 AM UTC

astrobe_ wrote: post #139

binarycrusader wrote: post #137

Earlier quoted context omitted.

You are very confused and quite frankly very wrong. The original claim was the standard library is not part of the OS. However, the standard library is objectively part of the OS on many platforms and so the original claim is factually incorrect. My so-called "view" reflects the industry accepted definition of an OS, so perhaps you should review your suppositions.

Ok so name a few of the "OS on many platforms" in which one absolutely can't replace the standard library.

Solaris is one of them, unless you made significant changes to the kernel itself.

Darwin, as shipped by Apple is another.

There are a variety of embedded OS' that are the same.

So yes, as shipped and delivered, you can't replace the standard library and the vendors both consider the standard library as part of the OS.

And furthermore, existing application binaries for those platforms would not work without them.