[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170620143548.GM27071@port70.net>
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.
