A Simple Real World Benchmark for Cygwin

A Simple Real World Benchmark for Cygwin

[Rick Richardson]

[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]

A Simple Real World Benchmark for CygWin
----------------------------------------

This is a simple benchmark of CygWin performance when running a
collection of Unix tools such as sed, awk, gcc.  It uses the familiar
"configure" script to generate the load.  I picked a configure script
I happened to have laying around as being "representative" of this
type of load.

I am a CygWin newbie.  The motivation for this benchmark is that I
noticed that my CygWin installations were so slow as to effectively be
unusable for development work.  For example, the attached script runs
in 5 seconds with native Redhat 7.2 on a P3/700 with a 7200 RPM disk.
But the script takes 3 minutes to run on the same machine under CygWin.

Certainly, some performance degradation under CygWin could be expected
and tolerated.  But not a factor of 30X or more.  IMHO, of course.

It is not entirely clear to me that my performance is representative
of other CygWin installations.  Without a benchmark, it is impossible
for me to determine if the results I am seeing are normal for CygWin,
or the result of some unknown as yet system or installation problem.

Hence this benchmark, which I hope will allow myself and others to
compare CygWin performance with the performance that other people
are seeing.

Running the benchmark is simple, and I am not particularly interested
in highly precise results in this first pass.  Simply make your system
as quiescent as possible, then type:

        rm -f config.cache
        time ./configure

Report the elapsed *real* time.

Here are the results from my two tests.  I will happily accept other
benchmark reports.  Mail them to rickr@mn.rr.com.

-Rick Richardson, 09/02/2002

TIME    CPU     MHZ     DISK            OS AND VERSION
(secs)                  
------  ---     ---     --------------  ----------------------------------
5       P3      700     IBM 7200RPM     RH7.2, native
180     P3      700     IBM 7200RPM     win98 4.10.1998, cygwin 1.3.12-2

-- 
Rick Richardson  rickr@mn.rr.com        http://home.mn.rr.com/richardsons/
Stock information at your fingertips:   http://linuxtrade.0catch.com/

Most Minnesotans think Global Warming is a good thing.

[-- Attachment #2: cygbench.tar.gz --]
[-- Type: application/x-gzip, Size: 24202 bytes --]

[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Ville Herva]

> TIME    CPU     MHZ     DISK            OS AND VERSION (secs)
> ------  ---     ---     --------------  ----------------------------------
> 5       P3      700     IBM 7200RPM     RH7.2, native
> 180     P3      700     IBM 7200RPM     win98 4.10.1998, cygwin 1.3.12-2

FWIW:

winXP, cygwin 1.3.12(0.54/3/2), 2xP3 900, 18GB 10k scsi
./configure  15.81s user 15.41s system 102% cpu 30.329 total

linux-2.2.21pre2, celeron-1000, old 9GB 7200 scsi
./configure  1.37s user 0.81s system 18% cpu 11.776 total

linux-2.4.13ac2, P3-600, 18GB 10k scsi
./configure  2.28s user 0.90s system 56% cpu 5.656 total

I believe XP is much better than 98 with cygwin?


-- v --

v@iki.fi

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Christopher Faylor]

On Mon, Sep 02, 2002 at 10:19:58AM -0500, Rick Richardson wrote:
>A Simple Real World Benchmark for CygWin

Here's the bottom line:  Cygwin is slow.  Either get used to it
or investigate the code and offer ways to speed it up.

Oh, and it is "Cygwin", not "CygWin".

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: A Simple Real World Benchmark for cygwin

[Dan Vasaru]

cgf> or investigate the code and offer ways to speed it up.

Here's a potential speedup for non-NTFS symlinks:

The check_shortcut function in shortcut.c calls CoInitialize/CoUninitialize
for *every* .LNK it needs to check on non EA filesystems.

I ran a small test on my computer, calling check_shortcut 1000 times.
When I moved the calls to CoInitialze/CoUnitialize outside the
check_shortcut function, the function throughput increased from 59 calls/sec
to 960 calls/sec.

As it turns out, CoInit...CoUninit costs up to 20 msecs on my system.

So my suggestion is that the CoInit../CoUnit... calls be moved to another
spot, to be called once per thread.


Dan.

PS. This patch made no difference what-so-ever on the timing results of the
cygbench configure on my NTFS disks; then again, it may help FATxx/Samba/NFS
people.



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Christopher Faylor]

