Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-Id: <6.0.1.1.0.20040718063702.01f796e8@imap.myrealbox.com> X-Sender: tprince AT imap DOT myrealbox DOT com Date: Sun, 18 Jul 2004 07:08:40 -0700 To: cygwin AT cygwin DOT com From: Tim Prince Subject: Re: Performance: g++ Cygwin vs. other compilers (copying char[] to vector) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-IsSubscribed: yes At 05:00 AM 7/18/2004, Alex Vinokur wrote: >Hi, > >How to explain so considerable difference in performance: g++ Cygwin vs. >other compilers in tests below? I can't figure out at a glance what you are doing. I find that loop lengths of 1000 or less (32-bit data types) require the cpu cycle timer (rdtsc) to get repeatable results. I have no significant difference in timings between g++ STL templates running in linux or in cygwin, not even between 32-bit cygwin under WOW64 and 64-bit linux. The Microsoft builds are generally slower. I haven't tried -mno-cygwin, I've used only standard gcc/g++ 3.4.x. My tests call a dummy() function before running back through the same test data, so that there is no software optimization performed by recognizing do-nothing loops. The data are initialized to normal stuff of the correct data type, so that no exceptions occur, same initial values for each compiler. Much of this comes ready-made in the Levine-Callahan-Dongarra vector benchmark from netlib.org. Where possible, I have made C, C++, and Fortran 90 versions, so I can get quite picky about effectiveness of compiler optimizations. I don't find your compile options, or whether you have profiled. For g++ under cygwin, I use -O3 -funroll-loops -march=pentium4 -mfpmath=sse No doubt, some of the compilers have entirely different defaults. Are you one of those who considers the only fair comparison to be among defaults, even though those vary from no optimization to more than what is permitted by the language standards? Microsoft STL doesn't implement copy() as memmove(), as libstdc++, STLport, and Dinkumware do, nor do the Microsoft compilers perform any consolidation of moves into 64- or 128- bit moves. If there is a memmove() replacement, you should tell us which one is used. Newlib is likely to be slow; even glibc or MS RT are not likely to be optimized for a particular style of CPU. Tim Prince -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/