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:subject:to:references:reply-to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=Z2abR5I8n0AqlGs6
	y+y6h7QK9R6U7hmeA2qU402iJwGLL/U4UEklc/KeAvKt3tW2vDmgEqAJeYRcuN4S
	nJWsKFSmlFRtCQ2gNe6psOas+OlzEw+cpgFRBGOgsFury7o0aOe8jC9epiakfJ49
	D0OIqEh0Jx7n1dby/Sb4+juhaT8=
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:subject:to:references:reply-to:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; s=default; bh=eiQ2erXd+O6m2l2HUGxiQ3
	t6CIE=; b=x1Vvr2cu9N/ovBv0qP8BJNJHhruKB99V4nDoMY/7W4MkQPFm4hYgf7
	Rq2naWH9kkTDwJawfStPzXwgpv/3SejCTu/sdlt1eENqvMDxRZw5Chryf6iB42Ik
	iqFrHCECzIQrC88ogRWStWVDAaE6Cfcue2ZqzIkCulI/2B5hGureg=
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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=corina, assist, HContent-Transfer-Encoding:8bit
X-HELO: mail-it0-f43.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=1e100.net; s=20161025;        h=x-gm-message-state:subject:to:references:reply-to:from:message-id         :date:user-agent:mime-version:in-reply-to:content-language         :content-transfer-encoding;        bh=oDJn4JMiiMjZDYKJnEq7mxxEpJb869dixSnZHHCH1GQ=;        b=K2klpCns/nzW1FLW8bmYX8Fu1PebS1c6N+QifHy485/APRu6F9afFhQo/mSC6idAiG         RjJPzGnZ9HcW9TQ+HARxpfhQ44yVxHCj53NvVB0q9CiL7QNjFh8ICnOmtGiVMFxB8M9v         5ZnFPaSlBJwDPC8+wOUEQdEV7akpdRz48Lcj8EuYg8OQX7/m6CshG0i0EyoaIKUgSbtO         lIWvVJqlmPZPcXlR2IWfCnK1uTkXVsJvSORV0oBQR6y0kCQgAu8FxLlI0O7trZ8CS8z3         Er2WMBtVH0wrXjB/ve2Tkh2rAtntfBSRxcDoLtXJsEl0R5JCs2dYA0f1s2QqrrbebXBg         iZyw==
X-Gm-Message-State: AKwxytdZXOUbZvmxe2m159gCw4E9E8PMImDlFUnFBwjTfjrAVClVnO+7	pLhEp1mipV+7rvvqT0BcAO+Fcg==
X-Google-Smtp-Source: ACJfBothlJTVRn/ujtOVmJg4I9IEzZdTPdXRveEikhlGDNR+/O2qOqxwzwq+2y0Lpoy+f/zuOTWtKg==
X-Received: by 10.36.9.208 with SMTP id 199mr5684279itm.86.1515787183630;        Fri, 12 Jan 2018 11:59:43 -0800 (PST)
Subject: Re: calloc speed difference
To: cygwin AT cygwin DOT com
References: <CAD8GWsvxzFe0dPnxO-odTY+EG5XOAApLjcOSN5d7vXhtLW0GmQ AT mail DOT gmail DOT com> <46515148-9f8e-6eae-69f9-9bf20921097a AT t-online DOT de> <20180112143339 DOT GE24623 AT calimero DOT vinschen DOT de>
Reply-To: cygwin AT cygwin DOT com
From: cyg Simple <cygsimple AT gmail DOT com>
Message-ID: <b7ab3fe3-fa81-432d-33ad-9c0d7948b044@gmail.com>
Date: Fri, 12 Jan 2018 14:59:39 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <20180112143339.GE24623@calimero.vinschen.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-IsSubscribed: yes

On 1/12/2018 9:33 AM, Corinna Vinschen wrote:
> On Jan 12 15:06, 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.
>>
>> Cygwin's calloc() is different.
> 
> But then again, Cygwin's malloc *is* slow, particulary in
> memory-demanding multi-threaded scenarios since that serializes all
> malloc/free calls.
> 
> The memory handling within Cygwin is tricky.  Attempts to replace good
> old dlmalloc with a fresher jemalloc or ptmalloc failed, but that only
> means the developer (i.e., me, in case of ptmalloc) was too lazy...
> busy! I mean busy... to pull this through.
> 
> Having said that, if somebody would like to take a stab at replacing
> dlmalloc with something leaner, I would be very happy and assist as
> much as I can.

Corina, how reliable is the Cygwin time function on a non-Cygwin
executable?  Isn't this a comparison of apples to oranges?

-- 
cyg Simple

--
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