This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin allocted time slice

On Thu, Jun 14, 2007 at 04:20:04PM +0100, Aaron Gray wrote:
On Thu, Jun 14, 2007 at 04:15:40AM +0100, Aaron Gray wrote:
Cygwin seems to only use a small amount of time slice relative to the
ammount of time slice availiable.  Compiles, builds and testsuite are
relly slow compared to MinGW which takes too much time.

'time' results confirm this.  Process time is about 1/4 of the total
system time.

It i very noticable on compiling and testing GCC as compared to the
same on Linux or MinGW.

Is there any way to give Cygwin a bigger slice of the pie ?

Say 50% or 75% ?

How do you suppose Cygwin is managing this interesting feat of only using some of the CPU time? What Windows API is Cygwin using to just grab a small slice of the time?

Weird I was getting very long compile times for GCC and on using 'time' was
getting indications that make was only getting 25% of total system time.

I'll see if it is repeatable on another system.

As a follow-up question:  Why do you suppose we are punishing you by
not allowing Cygwin to use all of the CPU by default?

Oh. Wait. WJM. Nevermind.

Weird reply, no need to take the micky !

You have apparently made an assumption that Cygwin is purposely using only a part of the CPU. What's weird about asking for your rationale for why anyone would write a program which did such a thing, leaving it to some undocumented procedure to get better performance? Why do you think we wouldn't just make this the default?

In other words: your assumptions don't make a lot of sense.

Here are some better assumptions:

1) Hey!  Maybe, since 'time' is a linux program, whatever is needed to get
it to work accurately isn't well-implemented in Cygwin, so you can't trust
its output.

2) Hey!  I just remembered that Cygwin is an emulation layer on top of
Windows.  That means that there is a lot more code being executed than
would be the case for MinGW!  Maybe *that's* why things are slower!

I'll take option 2, thank you :)


-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]