On Mon, Sep 02, 2002 at 11:34:11PM +0200, Dan Vasaru wrote:
>cgf> or investigate the code and offer ways to speed it up.
>
>Here's a potential speedup for non-NTFS symlinks:
>
>The check_shortcut function in shortcut.c calls CoInitialize/CoUninitialize
>for *every* .LNK it needs to check on non EA filesystems.
>
>I ran a small test on my computer, calling check_shortcut 1000 times.
>When I moved the calls to CoInitialze/CoUnitialize outside the
>check_shortcut function, the function throughput increased from 59 calls/sec
>to 960 calls/sec.
>
>As it turns out, CoInit...CoUninit costs up to 20 msecs on my system.
>
>So my suggestion is that the CoInit../CoUnit... calls be moved to another
>spot, to be called once per thread.
>
>
>Dan.
>
>PS. This patch made no difference what-so-ever on the timing results of the
>cygbench configure on my NTFS disks; then again, it may help FATxx/Samba/NFS
>people.

Only if there are a lot of symlinks, it seems.  Otherwise the code would never
be hit.  And indiscriminately setting it once for each thread could have some
negative ramifications when the program isn't manipulating any symlinks.

It's a good suggestion, nonetheless.

Corinna, this is your code, what do you think?  Maybe a per-thread
"initialized_yet?" global would be useful here.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Corinna Vinschen]

On Mon, Sep 02, 2002 at 06:02:34PM -0400, Chris Faylor wrote:
> >Here's a potential speedup for non-NTFS symlinks:
> >
> >The check_shortcut function in shortcut.c calls CoInitialize/CoUninitialize
> >for *every* .LNK it needs to check on non EA filesystems.
> >
> >I ran a small test on my computer, calling check_shortcut 1000 times.
> >When I moved the calls to CoInitialze/CoUnitialize outside the
> >check_shortcut function, the function throughput increased from 59 calls/sec
> >to 960 calls/sec.
> >
> >As it turns out, CoInit...CoUninit costs up to 20 msecs on my system.
> >
> >So my suggestion is that the CoInit../CoUnit... calls be moved to another
> >spot, to be called once per thread.
> >
> >
> >Dan.
> >
> >PS. This patch made no difference what-so-ever on the timing results of the
> >cygbench configure on my NTFS disks; then again, it may help FATxx/Samba/NFS
> >people.

Uhm... it should have nothing to do with NTFS vs. other FS.  The shortcut
symlinks are used on all FS.

> Only if there are a lot of symlinks, it seems.  Otherwise the code would never
> be hit.  And indiscriminately setting it once for each thread could have some
> negative ramifications when the program isn't manipulating any symlinks.
> 
> It's a good suggestion, nonetheless.
> 
> Corinna, this is your code, what do you think?  Maybe a per-thread
> "initialized_yet?" global would be useful here.

The question is if we can drop CoUninitialize() completely.  If the call
to CoUninitialize() is dropped, it should not matter to call CoInitialize()
multiple times since it should only return a "The COM library is already
initialized on this thread" return code.  That shouldn't take that much
time.  The slowness results from the need to load DLLs and such stuff.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[dvasaru]

Quoting Corinna Vinschen <corinna-cygwin@cygwin.com>:

> Uhm... it should have nothing to do with NTFS vs. other FS.  The shortcut
> symlinks are used on all FS.

That's what I thought to begin with, but cygwin cunningly uses Extended Attributes where available,  bypassing the check_shortcut and the whole COM world altogether on NTFS.

> The question is if we can drop CoUninitialize() completely.  If the call
> to CoUninitialize() is dropped, it should not matter to call CoInitialize()
> multiple times since it should only return a "The COM library is already
> initialized on this thread" return code.  That shouldn't take that much
> time.  The slowness results from the need to load DLLs and such stuff.

To quote from the MSDN:
"To close the COM library gracefully, each successful call to CoInitialize or CoInitializeEx, including those that return S_FALSE, must be balanced by a corresponding call to CoUninitialize"

Another relevant quote:
"Because there is no way to control the order in which in-process servers are loaded or unloaded, it is not safe to call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function"

To accomodate cygwin-based COM users, one should probably swallow the MSDN prescription and find a better place to call  CoInit/CoUninit. 

On the other hand, if the shortcut file format is known(?), one could maybe bypass the COM/ IShellXXXX interfaces completely  and read the link directly from the file.

