[EMAIL PROTECTED] wrote:
Am Montag, 30. Mai 2005 22:33 schrieb Gerrit P. Haase:
Anonymous wrote:
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o cygspd-ne
$ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
$ g++
Am Dienstag, 31. Mai 2005 12:05 schrieb Gerrit P. Haase:
[EMAIL PROTECTED] wrote:
Am Montag, 30. Mai 2005 22:33 schrieb Gerrit P. Haase:
Anonymous wrote:
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o
Ralf Habacker wrote:
Interesting, why is it faster when running a binary that doesn't
depend on cygwin1.dll after swapping the DLL? Some Win caching mechanism?
I recognized this caching behavior with KDE/cygwin too. Under
http://cvs.sourceforge.net/viewcvs.py/kde-cygwin/tools/fillmem/
Am Dienstag, 31. Mai 2005 12:42 schrieb Gerrit P. Haase:
Ralf Habacker wrote:
Interesting, why is it faster when running a binary that doesn't
depend on cygwin1.dll after swapping the DLL? Some Win caching
mechanism?
I recognized this caching behavior with KDE/cygwin too. Under
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o cygspd-ne
$ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
$ g++ -mno-cygwin cygspd.cc -o cygspd-mingw
$ g++ -O7 -mno-cygwin cygspd.cc -o cygspd-mingw-o7
$ g++
Anonymous wrote:
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o cygspd-ne
$ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
$ g++ -mno-cygwin cygspd.cc -o cygspd-mingw
$ g++ -O7 -mno-cygwin cygspd.cc -o cygspd-mingw-o7
Am Montag, 30. Mai 2005 22:33 schrieb Gerrit P. Haase:
Anonymous wrote:
My System:
#Set-up:
$ g++ cygspd.cc -o cygspd-basic
$ g++ -O7 cygspd.cc -o cygspd-o7
$ g++ -fno-exceptions cygspd.cc -o cygspd-ne
$ g++ -O7 -fno-exceptions cygspd.cc -o cygspd-ne-o7
$ g++ -mno-cygwin
Interesting, why is it faster when running a binary that doesn't
depend on cygwin1.dll after swapping the DLL? Some Win caching mechanism?
Repeating many times should minimize any caching:
#New DLL
$ /bin/time -f %E %S %U cygspd-mingw-ne-o7 cygspd.dat
0:04.48 0.01 0.02
0:01.40 0.00 0.02
On Mon, May 30, 2005 at 08:00:35PM -0400, Tacvek wrote:
Interesting, why is it faster when running a binary that doesn't depend
on cygwin1.dll after swapping the DLL? Some Win caching mechanism?
Repeating many times should minimize any caching:
#New DLL
$ /bin/time -f %E %S %U
There is no reason to expect any improvement in mingw programs from my
change.
Yeah i figured that one out. ;)
I was just trying to rationalize the change that I did show in the original
report. My timings don't show great improvement, and a 1 second margin of
error due to windows caching
On Sat, May 28, 2005 at 11:05:23PM -0400, Christopher Faylor wrote:
On Sat, May 28, 2005 at 08:18:46PM -0400, Christopher Faylor wrote:
I have an idea about how to work around this problem but I have to think
about how dangerous it might be. Basically removing the signal handling
wrapper around
Christopher Faylor wrote:
On Sat, May 28, 2005 at 11:05:23PM -0400, Christopher Faylor wrote:
On Sat, May 28, 2005 at 08:18:46PM -0400, Christopher Faylor wrote:
I have an idea about how to work around this problem but I have to think
about how dangerous it might be. Basically removing the
On Sun, May 29, 2005 at 09:37:16PM +0200, Gerrit P. Haase wrote:
Christopher Faylor wrote:
On Sat, May 28, 2005 at 11:05:23PM -0400, Christopher Faylor wrote:
On Sat, May 28, 2005 at 08:18:46PM -0400, Christopher Faylor wrote:
I have an idea about how to work around this problem but I have to
On Sat, May 28, 2005 at 08:18:46PM -0400, Christopher Faylor wrote:
I have an idea about how to work around this problem but I have to think
about how dangerous it might be. Basically removing the signal handling
wrapper around pthread_getspecific and pthread_setspecific. That may
work ok but I
14 matches
Mail list logo
