Hello,
I have to admit that I am a bit surprised by your
comments and those of Christopher Faylor. I found
what seems to me to be a rather serious problem,
reported it, and got flamed and a lecture on
non-constructive criticism. It was not my intent
to criticize nor to be non-constructive.
If someone wishes to flame me on this, please email
the list, otherwise please email me directly as I
am not on the list. My preference is that you not waste
your time in responding to this email.
Concerning gzip.exe and libm.a,
I made the mistake of using WinZip to load the new
release, something that I have done in the past
with success, in this case, it messed up my
installation, so my reports
of problems with gzip.exe and libm.a were bogus -
sorry for the inconvenience. Thanks to the kind
Cygwin user who brought this to my attention.
To respond to your complaints that I did not supply enough
information, below you will find more information.
Concerning my comments about the warning messages. Put
the following lines in x.cpp:
========== begin x.cpp ========
#include <windows.h>
#include <winsock2.h>
========== end x.cpp ==========
Then enter:
gcc x.cpp
and I get the following:
~/apcupsd/k/win32> gcc x.cpp
In file included from x.cpp:4:
/usr/include/w32api/winsock2.h:96: warning: #warning "fd_set and
associated macros have been defined in sys/types. This may cause
runtime problems with W32 sockets"
where I am remarking about the compiler warning not the fact
that it obviously doesn't link (I didn't copy the link errors).
To run the performance tests, which was and is the
only problem that really concerned me, I suggest that you
only need to try timing a fairly comprehensive ./configure
with 1.3.1 cygwin1.dll and with the 1.1.5 dll.
If you want the ./configure I was using, download:
www.sibbald.com/apcupsd/download/betaversions/apcupsd-3.8.2Beta9.tar.gz
extract it with either tar or WinZip, and enter:
time ./configure
if you want to duplicate exactly what I ran, use
time ./kernswinconfig
where I have attached kernswinconfig to this email.
One final thought on this problem. Because doing 30 minute
configures is painful, I installed the Cygwin environment on
my new 700Mhz WinMe notebook and reran the test there hoping
to get a modest speed improvement. To remind
you the tests were originally done on my 400Mhz Win98
Dell Dimension.
I expected to see the time reduced a factor of two or
probably by a bit more. Instead, I saw the time cut from approximately
30 minutes on the Dell to approximately 2 minutes on the
notebook. 15 times faster! To be sure, I repeated the tests on
the Dell and got the same results as previously emailed.
My conclusion without having looked at the source:
most likely 1.3.1 is not or no longer caching accesses to the
registry.
In both cases I am running with:
mount c: /
Regards,
Kern
-----Original Message-----
From: Robert Collins [SMTP:[EMAIL PROTECTED]]
Sent: Monday, 30 April 2001 2:07 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: Some comments about the current release
> -----Original Message-----
> From: Kern Sibbald [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, April 29, 2001 9:31 PM
> To: Robert Collins
> Cc: '[EMAIL PROTECTED]'
> Subject: RE: Some comments about the current release
This is a long one. Summary: Free software project mechanisms
>
> Hello,
>
> If your response is the "official" response, I feel
> sorry for the Cygwin project as the performance problem
> is not my specific problem but a problem in general.
> The test results that I sent were for the execution
> of ./configure, which does not run one line of my
> code (though the precise sequence of calls is determined
> by my configure.in).
I make no "official comments". You've already had those from Chris
Faylor!
As for feeling sorry for the Cygwin project you seem to have some
expectation (I've gone and reread this thread) that cygwin is able to be
improved _for you_ without you providing anything other than
non-constructive criticism.
(constructive critisicm - like a _small_ test case to pinpoint a
problem, or the results of a profile of an operation that is slow for
you can help the developers).
I never stated or implied that the cygwin developers wouldn't look at
the speed issue. It's in discussion _right now_ on the development
mailing list. The archives for that list are open to the public.
What I stated - "We/they might. Of course _you_ are able to get a debug
version of
cygwin1.dll and profile it. You might even see what's affecting you
specifically." - was intended to point out that without feedback and
assistance finding the problem may not be quick and or easy. There are 0
full time cygwin-net-release programmers. Chris is a manager (who codes
quite well :] ), Corinna as I understand it is there for the embedded
system development, but is able to hack on cygwin (For which we should
_all_ be grateful!).
And the rest, well we are all volunteers with some particular itch we
want to scratch.
I know I have little time to contribute, and I certainly will be looking
at the speed issue in that time, but if someone were to profile cygwin
and report back "turning threads on slows make from 30 seconds to 90
seconds" thus pinpointing the threading code.
That would reduce the number of lines of code to be examined to only a
few thousand.
In short the cygwin project depends on you _and_ on the developers.
Without your assistance the project dies.
If you want to be able to say "I hope someone will fix this" you need to
contribute in some fashion. Documentation, mailing list peer support,
testing (I mean detailed testing, not "it's slower :]") all all things
that don't require learning the code base.
If you wish to accept the gift that is cygwin, do not expect to ask for
things changed. It's a two way street.
> Thanks for your advice about pthread_cancel(). I'll
> stop using Cygwin pthreads, which will allow me to go back to
> Cygwin 1.1.5 eliminating the performance penalty.
This doesn't help us find the problem and as such won't help you in the
long run. At this point we don't even know if the performance problem is
in the new threads code/updated security/name any other part of cygwin.
Also: pthread_cancel will be active when I've had time to convert 30 odd
calls in newlib to use cancellation points... you could help do that.
(use the source Kern).
Rob
> Regards,
>
> Kern
>
> -----Original Message-----
> From: Robert Collins [SMTP:[EMAIL PROTECTED]]
> Sent: Sunday, 29 April 2001 10:35 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Some comments about the current release
>
> > -----Original Message-----
> > From: Kern Sibbald [mailto:[EMAIL PROTECTED]]
> > Sent: Sunday, April 29, 2001 6:23 PM
> > To: Robert Collins
> > Cc: '[EMAIL PROTECTED]'
> > Subject: RE: Some comments about the current release
> >
> >
> > Hello Robert,
> >
> > Thanks for the comments.
> >
> > - Oops. I should have asked you to provide a null
> > libpthread.a library (no s).
> >
> > - Perhaps my makefiles were broken in assuming
> > libpthread.a is the library name, but it DOES
> > seem to be commonly used for POSIX threads.
> > Why not make life easier for people like
> > me with "broken" makefiles? Of course, using
> > autoconf, I corrected the problem so it is
> > no longer a problem for me.
>
> sidenote) this translates as "backward compatability".
> a) Search the cygwin mailing list for -lm or libm. See how
> many crashes,
> stackdumps and general other unpleasantness have occured. This problem
> is now fixed, but I have _no_ intention of creating another.
> b) Because I can't be bothered. There I said it. I'm lazy. I'd rather
> code a little more backend support into cygwin than deal with altering
> setup.exe to create another symlink to fix makefiles in
> broken projects
> that are already unportable. I'd rather encourage developers to write
> portable code and portable makefiles. If cygwin was creating
> a *new* way
> of doing it, backwards compatability would be a good answer. As we're
> not... it isn't.
>
> > - I appreciate the improved pthreads support. It seems
> > to function well for the functions I am using.
> > I tried using pthreads in 1.1.5 and saw that it
> > was there, but it lacked pthread_cancel(), which
> > is why I upgraded to 1.3.1.
>
> pthread_cancel is not operational just yet :]. Don't depend
> on it. (See
> thread.cc for comments).
>
> > - My problem with winsock2.h is that I have part
> > of the program that is strictly Microsoft (the
> > part that makes apcupsd a service, handles the tray
> > icon, and the dialog boxes for the tray) and
> > a part that is Unix, which is the vast majority
> > of the program. I know the problem isn't simple
> > but I just wanted to mention it.
>
> Well you mislead us. You stated
> ===
> > 4. I was including <winsock2.h> in a bunch of header files
> > in my .cpp programs which are strictly Windows (no Unix
> > stuff) and I got lots of warning messages, which were
> ===
> which quite clearly indicates that you had "no Unix stuff". You cannot
> expect sensible answers when you provide half the question.
>
> > I hope someone can find a solution for the performance
> > problems with version 1.3.1 cygwin1.dll that I mentioned.
>
> We/they might. Of course _you_ are able to get a debug version of
> cygwin1.dll and profile it. You might even see what's affecting you
> specifically.
>
> Rob
>
>
> > Best regards,
> >
> > Kern
>
begin 600 kernswinconfig
M(R$O8FEN+W-H#0HC(%1H:7,@:7,@2V5R;B=S(&-O;F9I9W5R92!S8W)I<'0@
M9F]R('1H92!7:6XS,B!V97)S:6]N(&]F(&%P8W5P<V0-"BXO8V]N9FEG=7)E
M("UP<F5F:7@]+V%P8W5P<V0@+7-B:6YD:7(]+V%P8W5P<V0O8FEN(%P-"B @
M+7-Y<V-O;F9D:7(]+V%P8W5P<V0O971C+V%P8W5P<V0@+2UW:71H+7!I9"UD
M:7(]+V%P8W5P<V0O971C+V%P8W5P<V0@7 T*(" M+6UA;F1I<CTO87!C=7!S
M9" M+7=I=&@M8V=I+6)I;CTO87!C=7!S9"]E=&,O87!C=7!S9"]C9VD@7 T*
=(" M+65N86)L92UP=&AR96%D<PT*97AI=" P#0HO
`
end
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