Dan



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Corinna Vinschen]

On Tue, Sep 03, 2002 at 11:38:34AM +0200, dvasaru@broadpark.no wrote:
> Quoting Corinna Vinschen <corinna-cygwin@cygwin.com>:
> 
> > Uhm... it should have nothing to do with NTFS vs. other FS.  The shortcut
> > symlinks are used on all FS.
> 
> That's what I thought to begin with, but cygwin cunningly uses Extended Attributes where available,  bypassing the check_shortcut and the whole COM world altogether on NTFS.

Yeah, that's right, of course.

> > The question is if we can drop CoUninitialize() completely.  If the call
> > to CoUninitialize() is dropped, it should not matter to call CoInitialize()
> > multiple times since it should only return a "The COM library is already
> > initialized on this thread" return code.  That shouldn't take that much
> > time.  The slowness results from the need to load DLLs and such stuff.
> 
> To quote from the MSDN:
> "To close the COM library gracefully, each successful call to CoInitialize or CoInitializeEx, including those that return S_FALSE, must be balanced by a corresponding call to CoUninitialize"
> 
> Another relevant quote:
> "Because there is no way to control the order in which in-process servers are loaded or unloaded, it is not safe to call CoInitialize, CoInitializeEx, or CoUninitialize from the DllMain function"

Yep, that's the problem.  And the reasoning for calling CoInit/CoUnint
always as pair here since there's no way to rely on that the application
will *not* call CoUnit somewhere in the middle of its processing.

> On the other hand, if the shortcut file format is known(?), one could maybe bypass the COM/ IShellXXXX interfaces completely  and read the link directly from the file.

That's ok.  The format is partly known, at least it should be enough
to read the info from Cygwin created shortcuts.  The creation itself
already uses plain WriteFile() calls.  However, the code in shortcut.c
was meant to read all shortcuts (see the

 #if TREAT_NATIVE_SHORTCUTS_AS_SYMLINKS

part of the code.  Since we are confident that treating natively created
shortcuts as symlinks is a fault, we could drop that requirement and
just use ReadFile() for that.  This would obviously speed up Cygwin
when reading shortcuts.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Robert Collins]

[-- Attachment #1: Type: text/plain, Size: 604 bytes --]

On Tue, 2002-09-03 at 21:51, Corinna Vinschen wrote:

> Yep, that's the problem.  And the reasoning for calling CoInit/CoUnint
> always as pair here since there's no way to rely on that the application
> will *not* call CoUnit somewhere in the middle of its processing.

If it does, and it didnt' call CoInit, it is an application bug, and not
our problem. Thats why there is the requirement to pair the calls - to
allow us to call it once when we need it, and once on shutdown. If we
need to call it once per thread, then IMO we simply set a per-thread
flag when we have called it.
 
Rob


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: A Simple Real World Benchmark for cygwin

[Corinna Vinschen]

On Tue, Sep 03, 2002 at 09:59:57PM +1000, Robert Collins wrote:
> On Tue, 2002-09-03 at 21:51, Corinna Vinschen wrote:
> 
> > Yep, that's the problem.  And the reasoning for calling CoInit/CoUnint
> > always as pair here since there's no way to rely on that the application
> > will *not* call CoUnit somewhere in the middle of its processing.
> 
> If it does, and it didnt' call CoInit, it is an application bug, and not
> our problem. Thats why there is the requirement to pair the calls - to
> allow us to call it once when we need it, and once on shutdown. If we
> need to call it once per thread, then IMO we simply set a per-thread
> flag when we have called it.

That's not the point.  The application *may* call CoInit() before
requesting the first path to a shortcut and it *may* call CoUninit()
before requesting another path to a shortcut, all in the same thread.
The CoInit/CoUnint brace in shortcut.c is safe against that:

    Application  Cygwin-DLL

    CoInit()
    lstat()    ->  CoInit()
                   CoUninit()
    CoUninit()
    lstat()    ->  CoInit()
                   CoUninit()

while storing our own state is not safe:

    Application  Cygwin-DLL

    CoInit()
                   CoInit()
    lstat()    ->  ok
    CoUninit()
    lstat()    ->  ???

To workaround that situation, Cygwin would have to call CoInit()
anyway to know it's state.  Since that requires to be balanced
according to MSDN...

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: A Simple Real World Benchmark for cygwin

[Dan Vasaru]

Corrina,

Here's an idea that may work:

I run another quick benchmark that shows CoInit/CoUninit are "free" if
another CoInit is in effect. So we could make sure that the first CoInit is
not matched, whereas the rest are:

check_shortcut()
{
  CoInit(..);
  ...
  if (per_thread_coinit_count != 0) CoUnit(...); // always call except first
time
  per_thread_coinit_count++;
}

Now, the per_thread_coinit_count variable needs to be checked somewhere to
call CoUnit once more during thread/mainthread termination.

Note that if wellbehaved application calls CoUninit, it must have called
CoInit, so the COM use count never falls to zero.

Dan.

-----Original Message-----
From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
Of Corinna Vinschen
Sent: Tuesday, September 03, 2002 2:42 PM
To: cygwin@cygwin.com
Subject: Re: A Simple Real World Benchmark for cygwin


On Tue, Sep 03, 2002 at 09:59:57PM +1000, Robert Collins wrote:
> On Tue, 2002-09-03 at 21:51, Corinna Vinschen wrote:
>
> > Yep, that's the problem.  And the reasoning for calling CoInit/CoUnint
> > always as pair here since there's no way to rely on that the application
> > will *not* call CoUnit somewhere in the middle of its processing.
>
> If it does, and it didnt' call CoInit, it is an application bug, and not
> our problem. Thats why there is the requirement to pair the calls - to
> allow us to call it once when we need it, and once on shutdown. If we
> need to call it once per thread, then IMO we simply set a per-thread
> flag when we have called it.

That's not the point.  The application *may* call CoInit() before
requesting the first path to a shortcut and it *may* call CoUninit()
before requesting another path to a shortcut, all in the same thread.
The CoInit/CoUnint brace in shortcut.c is safe against that:

    Application  Cygwin-DLL

    CoInit()
    lstat()    ->  CoInit()
                   CoUninit()
    CoUninit()
    lstat()    ->  CoInit()
                   CoUninit()

while storing our own state is not safe:

    Application  Cygwin-DLL

    CoInit()
                   CoInit()
    lstat()    ->  ok
    CoUninit()
    lstat()    ->  ???

To workaround that situation, Cygwin would have to call CoInit()
anyway to know it's state.  Since that requires to be balanced
according to MSDN...

Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: A Simple Real World Benchmark for cygwin

[Bjoern Kahl AG Resy]

 Hi!

 I think, there is a missunderstanding on your side, Corinna
 (see below)


On Tue, Sep. 03, 2002, Corinna Vinschen wrote:
> On Tue, Sep 03, 2002 at 09:59:57PM +1000, Robert Collins wrote:
> > On Tue, 2002-09-03 at 21:51, Corinna Vinschen wrote:

> > > Yep, that's the problem.  And the reasoning for calling
> > > CoInit/CoUnint
> > > always as pair here since there's no way to rely on that the
> > > application
> > > will *not* call CoUnit somewhere in the middle of its processing.

> > If it does, and it didnt' call CoInit, it is an application bug, and
> > not
> > our problem. Thats why there is the requirement to pair the calls - to
> > allow us to call it once when we need it, and once on shutdown. If we
> > need to call it once per thread, then IMO we simply set a per-thread
> > flag when we have called it.

> That's not the point.  The application *may* call CoInit() before
> requesting the first path to a shortcut and it *may* call CoUninit()
> before requesting another path to a shortcut, all in the same thread.
> The CoInit/CoUnint brace in shortcut.c is safe against that:

 As I understand MSDN, the order of CoInit and CoUnint does not
 matter, as long as there is an equal number of CoUninit and CoInit
 at Process termination and the (number of CoUninit) <= (number of
 CoInit) at every other point of time.

 But then your examples are identical. I do not know details of
 the inner cygwin working, so I discuss two possible setups


 Example A)

>     Application  Cygwin-DLL
>
>    CoInit()
>    lstat()    ->  CoInit()
>                   CoUninit()
>    CoUninit()
>    lstat()    ->  CoInit()
>                   CoUninit()
>
> while storing our own state is not safe:

 Example B)
>
>    Application  Cygwin-DLL
>
>    CoInit()
>                   CoInit()
>    lstat()    ->  ok
>    CoUninit()
>    lstat()    ->  ???

