X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; q=dns; s=default; b=QqyzSqr
	YGSIuesstbGrdDs2HkqKT7+3kMn7hxsnYOxMgQPgSii+bQozxq0ZaGZVc07Bh2HN
	6cDXosMzt+cM0mqTeUKrIggVuAMVXbQ7/H9xQ49dZMx6KObV1Ipup7VJU6n4OaGv
	WMDwvCbezn40001vnhpmnZW3zAOT+FW5Yp/o=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:content-type; s=default; bh=4YDEvcSRWwPYN
	/ET3UwsBan1idk=; b=apbeLPoyQ+Q44Vq+Bjs5kHjPCJZOScodICLd1WDkkQzrx
	4TkF9B9aA2G7sZUIzlp3FaUgvhYkm+f/ignfA2sMazwEVOjKSiO1gW3ct3D4I765
	26CtK0Y7tj/hQZdNhWY5NR0vS173RmTQNtmLVVEbyn/l5I78AxbMKjtQbBr37M=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=buying, credit, pay
X-HELO: mail-io0-f172.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:mime-version:in-reply-to:references:from:date         :message-id:subject:to;        bh=3p99X2qAx/J0qOqULKMNdYgdWWCQQPdt+eMT9G8hbFc=;        b=iYjzIIrp0X82LJ7UW16xGs0RUITSYwEzE8OokxVusZ9T8tpQEVHOCH3fAQl2U35z2r         ggXSrVpFDIgVqwWiGj1rgjA+A52Tc4V1/NqioRHnB+tjyoXhGa4B+f3VvAqrix54C4mw         66cOxcL413N94ysCvWAbtwI6lfrlqFMSfRGXjoAao+y8+mnveh83C2d7tHdIuchXDW7X         /c0Y4w0UYf7sHQ9FimI+Cawbr8CcA22t3Or2lF4HDIJW0HnQKxhUhCgDJtS50cq5G7RA         HT/Kao7ltEUlGW9SQFddAa9UtwPVMKXKzSiArBNdVzaTPcPB4TMJjxJ2G8nXolrZRAGu         95LA==
X-Gm-Message-State: AKGB3mKjUfx/QmFtCJ9to0BAqkAPvCgvhrxGNqdMGZQ8J4KHhxKoP0wl	Em+1gX/bnEJMLYv1osuyqJrEGUkllPWbZs5chDY=
X-Google-Smtp-Source: ACJfBov1fNnozKs6Io3IZPpEZ1OGqgPdfzvEEZRSpjm8+4ayx5QCRsxEsps0x9/uoRihIHgbBaoBrgvaLx/eP1hu41s=
X-Received: by 10.107.166.18 with SMTP id p18mr28792665ioe.158.1515832510246; Sat, 13 Jan 2018 00:35:10 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <46515148-9f8e-6eae-69f9-9bf20921097a@t-online.de>
References: <CAD8GWsvxzFe0dPnxO-odTY+EG5XOAApLjcOSN5d7vXhtLW0GmQ AT mail DOT gmail DOT com> <46515148-9f8e-6eae-69f9-9bf20921097a AT t-online DOT de>
From: Lee <ler762 AT gmail DOT com>
Date: Sat, 13 Jan 2018 03:35:09 -0500
Message-ID: <CAD8GWstP5_5Jg=FSm37QfY_3yWT84=S03Q1-=0985=CXteXA7A@mail.gmail.com>
Subject: Re: calloc speed difference
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes

On 1/12/18, Christian Franke  wrote:
> Lee wrote:
>> Why is the cygwin gcc calloc so much slower than the
>> i686-w64-mingw32-gcc calloc?
>>    1:12 vs 0:11
>>
>> $cat calloc-test.c
>> #include <stdio.h>
>> #include <stdlib.h>
>> #define ALLOCATION_SIZE (100 * 1024 * 1024)
>> int main (int argc, char *argv[]) {
>>      for (int i = 0; i < 10000; i++) {
>>          void *temp = calloc(ALLOCATION_SIZE, 1);
>>          if ( temp == NULL ) {
>>             printf("drat! calloc returned NULL\n");
>>             return 1;
>>          }
>>          free(temp);
>>      }
>>      return 0;
>> }
>>
>
> Could reproduce the difference on an older i7-2600K machine:
>
> Cygwin: ~20s
> MinGW: ~4s
>
> Timing [cm]alloc() calls without actually using the allocated memory
> might produce misleading results due to lazy page allocation and/or
> zero-filling.
>
> MinGW binaries use calloc() from msvcrt.dll. This calloc() does not call
> malloc() and then memset(). It directly calls:
>
>    mem = HeapAlloc(_crtheap, HEAP_ZERO_MEMORY, size);
>
> which possibly only reserves allocate-and-zero-fill-on-demand pages for
> later.

Which seems like it could be viewed as a feature?  Sort of like buying
on credit - you don't pay for it all up front, just pay a bit each
time you reference another zero fill on demand page.


> Cygwin's calloc() is different.
>
> This variant of the above code adds one write access to each 4KiB page
> (guarded by "volatile" to prevent dead assignment optimization):
>
> #include <stdio.h>
> #include <stdlib.h>
> #define ALLOCATION_SIZE (100 * 1024 * 1024)
> int main (int argc, char *argv[]) {
>      for (int i = 0; i < 1000; i++) {
>          void *temp = calloc(ALLOCATION_SIZE, 1);
>          if ( temp == NULL ) {
>             printf("drat! calloc returned NULL\n");
>             return 1;
>          }
>          for (int j = 0; j < ALLOCATION_SIZE; j += 4096)
>            ((volatile char *)temp)[j] = (char)i;
>          free(temp);
>      }
>      return 0;
> }
>
> Results:
>
> Cygwin: ~310s
> MinGW: ~210s

Wow!  Really nice explanation & example - Thank you.
Lee

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple