Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Jun 2017 16:35:49 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Query regarding malloc if statement

* Markus Wichmann <nullplan@....net> [2017-06-20 06:14:29 +0200]:
> On Mon, Jun 19, 2017 at 09:02:00PM +0000, Jamie Mccrae wrote:
> > My understanding is that doing a read followed by a possible write is slower than always doing a write for the reason that upon doing a read the process will halt
> > until the memory is brought into the CPU's cache which isn't a problem when just doing a write. I've just thrown together a simple application to test this (testing on a modern PC running alpine linux 64-bit in a virtualbox VM with 512MB RAM and 1 CPU core) with a normal musl library and a modified one whereby I've removed the 'if' check:
> > 
> 
> Woah, you're mixing up a few things here. A cache miss and a page fault
> are two very different things.
> 
> Besides, doesn't a cache miss on write mean that a cache-line for the
> write area has to be allocated first?
> 

are you arguing with somebody off-list?
(i only see your replies)

in any case the calloc code should not be
controversial on linux.

writing to each allocated page when they are
potentially unused is a huge waste of memory
not just time. (a benchmark that calls calloc/free
in a loop is obviously bogous, try

calloc(1000*1000*1000,1)

vs

memset(malloc(1000*1000*1000),0,1000*1000*1000))

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.