> To workaround that situation, Cygwin would have to call CoInit()
> anyway to know it's state.  Since that requires to be balanced
> according to MSDN...

 1.) Lets assume, application and cygwin-lstst run in the same
     thread

 In Example A), while inside the first lstat, the thread has
 two instances of COM open (from application and from cygwin),
 same in the second call to lstat.

 In Example B), inside the first lstat, it identical to example A.
 In the second lstat, there is still one COM instance open, so
 every thing is right, because all calls to CoInit and CoUninit
 are equal, only the number matters. (This follows out of the fact,
 that CoInit with S_FALSE has to be matched by a CoUninit, too.)

 2.) Assume two or more threads.
 if the application and cygwin-lstat run in different threads,
 it is even simpler:
 depending on timing, you can end up in example A) with the
 same situation as in example B) :

   application           cydwin
 Thread_1  Thread_2     Thread_X
 CoInit
           lstat   ->   Conint
                    <thread time exeeded>
 CoUninit
                    <thread continues with new time-slice>
                    <process lstat-workload>
                        CoUninit
           lstat   <-  return

 You never know, where you lost CPU and when get it back.
 Note: it did not matter, if Thread_2 and Thread_X are in
 fact the same thread or two different one as shown here.

 This is pretty much the same situation as the second lstat-call
 in your example B).

 So I think, each thread that tries to do COM has to call CoInit
 exactly one time inside cygwin, remeber this fact, and call
 exactly one time CoUninit inside cygwin at thread termination.

 I hope I have not missed some thing important ...


   Bjoern

-- 
+---------------------------------------------------------------------+
| Dipl.-Phys. Bjoern Kahl +++ AG Embedded Systems and Robotics (RESY) |
| Informatics Faculty +++ Building 48 +++ University of Kaiserslautern|
| phone: +49-631-205-2654 +++ www: http://resy.informatik.uni-kl.de   |
+---------------------------------------------------------------------+



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Corinna Vinschen]

On Wed, Sep 04, 2002 at 08:34:10AM +0200, Bjoern Kahl AG Resy wrote:
> I think, there is a missunderstanding on your side, Corinna
> (see below)
> [...]
> As I understand MSDN, the order of CoInit and CoUnint does not
> matter, as long as there is an equal number of CoUninit and CoInit
> at Process termination and the (number of CoUninit) <= (number of
> CoInit) at every other point of time.
> 
> But then your examples are identical. I do not know details of
> the inner cygwin working, so I discuss two possible setups
> [...]
> Note: it did not matter, if Thread_2 and Thread_X are in
> fact the same thread or two different one as shown here.

Basically you're argumentation is right except for the different
threads.  In single-thread apartment mode, which is the only one
supported by CoInit, each thread using COM has to call CoInit 
anyway.

However, I think the better way is to change the code to use
direct calls to ReadFile and to drop usage of COM.  This will
eliminate the whole problem and is likely way faster.

Thanks,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Bjoern Kahl AG Resy]

 Hallo!

On Wed, 4 Sep 2002, Corinna Vinschen wrote:

> On Wed, Sep 04, 2002 at 08:34:10AM +0200, Bjoern Kahl AG Resy wrote:
> > [...]
> > As I understand MSDN, the order of CoInit and CoUnint does not
> > matter, as long as there is an equal number of CoUninit and CoInit
> > at Process termination and the (number of CoUninit) <= (number of
> > CoInit) at every other point of time.
> >
> > But then your examples are identical. I do not know details of
> > the inner cygwin working, so I discuss two possible setups
> > [...]
> > Note: it did not matter, if Thread_2 and Thread_X are in
> > fact the same thread or two different one as shown here.
>
> Basically you're argumentation is right except for the different
> threads.  In single-thread apartment mode, which is the only one
> supported by CoInit, each thread using COM has to call CoInit
> anyway.

 Ok. I silently assumed you use CoInitializeEx with multi-thread
 apartment mode. Seems to was wrong :-)

> However, I think the better way is to change the code to use
> direct calls to ReadFile and to drop usage of COM.  This will
> eliminate the whole problem and is likely way faster.

 Sounds clear.


  Bjoern

-- 
+---------------------------------------------------------------------+
| Dipl.-Phys. Bjoern Kahl +++ AG Embedded Systems and Robotics (RESY) |
| Informatics Faculty +++ Building 48 +++ University of Kaiserslautern|
| phone: +49-631-205-2654 +++ www: http://resy.informatik.uni-kl.de   |
+---------------------------------------------------------------------+



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for cygwin

