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=oVvGxs0rXDJoIN/A
	8cKCpXU/jiI/I0q3RebJHJokgvZQg6pegBtzoH3nUsBnVwEqTZYwlMcuhm96Gqum
	R3LFo5IxaTfjnHm6jH9+F4entn+Q5LN8vgyOohGXiFHZZudHPV+97p/TSB/dO/wc
	tx9vI/5ltfpVLo+I+CVXOmE0Ghs=
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=YUcYN+P9LzBdtCOX/c1XhG
	j4/nw=; b=S31NhVTEFbIHn8cy+Z2VaN+qbirQITPeJXyWDs5rY8CaA6zIfqOhuk
	we7cVRKxFa2asctJhWy69XgW0KDxDTeFKv+hcjVMgm+UNnuyA4Lbh0iUUte6xf7L
	PpF9pOw3twtwlEVSAVyX/HWl8l9oyUjTiZwWp5z2IIdl9OnF0itMo=
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=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-HELO:	mail-it0-f50.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=GbhmsVNYKHKrbyJSG9In8HPqAh1qg3EqlS3XSk9z6gQ=; b=ZPe/yd6fy4g6/rzGzzt6eDPdovn8OwONnSRkkJwHICiPj2s0CjIal/nEJLgiqaz5Tm jkN5wl0H7x+Ng+6J1i2H+2ncd7CZ6p6PH+F2Hzylc0Hh53SI1h7vtmbNLRGk1LOj4qJH TY8wgMo07GC/i/9NqnjcjyHjuyZ1cu/q2VAp3QRaMla/lXOUVnFTRO6FBHyudrJICRCz fQy+pBmyAUUi8ztm5IkksSWkHlx9+JcH8gw7oAuo0lG+Di6M0H5xxEyg1cv/aCZfmHBd OrKXKZiApvwC6sgphGQkoK+AUKmjB4UyYLwadfkYT90y8rad9kn2ODP73ZQDyGfie5ei nUMw==
X-Gm-Message-State:	AKwxytf0LNFKxlobSc4p8o1B1b1LW8WfzgHmgOJyzNDWR9/bTFk5txqD gHlvk5cmsz1+frXc/FgbyzbGOQ==
X-Google-Smtp-Source:	ACJfBoulkT/isxXXO8rdeRchVJ6XtBHvONyTvF00Av16+0zvrLy/1SxBsp7mF8RkbGZXRUYQ+aOghw==
X-Received:	by 10.36.25.140 with SMTP id b134mr5532056itb.21.1515787620522; Fri, 12 Jan 2018 12:07:00 -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> <b7ab3fe3-fa81-432d-33ad-9c0d7948b044 AT gmail DOT com>
Reply-To:	cygwin AT cygwin DOT com
From:	cyg Simple <cygsimple AT gmail DOT com>
Message-ID:	<afcef638-3f70-36c7-6148-9c0343021fa5@gmail.com>
Date:	Fri, 12 Jan 2018 15:06:56 -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:	<b7ab3fe3-fa81-432d-33ad-9c0d7948b044@gmail.com>
X-IsSubscribed:	yes

On 1/12/2018 2:59 PM, cyg Simple wrote:
> 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?
> 

s/Corina/Corinna

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

- Raw text -