[Corinna Vinschen]

On Wed, Sep 04, 2002 at 11:10:44AM +0200, Bjoern Kahl AG Resy wrote:
>  Ok. I silently assumed you use CoInitializeEx with multi-thread
>  apartment mode. Seems to was wrong :-)

CoInitEx isn't available on 95.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

BASH slow on network share scripts (was RE: A Simple Real World Benchmark for cygwin)

[Dan Vasaru]

Corinna,

Tnx for taking the trouble of fixing the symlinks. Let's hope it was worth
it :)

I have uncovered another problem now, with the CYGWIN port of bash.
At least when reading/executing a script, bash checks whether the file
descriptor is seekable; if not, it will not perform input buffering of any
kind.

The CYGWIN port of bash short-circuits the test by claiming the input is not
seekable:

bash/input.c
#ifndef __CYGWIN__
#  define fd_is_seekable(fd) (lseek ((fd), 0L, SEEK_CUR) >= 0)
#else
#  define fd_is_seekable(fd) 0
#endif /* __CYGWIN__ */

The result is abysmal performance when the script resides on a network
drive, since bash will read one byte at a time (ultimately resulting in a
network packet per script byte, assuming the OS does not cache the script).

/bin/bash is tens of times slower compared to /bin/sh for an e.g. 200kb
SAMBA-resident script file. I know, it's a BIG script.

Since CYGWIN seems to go to some length to allow O_TEXT seeking, I believe
the ifdef above to be a remnant of some times where cygwin1.dll didn't
support text seeks, and I propose to remove it.

I don't know who to contact on this issue, so someone please notify the
current bash-cygwin maintainer ?

Dan


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: BASH slow on network share scripts (was RE: A Simple Real World Benchmark for cygwin)

[Christopher Faylor]

On Wed, Sep 04, 2002 at 11:44:52PM +0200, Dan Vasaru wrote:
>Since CYGWIN seems to go to some length to allow O_TEXT seeking, I believe
>the ifdef above to be a remnant of some times where cygwin1.dll didn't
>support text seeks, and I propose to remove it.

You're probably right, but since most scripts (such as configure
scripts) are usually interpreted by /bin/sh, which is ash, not bash,
then this shouldn't have much impact on the normal running of scripts.
Unless, of course, there are similar problems in ash.

Still, it would be very nice to get this fixed in bash.

>I don't know who to contact on this issue, so someone please notify the
>current bash-cygwin maintainer ?

You can always check cygwin-announce to find this info, but, really, you
shouldn't have to do that.  Sending email here is the proper way to deal
with the issue.  Sending personal email to a package maintainer should be
the absolute last resort.  Public discussion is good.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Michael Hoffman]

On Mon, 2 Sep 2002, Rick Richardson wrote:

> Certainly, some performance degradation under CygWin could be expected
> and tolerated.  But not a factor of 30X or more.  IMHO, of course.

No! We should not tolerate any performance degradation under Cygwin
WHATSOEVER.  Cygwin should run faster than native Linux. Cygwin should run
faster than native Linux on a faster computer. Cygwin running on an aging
Windows 95 486 with automatic virus checking running should run faster
than a brand-new dual-processor Xeon system running on Linux. If the
developers stopped kicking dogs long enough to actually do some work, this
would already be a reality.

For a slightly more useful response, with slightly less sarcasm (but not
that much less :-]) check:

<http://sources.redhat.com/ml/cygwin/2002-07/msg02076.html>
-- 
Michael Hoffman <grouse@mail.utexas.edu>
The University of Texas at Austin


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Randall R Schulz]

Michael,

You are absolutely right. We (you and I, at least) are Americans, and we 
deserve every last damn thing we want and we deserve it right 
now--yesterday, really.

Based on my experience in data compression, I might be able to help with 
the problem of making Cygwin faster than the software and hardware on which 
it runs. To wit, I've created a compression algorithm that will compress 
any and all inputs to a size smaller than that of the original. I've 
applied this compression to the program itself, iteratively, until I've got 
the whole thing down to one bit.

Here it is: 1. Feel free to use it in any way you wish.

I think that given that I could do this, I can solve the problem that 
Cygwin sometimes fail to complete a computation by the time the enter key 
has returned to its raised position.


My Maxwell's daemon is working well, too. It's nice to have on these hot days.

All the above are patent pending, of course.

Randall Schulz


At 09:06 2002-09-02, Michael Hoffman wrote:
>On Mon, 2 Sep 2002, Rick Richardson wrote:
>
> > Certainly, some performance degradation under CygWin could be expected
> > and tolerated.  But not a factor of 30X or more.  IMHO, of course.
>
>No! We should not tolerate any performance degradation under Cygwin
>WHATSOEVER.  Cygwin should run faster than native Linux. Cygwin should run
>faster than native Linux on a faster computer. Cygwin running on an aging
>Windows 95 486 with automatic virus checking running should run faster
>than a brand-new dual-processor Xeon system running on Linux. If the
>developers stopped kicking dogs long enough to actually do some work, this
>would already be a reality.
>
>For a slightly more useful response, with slightly less sarcasm (but not
>that much less :-]) check:
>
><http://sources.redhat.com/ml/cygwin/2002-07/msg02076.html>
>--
>Michael Hoffman


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Jeremy Hetzler]

At 11:06 AM 9/2/2002 -0500, Michael Hoffman wrote:
>On Mon, 2 Sep 2002, Rick Richardson wrote:
>
> > Certainly, some performance degradation under CygWin could be expected
> > and tolerated.  But not a factor of 30X or more.  IMHO, of course.
>
>No! We should not tolerate any performance degradation under Cygwin
>WHATSOEVER.  Cygwin should run faster than native Linux. Cygwin should run
>faster than native Linux on a faster computer. Cygwin running on an aging
>Windows 95 486 with automatic virus checking running should run faster
>than a brand-new dual-processor Xeon system running on Linux. If the
>developers stopped kicking dogs long enough to actually do some work, this
>would already be a reality.

But the original poster wasn't just saying "Cygwin is slower than Linux" or 
"Cygwin is too slow". He also said:

>It is not entirely clear to me that my performance is representative
>of other CygWin installations.  Without a benchmark, it is impossible
>for me to determine if the results I am seeing are normal for CygWin,
>or the result of some unknown as yet system or installation problem.

Which is a valid point. What is "normal" for Cygwin on given hardware, and 
what is "slower than normal"? Now that we have a benchmark, we can start to 
answer those questions. That's a useful thing.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Eric M. Monsler]

Rick Richardson wrote:
(snip)
> 
>         rm -f config.cache
>         time ./configure


On a PIII 866 MHz, 512 MB Ram, 36Gb SCSI HD (10K RPM?), NT4.0 + SP6, 
only the standard mounts created by setup.

real    0m23.197s
user    0m10.930s
sys     0m6.860s


I hope that this will be a useful thread in the archives for future 
users who find that their 'configure' stages take an unusually long time.

Eric


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Shankar Unni]

Eric M. Monsler wrote:
> Rick Richardson wrote:
>> (snip)
> (snip)

On a PIII, 733MHz, 384MB PC-133 SDRAM, Windows XP (laptop), non-standard 
mounts(*):

real 21.304s
user  9.080s
sys  13.711s

(warmed up, of course:
    rm -f config.cache
    ./configure
    rm -f config.cache
    ./configure   # measured
)

(*) The non-standard mounts are actually sub-optimal, so I'm sure these 
numbers can be beaten:

    % mount
    c: on / type system (textmode)
    d: on /cygdrive/d type system (textmode)

--
Shankar.




--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: A Simple Real World Benchmark for Cygwin

[Randall R Schulz]

Rick,

CPU & RAM:
	P4; 0.13 micron geometry (512K L2 cache); 2.38GHz (2.27 GHz normina)
	140 / 560 (QDR) FSB (overclocked from nominal 133 / 533 MHz)
	PC2700 RAM running 2-2-2-5 RAS/CAS timings

Disk:
	[ 17 Gb
	  10,000 RPM ] x2; Windows and Cygwin on separate spindles
	SCSI Ultra 160
	Adaptec 39160 in a 32-bit PCI slot; non-Ultra-160 devices on separate channel

OS:
	Windows 2K Pro; SP3

SWRB:
	real    0m14.925s
	user    0m12.262s
	sys     0m8.881s

By the way, does anybody see what's wrong with this picture? Is there any 
explanation for how over 21 seconds of CPU time were expended in less than 
15 seconds of clock time?


Randall Schulz
Mountain View, CA USA 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/