* RE: Old Thread: Cygwin Performance
[not found] <008501c17af9$d044f4f0$8feb85ce@amr.corp.intel.com>
@ 2001-12-02 10:24 ` Ralf Habacker
2001-12-02 12:05 ` Tim Prince
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Ralf Habacker @ 2001-12-02 10:24 UTC (permalink / raw)
To: Tim Prince; +Cc: Cygwin
[-- Attachment #1: Type: text/plain, Size: 6873 bytes --]
> I'd suggest you offer your patch to the lmbench maintainers. At one time,
> they were talking about supporting something for Windows. If they don't
> adopt it, I suppose the other alternative is to offer to maintain a Cygwin
> port as an optional Cygwin package. I'd certainly like to try your version.
Perhaps it is the best, that you look at the patch before offering to the lmbench maintainer.
I should note some things to the patch:
1. It emulates rpc functions by adding a file "lib_cygwin.c" which contains empty rcp_...
functions,
so that the rpc functions are disabled and will not be tested.
2. Because the makefile does not have any platform depending parts, generating lat_rpc.exe is
disabled
3. in scripts/lmbench I have added some ' echo -n "*" ' to enable visible feedback for the
long time execution of some benchmarks.
4. On problem I have recognized is with the "lat_select", it hangs on operation.
5. Because I don't have any compare of lmbench running time on other platforms I can't say if
this is okay. Some benchmarks need several minutes to run, but this may be okay.
Regards
Ralf
> ----- Original Message -----
> From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> To: "Tim Prince" <tprince@computer.org>
> Cc: "Cygwin" <cygwin@sources.redhat.com>
> Sent: Saturday, December 01, 2001 11:44 AM
> Subject: RE: Old Thread: Cygwin Performance
>
>
> > >
> > > cygwin should have made some improvements in piping since then. Amazing
> the
> > > things I had time to do last year. At that time, I got over a few of
> the
> > > linux specific functions by the use of Chuck Wilson's useful packages,
> some
> > > of which should be integrated into cygwin now. I commented out sections
> of
> > > lmbench which I couldn't figure out how to port. This would be a useful
> > > port, particularly in view of the new performance issues brought up by
> XP.
> >
> > I have get running lmbench 2.0 on cygwin with some patches (removing rpc
> functions).
> >
> > Is there anyone who could verify this patch ? To whom should I send this
> patch ?
> >
> > Regards
> > Ralf
> >
> > > However, several of the organizations involved in lmbench are trying to
> stay
> > > clear of Bill Gates' vendetta against use of open software together with
> his
> > > products. I was not employed by such an organization at the time I was
> > > beating on lmbench.
> >
> > > ----- Original Message -----
> > > From: "Piyush Kumar" <piyush@acm.org>
> > > To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> > > Sent: Friday, November 30, 2001 6:49 AM
> > > Subject: Old Thread: Cygwin Performance
> > >
> > >
> > > >
> > > >
> > > > I picked this old thread from Oct 2000!!!
> > > > Tim reports that cygwin falls short by
> > > > performance compared to linux box by a
> > > > factor of 2 using lmbench. Is it still
> > > > the case? Or have things improved since
> > > > Oct 13(Unlucky date!! ;)??
> > > >
> > > > I was trying to compile lmbench 2.0 (Patch 2)
> > > > on my cygwin , no luck!!!! I couldnt compile it!
> > > > Anyone here has tried it before ?? Any luck?
> > > > I would be really interested in a lmbench port
> > > > on cygwin! If someone has already done it , please
> > > > let me know!
> > > >
> > > > Thanks,
> > > > --Piyush
> > > >
> > > >
> > > > =============================================================An Old
> Thread
> > > >
> > > > Re: Cygwin Performance Info
> > > > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey" <cabbey
> at
> > > > chartermi dot net>
> > > > Subject: Re: Cygwin Performance Info
> > > > From: "Tim Prince" <tprince at computer dot org>
> > > > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > > > References: <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> > > >
> > >
> > --------------------------------------------------------------------------
> > > --
> > > > ----
> > > >
> > > > When I attempted to run lmbench on this old box both under linux and
> cygwi
> > > n,
> > > > there were some tests on which cygwin/w2k fell short of linux by a
> factor
> > > of
> > > > 2 or more (opening files, pipe throughput, and the like), and then
> there
> > > > were the cache statistics on which cygwin beat linux by a small
> margin. I
> > > > was expecting lmbench to become better adapted to cygwin, but I have
> no
> > > news
> > > > there.
> > > > ----- Original Message -----
> > > > From: "Chris Abbey" <cabbey@chartermi.net>
> > > > To: <cygwin@sourceware.cygnus.com>
> > > > Sent: Friday, October 13, 2000 4:51 PM
> > > > Subject: Re: Cygwin Performance Info
> > > >
> > > >
> > > > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > > > >Can someone tell me where the performance hit is in cygwin unix
> > > > > >emulation?
> > > > >
> > > > > whichever part you use the most inside your tightest inner loop.
> > > > >
> > > > > seriously.
> > > > >
> > > > > that's a big huge open ended question (not about cygwin, about ANY
> > > > > library/platform) that is as specific to your application as you can
> > > > > get. For example, if you spend 75% of your computing day
> manipulating
> > > > > text files and piping them and greping them and running file utils
> > > > > against them then the cr/lf translation may be a big hit for you.
> > > > > On the otherhand if most of your computation in a day is spent
> answering
> > > > > requests that come in on tcp/ip sockets then the remapping of
> winsock
> > > > > to netinet.h functions maybe your major headache. (note, I'm not
> trying
> > > > > to imply that either function has a performance problem, merely that
> > > they
> > > > > would be representative places that would have high invocation
> counts
> > > > > in the course of the given activity.)
> > > > >
> > > > > To really answer that for your application/workload then you need to
> > > > > get some form of performance detailing that can tell you how much
> time
> > > > > you are spending in any given method and how often it's called.
> > > > >
> > > > >
> > > > > --
> > > > > Want to unsubscribe from this list?
> > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > > >
> > > >
> > > > --
> > > > 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/
> > >
> > >
>
>
> --
> 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/
>
>
[-- Attachment #2: lmbench-2.0-p1-cygwin.dif --]
[-- Type: application/octet-stream, Size: 7416 bytes --]
--- ./scripts/lmbench Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./scripts/lmbench Fri Nov 30 20:02:40 2001
@@ -111,19 +111,34 @@
date >> ${OUTPUT}
echo Latency measurements >> ${OUTPUT}
+echo -n "*"
lat_syscall null
+echo -n "*"
lat_syscall read
+echo -n "*"
lat_syscall write
+echo -n "*"
lat_syscall stat $STAT
+echo -n "*"
lat_syscall fstat $STAT
+echo -n "*"
lat_syscall open $STAT
+echo -n "*"
for i in 10 100 250 500; do lat_select file $i; done
+echo -n "*"
for i in 10 100 250 500; do lat_select tcp $i; done
+echo -n "*"
lat_sig install
+echo -n "*"
lat_sig catch
+echo -n "*"
+echo -n "*"
lat_sig prot lat_sig
+echo -n "*"
lat_pipe
+echo -n "*"
lat_unix
+echo -n "*"
cp hello /tmp/hello
for i in fork exec shell; do lat_proc $i; done
rm /tmp/hello
@@ -141,6 +156,7 @@
lat_fs $FSDIR
echo "" 1>&2
fi
+echo -n "*"
if [ X"$DISKS" != X ]
then for i in $DISKS
@@ -151,6 +167,7 @@
fi
done
fi
+echo -n "*"
date >> ${OUTPUT}
echo Local networking >> ${OUTPUT}
@@ -166,19 +183,31 @@
for i in localhost
do
lat_udp $i
+echo -n "*"
lat_udp -$i
+echo -n "*"
lat_tcp $i
+echo -n "*"
lat_tcp -$i
+echo -n "*"
lat_rpc $i
+echo -n "*"
lat_rpc -$i
+echo -n "*"
lat_connect $i
+echo -n "*"
lat_connect -$i
+echo -n "*"
bw_tcp $i
+echo -n "*"
bw_tcp -$i
# I want a hot cache number
lat_http $i 8008 < ../../src/webpage-lm/URLS > /dev/null 2>&1
+echo -n "*"
lat_http $i 8008 < ../../src/webpage-lm/URLS
+echo -n "*"
lat_http -$i 8008
+echo -n "*"
done
for remote in $REMOTE
@@ -190,15 +219,24 @@
$RSH $remote -n 'cd /tmp; tar xf webpage-lm.tar; cd webpage-lm; ../lmhttp 8008' &
sleep 10
echo "[ Networking remote to $remote: `$RSH $remote uname -a` ]" 1>&2
+echo -n "*"
lat_udp $remote; lat_udp -$remote;
+echo -n "*"
lat_tcp $remote; lat_tcp -$remote;
+echo -n "*"
lat_rpc $remote udp; lat_rpc $remote tcp; lat_rpc -$remote;
+echo -n "*"
lat_connect $remote; lat_connect -$remote;
+echo -n "*"
bw_tcp $remote; bw_tcp -$remote
# I want a hot cache number
+echo -n "*"
lat_http $remote 8008 < ../../src/webpage-lm/URLS > /dev/null 2>&1
+echo -n "*"
lat_http $remote 8008 < ../../src/webpage-lm/URLS
+echo -n "*"
lat_http -$remote 8008
+echo -n "*"
RM=
for server in $SERVERS
do RM="/tmp/$server $RM"
@@ -209,55 +247,71 @@
date >> ${OUTPUT}
echo Bandwidth measurements >> ${OUTPUT}
bw_unix
+echo -n "*"
bw_pipe
+echo -n "*"
echo "" 1>&2
echo \"read bandwidth 1>&2
for i in $ALL; do bw_file_rd $i io_only $FILE; done
echo "" 1>&2
+echo -n "*"
echo "" 1>&2
echo \"read open2close bandwidth 1>&2
for i in $ALL; do bw_file_rd $i open2close $FILE; done
echo "" 1>&2
+echo -n "*"
echo \"Mmap read bandwidth 1>&2
for i in $ALL; do bw_mmap_rd $i mmap_only $FILE; done
echo "" 1>&2
+echo -n "*"
echo \"Mmap read open2close bandwidth 1>&2
for i in $ALL; do bw_mmap_rd $i open2close $FILE; done
echo "" 1>&2
rm -f $FILE
+echo -n "*"
echo \"libc bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i bcopy; done; echo "" 1>&2
+echo -n "*"
echo \"libc bcopy aligned 1>&2
for i in $HALF; do bw_mem $i bcopy conflict; done; echo "" 1>&2
+echo -n "*"
echo \"unrolled bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i fcp; done; echo "" 1>&2
+echo -n "*"
echo \"unrolled partial bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i cp; done; echo "" 1>&2
+echo -n "*"
echo "Memory read bandwidth" 1>&2
for i in $ALL; do bw_mem $i frd; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial read bandwidth" 1>&2
for i in $ALL; do bw_mem $i rd; done; echo "" 1>&2
+echo -n "*"
echo "Memory write bandwidth" 1>&2
for i in $ALL; do bw_mem $i fwr; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial write bandwidth" 1>&2
for i in $ALL; do bw_mem $i wr; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial read/write bandwidth" 1>&2
for i in $ALL; do bw_mem $i rdwr; done; echo "" 1>&2
+echo -n "*"
echo "Memory bzero bandwidth" 1>&2
for i in $ALL; do bw_mem $i bzero; done; echo "" 1>&2
+echo -n "*"
date >> ${OUTPUT}
msleep 250
--- ./src/bench.h Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/bench.h Fri Nov 30 17:05:38 2001
@@ -34,9 +34,13 @@
#include <sys/socket.h>
#include <sys/un.h>
#include <sys/resource.h>
+#ifdef __CYGWIN__
+#include <w32api/rpc.h>
+#else
#define PORTMAP
#include <rpc/rpc.h>
#endif
+#endif
#ifndef HAVE_uint
typedef unsigned int uint;
@@ -239,9 +243,9 @@
* Please do not edit this file.
* It was generated using rpcgen.
*/
-
+#ifndef __CYGWIN__
#include <rpc/types.h>
-
+#endif
#define XACT_PROG ((u_long)404040)
#define XACT_VERS ((u_long)1)
#define RPC_XACT ((u_long)1)
--- ./src/lib_timing.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_timing.c Fri Nov 30 17:10:03 2001
@@ -857,7 +857,7 @@
}
}
-#if defined(hpux) || defined(__hpux)
+#if defined(hpux) || defined(__hpux) && !defined(__CYGWIN__)
int
getpagesize()
{
@@ -865,7 +865,7 @@
}
#endif
-#ifdef WIN32
+#if defined(WIN32) && !defined(__CYGWIN__)
int
getpagesize()
{
--- ./src/Makefile Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/Makefile Fri Nov 30 17:20:39 2001
@@ -56,7 +56,7 @@
memsize.c bw_unix.c lat_unix.c lmdd.c loop_o.c timing_o.c \
timing.h stats.h lib_tcp.h lib_udp.h enough.c lat_select.c \
msleep.c bw_mem.c lat_fifo.c lmhttp.c lat_http.c \
- disk.c flushdisk.c lat_unix_connect.c lib_unix.c lib_stats.c \
+ disk.c flushdisk.c lat_unix_connect.c lib_unix.c lib_stats.c lib_cygwin.c \
lib_unix.h names.h version.h
EXES = $O/bw_file_rd $O/bw_mem $O/bw_mmap_rd $O/bw_pipe $O/bw_tcp \
@@ -82,7 +82,7 @@
$D/lmbench.8 $D/disk.8 $D/lmdd.8 $D/mhz.8 \
$D/clock.8 $D/enough.8 $D/loop_o.8 $D/timing_o.8
-LIBOBJS= $O/lib_tcp.o $O/lib_udp.o $O/lib_unix.o $O/lib_timing.o $O/lib_stats.o
+LIBOBJS= $O/lib_tcp.o $O/lib_udp.o $O/lib_unix.o $O/lib_timing.o $O/lib_stats.o $O/lib_cygwin.o
lmbench: $(UTILS)
@env CFLAGS=-O MAKE="$(MAKE)" MAKEFLAGS="$(MAKEFLAGS)" ../scripts/build all
@@ -196,6 +196,9 @@
$O/lib_stats.o : lib_stats.c $(INCS)
$(COMPILE) -c lib_stats.c -o $O/lib_stats.o
+$O/lib_cygwin.o : lib_cygwin.c $(INCS)
+ $(COMPILE) -c lib_cygwin.c -o $O/lib_cygwin.o
+
# Do not remove the next line, $(MAKE) depend needs it
# MAKEDEPEND follows
$O/rhttp: rhttp.c timing.h stats.h bench.h $O/lmbench.a
@@ -292,7 +295,7 @@
$(COMPILE) -o $O/lat_proc lat_proc.c $O/lmbench.a $(LDLIBS)
$O/lat_rpc: lat_rpc.c timing.h stats.h bench.h $O/lmbench.a
- $(COMPILE) -o $O/lat_rpc lat_rpc.c $O/lmbench.a $(LDLIBS)
+# $(COMPILE) -o $O/lat_rpc lat_rpc.c $O/lmbench.a $(LDLIBS)
$O/lat_sig: lat_sig.c timing.h stats.h bench.h $O/lmbench.a
$(COMPILE) -o $O/lat_sig lat_sig.c $O/lmbench.a $(LDLIBS)
--- ./src/timing.h Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/timing.h Fri Nov 30 17:10:18 2001
@@ -42,7 +42,7 @@
uint64 usecs_spent(void);
void touch(char *buf, int size);
-#if defined(hpux) || defined(__hpux) || defined(WIN32)
+#if defined(hpux) || defined(__hpux) || (defined(WIN32) && !defined(__CYGWIN__))
int getpagesize();
#endif
[-- 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: Cygwin Performance
2001-12-02 10:24 ` Old Thread: Cygwin Performance Ralf Habacker
@ 2001-12-02 12:05 ` Tim Prince
2001-12-02 13:58 ` Tim Prince
2002-01-28 8:39 ` Old Thread: Cygwin Performance Ralf Habacker
2 siblings, 0 replies; 17+ messages in thread
From: Tim Prince @ 2001-12-02 12:05 UTC (permalink / raw)
To: Ralf Habacker; +Cc: Cygwin
Thanks. I take it that your patches are for the lmbench/old/lmbench-2.0
"stable" release, which I have just now downloaded. I agree in principle
with your comments, according to my previous experience. I did not
understand, from the comments of others, how they expected to deal with the
rpc in a Windows port.
As this could relate to a task which I currently have at the office, I may
be able to try this on more recent ia hardware, but I will start out on the
P-III laptop. Actually, my current problem is at least partly associated
with TCP/IP latencies, and I must check to what extent lmbench may
contribute to measuring them. The performance problem appears to be of
similar magnitude on Win2K and redhat 7.1, but it will be important to see
if it increases in relative importance on newer hardware or on XP.
----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
To: "Tim Prince" <tprince@computer.org>
Cc: "Cygwin" <cygwin@sources.redhat.com>
Sent: Sunday, December 02, 2001 10:29 AM
Subject: RE: Old Thread: Cygwin Performance
> > I'd suggest you offer your patch to the lmbench maintainers. At one
time,
> > they were talking about supporting something for Windows. If they don't
> > adopt it, I suppose the other alternative is to offer to maintain a
Cygwin
> > port as an optional Cygwin package. I'd certainly like to try your
version.
>
> Perhaps it is the best, that you look at the patch before offering to the
lmbench maintainer.
> I should note some things to the patch:
>
> 1. It emulates rpc functions by adding a file "lib_cygwin.c" which
contains empty rcp_...
> functions,
> so that the rpc functions are disabled and will not be tested.
>
> 2. Because the makefile does not have any platform depending parts,
generating lat_rpc.exe is
> disabled
>
> 3. in scripts/lmbench I have added some ' echo -n "*" ' to enable visible
feedback for the
> long time execution of some benchmarks.
>
> 4. On problem I have recognized is with the "lat_select", it hangs on
operation.
>
> 5. Because I don't have any compare of lmbench running time on other
platforms I can't say if
> this is okay. Some benchmarks need several minutes to run, but this may be
okay.
>
> Regards
> Ralf
>
> > ----- Original Message -----
> > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > To: "Tim Prince" <tprince@computer.org>
> > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > Sent: Saturday, December 01, 2001 11:44 AM
> > Subject: RE: Old Thread: Cygwin Performance
> >
> >
> > > >
> > > > cygwin should have made some improvements in piping since then.
Amazing
> > the
> > > > things I had time to do last year. At that time, I got over a few
of
> > the
> > > > linux specific functions by the use of Chuck Wilson's useful
packages,
> > some
> > > > of which should be integrated into cygwin now. I commented out
sections
> > of
> > > > lmbench which I couldn't figure out how to port. This would be a
useful
> > > > port, particularly in view of the new performance issues brought up
by
> > XP.
> > >
> > > I have get running lmbench 2.0 on cygwin with some patches (removing
rpc
> > functions).
> > >
> > > Is there anyone who could verify this patch ? To whom should I send
this
> > patch ?
> > >
> > > Regards
> > > Ralf
> > >
> > > > However, several of the organizations involved in lmbench are trying
to
> > stay
> > > > clear of Bill Gates' vendetta against use of open software together
with
> > his
> > > > products. I was not employed by such an organization at the time I
was
> > > > beating on lmbench.
> > >
> > > > ----- Original Message -----
> > > > From: "Piyush Kumar" <piyush@acm.org>
> > > > To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> > > > Sent: Friday, November 30, 2001 6:49 AM
> > > > Subject: Old Thread: Cygwin Performance
> > > >
> > > >
> > > > >
> > > > >
> > > > > I picked this old thread from Oct 2000!!!
> > > > > Tim reports that cygwin falls short by
> > > > > performance compared to linux box by a
> > > > > factor of 2 using lmbench. Is it still
> > > > > the case? Or have things improved since
> > > > > Oct 13(Unlucky date!! ;)??
> > > > >
> > > > > I was trying to compile lmbench 2.0 (Patch 2)
> > > > > on my cygwin , no luck!!!! I couldnt compile it!
> > > > > Anyone here has tried it before ?? Any luck?
> > > > > I would be really interested in a lmbench port
> > > > > on cygwin! If someone has already done it , please
> > > > > let me know!
> > > > >
> > > > > Thanks,
> > > > > --Piyush
> > > > >
> > > > >
> > > > > =============================================================An
Old
> > Thread
> > > > >
> > > > > Re: Cygwin Performance Info
> > > > > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey"
<cabbey
> > at
> > > > > chartermi dot net>
> > > > > Subject: Re: Cygwin Performance Info
> > > > > From: "Tim Prince" <tprince at computer dot org>
> > > > > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > > > > References:
<4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> > > > >
> > > >
> >
> --------------------------------------------------------------------------
> > > > --
> > > > > ----
> > > > >
> > > > > When I attempted to run lmbench on this old box both under linux
and
> > cygwi
> > > > n,
> > > > > there were some tests on which cygwin/w2k fell short of linux by a
> > factor
> > > > of
> > > > > 2 or more (opening files, pipe throughput, and the like), and then
> > there
> > > > > were the cache statistics on which cygwin beat linux by a small
> > margin. I
> > > > > was expecting lmbench to become better adapted to cygwin, but I
have
> > no
> > > > news
> > > > > there.
> > > > > ----- Original Message -----
> > > > > From: "Chris Abbey" <cabbey@chartermi.net>
> > > > > To: <cygwin@sourceware.cygnus.com>
> > > > > Sent: Friday, October 13, 2000 4:51 PM
> > > > > Subject: Re: Cygwin Performance Info
> > > > >
> > > > >
> > > > > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > > > > >Can someone tell me where the performance hit is in cygwin unix
> > > > > > >emulation?
> > > > > >
> > > > > > whichever part you use the most inside your tightest inner loop.
> > > > > >
> > > > > > seriously.
> > > > > >
> > > > > > that's a big huge open ended question (not about cygwin, about
ANY
> > > > > > library/platform) that is as specific to your application as you
can
> > > > > > get. For example, if you spend 75% of your computing day
> > manipulating
> > > > > > text files and piping them and greping them and running file
utils
> > > > > > against them then the cr/lf translation may be a big hit for
you.
> > > > > > On the otherhand if most of your computation in a day is spent
> > answering
> > > > > > requests that come in on tcp/ip sockets then the remapping of
> > winsock
> > > > > > to netinet.h functions maybe your major headache. (note, I'm not
> > trying
> > > > > > to imply that either function has a performance problem, merely
that
> > > > they
> > > > > > would be representative places that would have high invocation
> > counts
> > > > > > in the course of the given activity.)
> > > > > >
> > > > > > To really answer that for your application/workload then you
need to
> > > > > > get some form of performance detailing that can tell you how
much
> > time
> > > > > > you are spending in any given method and how often it's called.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Want to unsubscribe from this list?
> > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > > > >
> > > > >
> > > > > --
> > > > > 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/
> > > >
> > > >
> >
> >
> > --
> > 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: Cygwin Performance
2001-12-02 10:24 ` Old Thread: Cygwin Performance Ralf Habacker
2001-12-02 12:05 ` Tim Prince
@ 2001-12-02 13:58 ` Tim Prince
2001-12-04 7:19 ` Ralf Habacker
2002-01-28 8:39 ` Old Thread: Cygwin Performance Ralf Habacker
2 siblings, 1 reply; 17+ messages in thread
From: Tim Prince @ 2001-12-02 13:58 UTC (permalink / raw)
To: Ralf Habacker; +Cc: Cygwin
Your patch adds lib_cygwin.c to the list of required source files, yet that
new file is not included. Also, it causes Makefile to invoke the 'get -s'
command, of whose function I am not aware.
On my laptop, running linux, the lmbench-2beta2 version corrects a hang in
the "stable version" code which makes a network connection. Perhaps that is
not supported anyway in your cygwin version.
----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
To: "Tim Prince" <tprince@computer.org>
Cc: "Cygwin" <cygwin@sources.redhat.com>
Sent: Sunday, December 02, 2001 10:29 AM
Subject: RE: Old Thread: Cygwin Performance
> > I'd suggest you offer your patch to the lmbench maintainers. At one
time,
> > they were talking about supporting something for Windows. If they don't
> > adopt it, I suppose the other alternative is to offer to maintain a
Cygwin
> > port as an optional Cygwin package. I'd certainly like to try your
version.
>
> Perhaps it is the best, that you look at the patch before offering to the
lmbench maintainer.
> I should note some things to the patch:
>
> 1. It emulates rpc functions by adding a file "lib_cygwin.c" which
contains empty rcp_...
> functions,
> so that the rpc functions are disabled and will not be tested.
>
> 2. Because the makefile does not have any platform depending parts,
generating lat_rpc.exe is
> disabled
>
> 3. in scripts/lmbench I have added some ' echo -n "*" ' to enable visible
feedback for the
> long time execution of some benchmarks.
>
> 4. On problem I have recognized is with the "lat_select", it hangs on
operation.
>
> 5. Because I don't have any compare of lmbench running time on other
platforms I can't say if
> this is okay. Some benchmarks need several minutes to run, but this may be
okay.
>
> Regards
> Ralf
>
> > ----- Original Message -----
> > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > To: "Tim Prince" <tprince@computer.org>
> > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > Sent: Saturday, December 01, 2001 11:44 AM
> > Subject: RE: Old Thread: Cygwin Performance
> >
> >
> > > >
> > > > cygwin should have made some improvements in piping since then.
Amazing
> > the
> > > > things I had time to do last year. At that time, I got over a few
of
> > the
> > > > linux specific functions by the use of Chuck Wilson's useful
packages,
> > some
> > > > of which should be integrated into cygwin now. I commented out
sections
> > of
> > > > lmbench which I couldn't figure out how to port. This would be a
useful
> > > > port, particularly in view of the new performance issues brought up
by
> > XP.
> > >
> > > I have get running lmbench 2.0 on cygwin with some patches (removing
rpc
> > functions).
> > >
> > > Is there anyone who could verify this patch ? To whom should I send
this
> > patch ?
> > >
> > > Regards
> > > Ralf
> > >
> > > > However, several of the organizations involved in lmbench are trying
to
> > stay
> > > > clear of Bill Gates' vendetta against use of open software together
with
> > his
> > > > products. I was not employed by such an organization at the time I
was
> > > > beating on lmbench.
> > >
> > > > ----- Original Message -----
> > > > From: "Piyush Kumar" <piyush@acm.org>
> > > > To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> > > > Sent: Friday, November 30, 2001 6:49 AM
> > > > Subject: Old Thread: Cygwin Performance
> > > >
> > > >
> > > > >
> > > > >
> > > > > I picked this old thread from Oct 2000!!!
> > > > > Tim reports that cygwin falls short by
> > > > > performance compared to linux box by a
> > > > > factor of 2 using lmbench. Is it still
> > > > > the case? Or have things improved since
> > > > > Oct 13(Unlucky date!! ;)??
> > > > >
> > > > > I was trying to compile lmbench 2.0 (Patch 2)
> > > > > on my cygwin , no luck!!!! I couldnt compile it!
> > > > > Anyone here has tried it before ?? Any luck?
> > > > > I would be really interested in a lmbench port
> > > > > on cygwin! If someone has already done it , please
> > > > > let me know!
> > > > >
> > > > > Thanks,
> > > > > --Piyush
> > > > >
> > > > >
> > > > > =============================================================An
Old
> > Thread
> > > > >
> > > > > Re: Cygwin Performance Info
> > > > > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey"
<cabbey
> > at
> > > > > chartermi dot net>
> > > > > Subject: Re: Cygwin Performance Info
> > > > > From: "Tim Prince" <tprince at computer dot org>
> > > > > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > > > > References:
<4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> > > > >
> > > >
> >
> --------------------------------------------------------------------------
> > > > --
> > > > > ----
> > > > >
> > > > > When I attempted to run lmbench on this old box both under linux
and
> > cygwi
> > > > n,
> > > > > there were some tests on which cygwin/w2k fell short of linux by a
> > factor
> > > > of
> > > > > 2 or more (opening files, pipe throughput, and the like), and then
> > there
> > > > > were the cache statistics on which cygwin beat linux by a small
> > margin. I
> > > > > was expecting lmbench to become better adapted to cygwin, but I
have
> > no
> > > > news
> > > > > there.
> > > > > ----- Original Message -----
> > > > > From: "Chris Abbey" <cabbey@chartermi.net>
> > > > > To: <cygwin@sourceware.cygnus.com>
> > > > > Sent: Friday, October 13, 2000 4:51 PM
> > > > > Subject: Re: Cygwin Performance Info
> > > > >
> > > > >
> > > > > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > > > > >Can someone tell me where the performance hit is in cygwin unix
> > > > > > >emulation?
> > > > > >
> > > > > > whichever part you use the most inside your tightest inner loop.
> > > > > >
> > > > > > seriously.
> > > > > >
> > > > > > that's a big huge open ended question (not about cygwin, about
ANY
> > > > > > library/platform) that is as specific to your application as you
can
> > > > > > get. For example, if you spend 75% of your computing day
> > manipulating
> > > > > > text files and piping them and greping them and running file
utils
> > > > > > against them then the cr/lf translation may be a big hit for
you.
> > > > > > On the otherhand if most of your computation in a day is spent
> > answering
> > > > > > requests that come in on tcp/ip sockets then the remapping of
> > winsock
> > > > > > to netinet.h functions maybe your major headache. (note, I'm not
> > trying
> > > > > > to imply that either function has a performance problem, merely
that
> > > > they
> > > > > > would be representative places that would have high invocation
> > counts
> > > > > > in the course of the given activity.)
> > > > > >
> > > > > > To really answer that for your application/workload then you
need to
> > > > > > get some form of performance detailing that can tell you how
much
> > time
> > > > > > you are spending in any given method and how often it's called.
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Want to unsubscribe from this list?
> > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > > > >
> > > > >
> > > > > --
> > > > > 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/
> > > >
> > > >
> >
> >
> > --
> > 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/
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: Cygwin Performance
2001-12-02 13:58 ` Tim Prince
@ 2001-12-04 7:19 ` Ralf Habacker
2001-12-04 16:44 ` Tim Prince
` (2 more replies)
0 siblings, 3 replies; 17+ messages in thread
From: Ralf Habacker @ 2001-12-04 7:19 UTC (permalink / raw)
To: Cygwin
[-- Attachment #1: Type: text/plain, Size: 9089 bytes --]
> -----Original Message-----
> From: Tim Prince [mailto:tprince@computer.org]
> Sent: Sunday, December 02, 2001 10:58 PM
> To: Ralf Habacker
> Cc: Cygwin
> Subject: Re: Old Thread: Cygwin Performance
>
>
> Your patch adds lib_cygwin.c to the list of required source files, yet that
> new file is not included.
Sorry, I've only compared the original source files with the patched, so it fall through.
It's appended.
> Also, it causes Makefile to invoke the 'get -s' command, of whose function I am not aware.
I'm not aware too, I have recognized this in the Makefile, but I have ignored this :-)
>
> On my laptop, running linux, the lmbench-2beta2 version corrects a hang in
> the "stable version" code which makes a network connection. Perhaps that is
> not supported anyway in your cygwin version.
> ----- Original Message -----
> From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> To: "Tim Prince" <tprince@computer.org>
> Cc: "Cygwin" <cygwin@sources.redhat.com>
> Sent: Sunday, December 02, 2001 10:29 AM
> Subject: RE: Old Thread: Cygwin Performance
>
>
> > > I'd suggest you offer your patch to the lmbench maintainers. At one
> time,
> > > they were talking about supporting something for Windows. If they don't
> > > adopt it, I suppose the other alternative is to offer to maintain a
> Cygwin
> > > port as an optional Cygwin package. I'd certainly like to try your
> version.
> >
> > Perhaps it is the best, that you look at the patch before offering to the
> lmbench maintainer.
> > I should note some things to the patch:
> >
> > 1. It emulates rpc functions by adding a file "lib_cygwin.c" which
> contains empty rcp_...
> > functions,
> > so that the rpc functions are disabled and will not be tested.
> >
> > 2. Because the makefile does not have any platform depending parts,
> generating lat_rpc.exe is
> > disabled
> >
> > 3. in scripts/lmbench I have added some ' echo -n "*" ' to enable visible
> feedback for the
> > long time execution of some benchmarks.
> >
> > 4. On problem I have recognized is with the "lat_select", it hangs on
> operation.
> >
> > 5. Because I don't have any compare of lmbench running time on other
> platforms I can't say if
> > this is okay. Some benchmarks need several minutes to run, but this may be
> okay.
> >
> > Regards
> > Ralf
> >
> > > ----- Original Message -----
> > > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > > To: "Tim Prince" <tprince@computer.org>
> > > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > > Sent: Saturday, December 01, 2001 11:44 AM
> > > Subject: RE: Old Thread: Cygwin Performance
> > >
> > >
> > > > >
> > > > > cygwin should have made some improvements in piping since then.
> Amazing
> > > the
> > > > > things I had time to do last year. At that time, I got over a few
> of
> > > the
> > > > > linux specific functions by the use of Chuck Wilson's useful
> packages,
> > > some
> > > > > of which should be integrated into cygwin now. I commented out
> sections
> > > of
> > > > > lmbench which I couldn't figure out how to port. This would be a
> useful
> > > > > port, particularly in view of the new performance issues brought up
> by
> > > XP.
> > > >
> > > > I have get running lmbench 2.0 on cygwin with some patches (removing
> rpc
> > > functions).
> > > >
> > > > Is there anyone who could verify this patch ? To whom should I send
> this
> > > patch ?
> > > >
> > > > Regards
> > > > Ralf
> > > >
> > > > > However, several of the organizations involved in lmbench are trying
> to
> > > stay
> > > > > clear of Bill Gates' vendetta against use of open software together
> with
> > > his
> > > > > products. I was not employed by such an organization at the time I
> was
> > > > > beating on lmbench.
> > > >
> > > > > ----- Original Message -----
> > > > > From: "Piyush Kumar" <piyush@acm.org>
> > > > > To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> > > > > Sent: Friday, November 30, 2001 6:49 AM
> > > > > Subject: Old Thread: Cygwin Performance
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > I picked this old thread from Oct 2000!!!
> > > > > > Tim reports that cygwin falls short by
> > > > > > performance compared to linux box by a
> > > > > > factor of 2 using lmbench. Is it still
> > > > > > the case? Or have things improved since
> > > > > > Oct 13(Unlucky date!! ;)??
> > > > > >
> > > > > > I was trying to compile lmbench 2.0 (Patch 2)
> > > > > > on my cygwin , no luck!!!! I couldnt compile it!
> > > > > > Anyone here has tried it before ?? Any luck?
> > > > > > I would be really interested in a lmbench port
> > > > > > on cygwin! If someone has already done it , please
> > > > > > let me know!
> > > > > >
> > > > > > Thanks,
> > > > > > --Piyush
> > > > > >
> > > > > >
> > > > > > =============================================================An
> Old
> > > Thread
> > > > > >
> > > > > > Re: Cygwin Performance Info
> > > > > > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey"
> <cabbey
> > > at
> > > > > > chartermi dot net>
> > > > > > Subject: Re: Cygwin Performance Info
> > > > > > From: "Tim Prince" <tprince at computer dot org>
> > > > > > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > > > > > References:
> <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> > > > > >
> > > > >
> > >
> > --------------------------------------------------------------------------
> > > > > --
> > > > > > ----
> > > > > >
> > > > > > When I attempted to run lmbench on this old box both under linux
> and
> > > cygwi
> > > > > n,
> > > > > > there were some tests on which cygwin/w2k fell short of linux by a
> > > factor
> > > > > of
> > > > > > 2 or more (opening files, pipe throughput, and the like), and then
> > > there
> > > > > > were the cache statistics on which cygwin beat linux by a small
> > > margin. I
> > > > > > was expecting lmbench to become better adapted to cygwin, but I
> have
> > > no
> > > > > news
> > > > > > there.
> > > > > > ----- Original Message -----
> > > > > > From: "Chris Abbey" <cabbey@chartermi.net>
> > > > > > To: <cygwin@sourceware.cygnus.com>
> > > > > > Sent: Friday, October 13, 2000 4:51 PM
> > > > > > Subject: Re: Cygwin Performance Info
> > > > > >
> > > > > >
> > > > > > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > > > > > >Can someone tell me where the performance hit is in cygwin unix
> > > > > > > >emulation?
> > > > > > >
> > > > > > > whichever part you use the most inside your tightest inner loop.
> > > > > > >
> > > > > > > seriously.
> > > > > > >
> > > > > > > that's a big huge open ended question (not about cygwin, about
> ANY
> > > > > > > library/platform) that is as specific to your application as you
> can
> > > > > > > get. For example, if you spend 75% of your computing day
> > > manipulating
> > > > > > > text files and piping them and greping them and running file
> utils
> > > > > > > against them then the cr/lf translation may be a big hit for
> you.
> > > > > > > On the otherhand if most of your computation in a day is spent
> > > answering
> > > > > > > requests that come in on tcp/ip sockets then the remapping of
> > > winsock
> > > > > > > to netinet.h functions maybe your major headache. (note, I'm not
> > > trying
> > > > > > > to imply that either function has a performance problem, merely
> that
> > > > > they
> > > > > > > would be representative places that would have high invocation
> > > counts
> > > > > > > in the course of the given activity.)
> > > > > > >
> > > > > > > To really answer that for your application/workload then you
> need to
> > > > > > > get some form of performance detailing that can tell you how
> much
> > > time
> > > > > > > you are spending in any given method and how often it's called.
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Want to unsubscribe from this list?
> > > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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/
> > > > >
> > > > >
> > >
> > >
> > > --
> > > 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/
>
>
[-- Attachment #2: lib_cygwin.c --]
[-- Type: application/octet-stream, Size: 220 bytes --]
#include "bench.h"
void pmap_unset(u_long prog, u_long b)
{
}
int pmap_set( u_long prog, u_long b, u_long c)
{
return 0;
}
int pmap_getport(struct sockaddr_in *s, u_long prog, u_long b, u_long c)
{
return 0;
}
[-- 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: Cygwin Performance
2001-12-04 7:19 ` Ralf Habacker
@ 2001-12-04 16:44 ` Tim Prince
2001-12-04 21:27 ` Tim Prince
2001-12-05 12:56 ` Tim Prince
2 siblings, 0 replies; 17+ messages in thread
From: Tim Prince @ 2001-12-04 16:44 UTC (permalink / raw)
To: Ralf Habacker, Cygwin
Thanks, this got it started. I may be able to try a few runs by the end of
the day.
----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
To: "Cygwin" <cygwin@sources.redhat.com>
Sent: Tuesday, December 04, 2001 7:13 AM
Subject: RE: Old Thread: Cygwin Performance
> > -----Original Message-----
> > From: Tim Prince [mailto:tprince@computer.org]
> > Sent: Sunday, December 02, 2001 10:58 PM
> > To: Ralf Habacker
> > Cc: Cygwin
> > Subject: Re: Old Thread: Cygwin Performance
> >
> >
> > Your patch adds lib_cygwin.c to the list of required source files, yet
that
> > new file is not included.
>
> Sorry, I've only compared the original source files with the patched, so
it fall through.
> It's appended.
>
> > Also, it causes Makefile to invoke the 'get -s' command, of whose
function I am not aware.
>
> I'm not aware too, I have recognized this in the Makefile, but I have
ignored this :-)
> >
> > On my laptop, running linux, the lmbench-2beta2 version corrects a hang
in
> > the "stable version" code which makes a network connection. Perhaps
that is
> > not supported anyway in your cygwin version.
>
> > ----- Original Message -----
> > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > To: "Tim Prince" <tprince@computer.org>
> > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > Sent: Sunday, December 02, 2001 10:29 AM
> > Subject: RE: Old Thread: Cygwin Performance
> >
> >
> > > > I'd suggest you offer your patch to the lmbench maintainers. At one
> > time,
> > > > they were talking about supporting something for Windows. If they
don't
> > > > adopt it, I suppose the other alternative is to offer to maintain a
> > Cygwin
> > > > port as an optional Cygwin package. I'd certainly like to try your
> > version.
> > >
> > > Perhaps it is the best, that you look at the patch before offering to
the
> > lmbench maintainer.
> > > I should note some things to the patch:
> > >
> > > 1. It emulates rpc functions by adding a file "lib_cygwin.c" which
> > contains empty rcp_...
> > > functions,
> > > so that the rpc functions are disabled and will not be tested.
> > >
> > > 2. Because the makefile does not have any platform depending parts,
> > generating lat_rpc.exe is
> > > disabled
> > >
> > > 3. in scripts/lmbench I have added some ' echo -n "*" ' to enable
visible
> > feedback for the
> > > long time execution of some benchmarks.
> > >
> > > 4. On problem I have recognized is with the "lat_select", it hangs on
> > operation.
> > >
> > > 5. Because I don't have any compare of lmbench running time on other
> > platforms I can't say if
> > > this is okay. Some benchmarks need several minutes to run, but this
may be
> > okay.
> > >
> > > Regards
> > > Ralf
> > >
> > > > ----- Original Message -----
> > > > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > > > To: "Tim Prince" <tprince@computer.org>
> > > > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > > > Sent: Saturday, December 01, 2001 11:44 AM
> > > > Subject: RE: Old Thread: Cygwin Performance
> > > >
> > > >
> > > > > >
> > > > > > cygwin should have made some improvements in piping since then.
> > Amazing
> > > > the
> > > > > > things I had time to do last year. At that time, I got over a
few
> > of
> > > > the
> > > > > > linux specific functions by the use of Chuck Wilson's useful
> > packages,
> > > > some
> > > > > > of which should be integrated into cygwin now. I commented out
> > sections
> > > > of
> > > > > > lmbench which I couldn't figure out how to port. This would be
a
> > useful
> > > > > > port, particularly in view of the new performance issues brought
up
> > by
> > > > XP.
> > > > >
> > > > > I have get running lmbench 2.0 on cygwin with some patches
(removing
> > rpc
> > > > functions).
> > > > >
> > > > > Is there anyone who could verify this patch ? To whom should I
send
> > this
> > > > patch ?
> > > > >
> > > > > Regards
> > > > > Ralf
> > > > >
> > > > > > However, several of the organizations involved in lmbench are
trying
> > to
> > > > stay
> > > > > > clear of Bill Gates' vendetta against use of open software
together
> > with
> > > > his
> > > > > > products. I was not employed by such an organization at the
time I
> > was
> > > > > > beating on lmbench.
> > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Piyush Kumar" <piyush@acm.org>
> > > > > > To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> > > > > > Sent: Friday, November 30, 2001 6:49 AM
> > > > > > Subject: Old Thread: Cygwin Performance
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I picked this old thread from Oct 2000!!!
> > > > > > > Tim reports that cygwin falls short by
> > > > > > > performance compared to linux box by a
> > > > > > > factor of 2 using lmbench. Is it still
> > > > > > > the case? Or have things improved since
> > > > > > > Oct 13(Unlucky date!! ;)??
> > > > > > >
> > > > > > > I was trying to compile lmbench 2.0 (Patch 2)
> > > > > > > on my cygwin , no luck!!!! I couldnt compile it!
> > > > > > > Anyone here has tried it before ?? Any luck?
> > > > > > > I would be really interested in a lmbench port
> > > > > > > on cygwin! If someone has already done it , please
> > > > > > > let me know!
> > > > > > >
> > > > > > > Thanks,
> > > > > > > --Piyush
> > > > > > >
> > > > > > >
> > > > > > >
=============================================================An
> > Old
> > > > Thread
> > > > > > >
> > > > > > > Re: Cygwin Performance Info
> > > > > > > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey"
> > <cabbey
> > > > at
> > > > > > > chartermi dot net>
> > > > > > > Subject: Re: Cygwin Performance Info
> > > > > > > From: "Tim Prince" <tprince at computer dot org>
> > > > > > > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > > > > > > References:
> > <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> > > > > > >
> > > > > >
> > > >
> >
> --------------------------------------------------------------------------
> > > > > > --
> > > > > > > ----
> > > > > > >
> > > > > > > When I attempted to run lmbench on this old box both under
linux
> > and
> > > > cygwi
> > > > > > n,
> > > > > > > there were some tests on which cygwin/w2k fell short of linux
by a
> > > > factor
> > > > > > of
> > > > > > > 2 or more (opening files, pipe throughput, and the like), and
then
> > > > there
> > > > > > > were the cache statistics on which cygwin beat linux by a
small
> > > > margin. I
> > > > > > > was expecting lmbench to become better adapted to cygwin, but
I
> > have
> > > > no
> > > > > > news
> > > > > > > there.
> > > > > > > ----- Original Message -----
> > > > > > > From: "Chris Abbey" <cabbey@chartermi.net>
> > > > > > > To: <cygwin@sourceware.cygnus.com>
> > > > > > > Sent: Friday, October 13, 2000 4:51 PM
> > > > > > > Subject: Re: Cygwin Performance Info
> > > > > > >
> > > > > > >
> > > > > > > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > > > > > > >Can someone tell me where the performance hit is in cygwin
unix
> > > > > > > > >emulation?
> > > > > > > >
> > > > > > > > whichever part you use the most inside your tightest inner
loop.
> > > > > > > >
> > > > > > > > seriously.
> > > > > > > >
> > > > > > > > that's a big huge open ended question (not about cygwin,
about
> > ANY
> > > > > > > > library/platform) that is as specific to your application as
you
> > can
> > > > > > > > get. For example, if you spend 75% of your computing day
> > > > manipulating
> > > > > > > > text files and piping them and greping them and running file
> > utils
> > > > > > > > against them then the cr/lf translation may be a big hit for
> > you.
> > > > > > > > On the otherhand if most of your computation in a day is
spent
> > > > answering
> > > > > > > > requests that come in on tcp/ip sockets then the remapping
of
> > > > winsock
> > > > > > > > to netinet.h functions maybe your major headache. (note, I'm
not
> > > > trying
> > > > > > > > to imply that either function has a performance problem,
merely
> > that
> > > > > > they
> > > > > > > > would be representative places that would have high
invocation
> > > > counts
> > > > > > > > in the course of the given activity.)
> > > > > > > >
> > > > > > > > To really answer that for your application/workload then you
> > need to
> > > > > > > > get some form of performance detailing that can tell you how
> > much
> > > > time
> > > > > > > > you are spending in any given method and how often it's
called.
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Want to unsubscribe from this list?
> > > > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 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/
> > > > > >
> > > > > >
> > > >
> > > >
> > > > --
> > > > 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/
> >
> >
>
----------------------------------------------------------------------------
----
> --
> 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: Cygwin Performance
2001-12-04 7:19 ` Ralf Habacker
2001-12-04 16:44 ` Tim Prince
@ 2001-12-04 21:27 ` Tim Prince
2001-12-05 12:56 ` Tim Prince
2 siblings, 0 replies; 17+ messages in thread
From: Tim Prince @ 2001-12-04 21:27 UTC (permalink / raw)
To: Ralf Habacker, Cygwin
[-- Attachment #1: Type: text/plain, Size: 10665 bytes --]
I suggest the timing be done using the lmbench replacement for
gettimeofday() in terms of Windows QueryPerformance() calls, as attached.
This provides sufficient timer resolution to perform the tests quickly,
obtain accurate cache latency data, and make the cpu clock rate detection
work as well as on linux.
Unfortunately, some of the file system and communication latencies appear to
be way out of line. You do have as many or more tests working correctly as
I have seen in attempts to port earlier lmbench versions to Windows.
----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
To: "Cygwin" <cygwin@sources.redhat.com>
Sent: Tuesday, December 04, 2001 7:13 AM
Subject: RE: Old Thread: Cygwin Performance
> > -----Original Message-----
> > From: Tim Prince [mailto:tprince@computer.org]
> > Sent: Sunday, December 02, 2001 10:58 PM
> > To: Ralf Habacker
> > Cc: Cygwin
> > Subject: Re: Old Thread: Cygwin Performance
> >
> >
> > Your patch adds lib_cygwin.c to the list of required source files, yet
that
> > new file is not included.
>
> Sorry, I've only compared the original source files with the patched, so
it fall through.
> It's appended.
>
> > Also, it causes Makefile to invoke the 'get -s' command, of whose
function I am not aware.
>
> I'm not aware too, I have recognized this in the Makefile, but I have
ignored this :-)
> >
> > On my laptop, running linux, the lmbench-2beta2 version corrects a hang
in
> > the "stable version" code which makes a network connection. Perhaps
that is
> > not supported anyway in your cygwin version.
>
> > ----- Original Message -----
> > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > To: "Tim Prince" <tprince@computer.org>
> > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > Sent: Sunday, December 02, 2001 10:29 AM
> > Subject: RE: Old Thread: Cygwin Performance
> >
> >
> > > > I'd suggest you offer your patch to the lmbench maintainers. At one
> > time,
> > > > they were talking about supporting something for Windows. If they
don't
> > > > adopt it, I suppose the other alternative is to offer to maintain a
> > Cygwin
> > > > port as an optional Cygwin package. I'd certainly like to try your
> > version.
> > >
> > > Perhaps it is the best, that you look at the patch before offering to
the
> > lmbench maintainer.
> > > I should note some things to the patch:
> > >
> > > 1. It emulates rpc functions by adding a file "lib_cygwin.c" which
> > contains empty rcp_...
> > > functions,
> > > so that the rpc functions are disabled and will not be tested.
> > >
> > > 2. Because the makefile does not have any platform depending parts,
> > generating lat_rpc.exe is
> > > disabled
> > >
> > > 3. in scripts/lmbench I have added some ' echo -n "*" ' to enable
visible
> > feedback for the
> > > long time execution of some benchmarks.
> > >
> > > 4. On problem I have recognized is with the "lat_select", it hangs on
> > operation.
> > >
> > > 5. Because I don't have any compare of lmbench running time on other
> > platforms I can't say if
> > > this is okay. Some benchmarks need several minutes to run, but this
may be
> > okay.
> > >
> > > Regards
> > > Ralf
> > >
> > > > ----- Original Message -----
> > > > From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> > > > To: "Tim Prince" <tprince@computer.org>
> > > > Cc: "Cygwin" <cygwin@sources.redhat.com>
> > > > Sent: Saturday, December 01, 2001 11:44 AM
> > > > Subject: RE: Old Thread: Cygwin Performance
> > > >
> > > >
> > > > > >
> > > > > > cygwin should have made some improvements in piping since then.
> > Amazing
> > > > the
> > > > > > things I had time to do last year. At that time, I got over a
few
> > of
> > > > the
> > > > > > linux specific functions by the use of Chuck Wilson's useful
> > packages,
> > > > some
> > > > > > of which should be integrated into cygwin now. I commented out
> > sections
> > > > of
> > > > > > lmbench which I couldn't figure out how to port. This would be
a
> > useful
> > > > > > port, particularly in view of the new performance issues brought
up
> > by
> > > > XP.
> > > > >
> > > > > I have get running lmbench 2.0 on cygwin with some patches
(removing
> > rpc
> > > > functions).
> > > > >
> > > > > Is there anyone who could verify this patch ? To whom should I
send
> > this
> > > > patch ?
> > > > >
> > > > > Regards
> > > > > Ralf
> > > > >
> > > > > > However, several of the organizations involved in lmbench are
trying
> > to
> > > > stay
> > > > > > clear of Bill Gates' vendetta against use of open software
together
> > with
> > > > his
> > > > > > products. I was not employed by such an organization at the
time I
> > was
> > > > > > beating on lmbench.
> > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "Piyush Kumar" <piyush@acm.org>
> > > > > > To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> > > > > > Sent: Friday, November 30, 2001 6:49 AM
> > > > > > Subject: Old Thread: Cygwin Performance
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I picked this old thread from Oct 2000!!!
> > > > > > > Tim reports that cygwin falls short by
> > > > > > > performance compared to linux box by a
> > > > > > > factor of 2 using lmbench. Is it still
> > > > > > > the case? Or have things improved since
> > > > > > > Oct 13(Unlucky date!! ;)??
> > > > > > >
> > > > > > > I was trying to compile lmbench 2.0 (Patch 2)
> > > > > > > on my cygwin , no luck!!!! I couldnt compile it!
> > > > > > > Anyone here has tried it before ?? Any luck?
> > > > > > > I would be really interested in a lmbench port
> > > > > > > on cygwin! If someone has already done it , please
> > > > > > > let me know!
> > > > > > >
> > > > > > > Thanks,
> > > > > > > --Piyush
> > > > > > >
> > > > > > >
> > > > > > >
=============================================================An
> > Old
> > > > Thread
> > > > > > >
> > > > > > > Re: Cygwin Performance Info
> > > > > > > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey"
> > <cabbey
> > > > at
> > > > > > > chartermi dot net>
> > > > > > > Subject: Re: Cygwin Performance Info
> > > > > > > From: "Tim Prince" <tprince at computer dot org>
> > > > > > > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > > > > > > References:
> > <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> > > > > > >
> > > > > >
> > > >
> >
> --------------------------------------------------------------------------
> > > > > > --
> > > > > > > ----
> > > > > > >
> > > > > > > When I attempted to run lmbench on this old box both under
linux
> > and
> > > > cygwi
> > > > > > n,
> > > > > > > there were some tests on which cygwin/w2k fell short of linux
by a
> > > > factor
> > > > > > of
> > > > > > > 2 or more (opening files, pipe throughput, and the like), and
then
> > > > there
> > > > > > > were the cache statistics on which cygwin beat linux by a
small
> > > > margin. I
> > > > > > > was expecting lmbench to become better adapted to cygwin, but
I
> > have
> > > > no
> > > > > > news
> > > > > > > there.
> > > > > > > ----- Original Message -----
> > > > > > > From: "Chris Abbey" <cabbey@chartermi.net>
> > > > > > > To: <cygwin@sourceware.cygnus.com>
> > > > > > > Sent: Friday, October 13, 2000 4:51 PM
> > > > > > > Subject: Re: Cygwin Performance Info
> > > > > > >
> > > > > > >
> > > > > > > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > > > > > > >Can someone tell me where the performance hit is in cygwin
unix
> > > > > > > > >emulation?
> > > > > > > >
> > > > > > > > whichever part you use the most inside your tightest inner
loop.
> > > > > > > >
> > > > > > > > seriously.
> > > > > > > >
> > > > > > > > that's a big huge open ended question (not about cygwin,
about
> > ANY
> > > > > > > > library/platform) that is as specific to your application as
you
> > can
> > > > > > > > get. For example, if you spend 75% of your computing day
> > > > manipulating
> > > > > > > > text files and piping them and greping them and running file
> > utils
> > > > > > > > against them then the cr/lf translation may be a big hit for
> > you.
> > > > > > > > On the otherhand if most of your computation in a day is
spent
> > > > answering
> > > > > > > > requests that come in on tcp/ip sockets then the remapping
of
> > > > winsock
> > > > > > > > to netinet.h functions maybe your major headache. (note, I'm
not
> > > > trying
> > > > > > > > to imply that either function has a performance problem,
merely
> > that
> > > > > > they
> > > > > > > > would be representative places that would have high
invocation
> > > > counts
> > > > > > > > in the course of the given activity.)
> > > > > > > >
> > > > > > > > To really answer that for your application/workload then you
> > need to
> > > > > > > > get some form of performance detailing that can tell you how
> > much
> > > > time
> > > > > > > > you are spending in any given method and how often it's
called.
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Want to unsubscribe from this list?
> > > > > > > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > 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/
> > > > > >
> > > > > >
> > > >
> > > >
> > > > --
> > > > 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/
> >
> >
>
----------------------------------------------------------------------------
----
> --
> 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/
[-- Attachment #2: lib_timing.c --]
[-- Type: application/octet-stream, Size: 18144 bytes --]
/*
* a timing utilities library
*
* Requires 64bit integers to work.
*
* %W% %@%
*
* Copyright (c) 1994-1998 Larry McVoy.
*/
#define _LIB /* bench.h needs this */
#include "bench.h"
#define nz(x) ((x) == 0 ? 1 : (x))
/*
* I know you think these should be 2^10 and 2^20, but people are quoting
* disk sizes in powers of 10, and bandwidths are all power of ten.
* Deal with it.
*/
#define MB (1000*1000.0)
#define KB (1000.0)
static struct timeval start_tv, stop_tv;
FILE *ftiming;
volatile uint64 use_result_dummy; /* !static for optimizers. */
static uint64 iterations;
static void init_timing(void);
#if defined(hpux) || defined(__hpux)
#include <sys/mman.h>
#endif
#ifdef RUSAGE
#include <sys/resource.h>
#define SECS(tv) (tv.tv_sec + tv.tv_usec / 1000000.0)
#define mine(f) (int)(ru_stop.f - ru_start.f)
static struct rusage ru_start, ru_stop;
void
rusage(void)
{
double sys, user, idle;
double per;
sys = SECS(ru_stop.ru_stime) - SECS(ru_start.ru_stime);
user = SECS(ru_stop.ru_utime) - SECS(ru_start.ru_utime);
idle = timespent() - (sys + user);
per = idle / timespent() * 100;
if (!ftiming) ftiming = stderr;
fprintf(ftiming, "real=%.2f sys=%.2f user=%.2f idle=%.2f stall=%.0f%% ",
timespent(), sys, user, idle, per);
fprintf(ftiming, "rd=%d wr=%d min=%d maj=%d ctx=%d\n",
mine(ru_inblock), mine(ru_oublock),
mine(ru_minflt), mine(ru_majflt),
mine(ru_nvcsw) + mine(ru_nivcsw));
}
#endif /* RUSAGE */
/*
* Redirect output someplace else.
*/
void
timing(FILE *out)
{
ftiming = out;
}
/*
* Start timing now.
*/
void
start(struct timeval *tv)
{
if (tv == NULL) {
tv = &start_tv;
}
#ifdef RUSAGE
getrusage(RUSAGE_SELF, &ru_start);
#endif
(void) gettimeofday(tv, (struct timezone *) 0);
}
/*
* Stop timing and return real time in microseconds.
*/
uint64
stop(struct timeval *begin, struct timeval *end)
{
if (end == NULL) {
end = &stop_tv;
}
(void) gettimeofday(end, (struct timezone *) 0);
#ifdef RUSAGE
getrusage(RUSAGE_SELF, &ru_stop);
#endif
if (begin == NULL) {
begin = &start_tv;
}
return tvdelta(begin, end);
}
uint64
now(void)
{
struct timeval t;
uint64 m;
(void) gettimeofday(&t, (struct timezone *) 0);
m = t.tv_sec;
m *= 1000000;
m += t.tv_usec;
return (m);
}
double
Now(void)
{
struct timeval t;
(void) gettimeofday(&t, (struct timezone *) 0);
return (t.tv_sec * 1000000.0 + t.tv_usec);
}
uint64
delta(void)
{
static struct timeval last;
struct timeval t;
struct timeval diff;
uint64 m;
(void) gettimeofday(&t, (struct timezone *) 0);
if (last.tv_usec) {
tvsub(&diff, &t, &last);
last = t;
m = diff.tv_sec;
m *= 1000000;
m += diff.tv_usec;
return (m);
} else {
last = t;
return (0);
}
}
double
Delta(void)
{
struct timeval t;
struct timeval diff;
(void) gettimeofday(&t, (struct timezone *) 0);
tvsub(&diff, &t, &start_tv);
return (diff.tv_sec + diff.tv_usec / 1000000.0);
}
void
save_n(uint64 n)
{
iterations = n;
}
uint64
get_n(void)
{
return (iterations);
}
/*
* Make the time spend be usecs.
*/
void
settime(uint64 usecs)
{
bzero((void*)&start_tv, sizeof(start_tv));
stop_tv.tv_sec = usecs / 1000000;
stop_tv.tv_usec = usecs % 1000000;
}
void
bandwidth(uint64 bytes, uint64 times, int verbose)
{
struct timeval tdiff;
double mb, secs;
tvsub(&tdiff, &stop_tv, &start_tv);
secs = tdiff.tv_sec;
secs *= 1000000;
secs += tdiff.tv_usec;
secs /= 1000000;
secs /= times;
mb = bytes / MB;
if (!ftiming) ftiming = stderr;
if (verbose) {
(void) fprintf(ftiming,
"%.4f MB in %.4f secs, %.4f MB/sec\n",
mb, secs, mb/secs);
} else {
if (mb < 1) {
(void) fprintf(ftiming, "%.6f ", mb);
} else {
(void) fprintf(ftiming, "%.2f ", mb);
}
if (mb / secs < 1) {
(void) fprintf(ftiming, "%.6f\n", mb/secs);
} else {
(void) fprintf(ftiming, "%.2f\n", mb/secs);
}
}
}
void
kb(uint64 bytes)
{
struct timeval td;
double s, bs;
tvsub(&td, &stop_tv, &start_tv);
s = td.tv_sec + td.tv_usec / 1000000.0;
bs = bytes / nz(s);
if (!ftiming) ftiming = stderr;
(void) fprintf(ftiming, "%.0f KB/sec\n", bs / KB);
}
void
mb(uint64 bytes)
{
struct timeval td;
double s, bs;
tvsub(&td, &stop_tv, &start_tv);
s = td.tv_sec + td.tv_usec / 1000000.0;
bs = bytes / nz(s);
if (!ftiming) ftiming = stderr;
(void) fprintf(ftiming, "%.2f MB/sec\n", bs / MB);
}
void
latency(uint64 xfers, uint64 size)
{
struct timeval td;
double s;
if (!ftiming) ftiming = stderr;
tvsub(&td, &stop_tv, &start_tv);
s = td.tv_sec + td.tv_usec / 1000000.0;
if (xfers > 1) {
fprintf(ftiming, "%d %dKB xfers in %.2f secs, ",
(int) xfers, (int) (size / KB), s);
} else {
fprintf(ftiming, "%.1fKB in ", size / KB);
}
if ((s * 1000 / xfers) > 100) {
fprintf(ftiming, "%.0f millisec%s, ",
s * 1000 / xfers, xfers > 1 ? "/xfer" : "s");
} else {
fprintf(ftiming, "%.4f millisec%s, ",
s * 1000 / xfers, xfers > 1 ? "/xfer" : "s");
}
if (((xfers * size) / (MB * s)) > 1) {
fprintf(ftiming, "%.2f MB/sec\n", (xfers * size) / (MB * s));
} else {
fprintf(ftiming, "%.2f KB/sec\n", (xfers * size) / (KB * s));
}
}
void
context(uint64 xfers)
{
struct timeval td;
double s;
tvsub(&td, &stop_tv, &start_tv);
s = td.tv_sec + td.tv_usec / 1000000.0;
if (!ftiming) ftiming = stderr;
fprintf(ftiming,
"%d context switches in %.2f secs, %.0f microsec/switch\n",
(int)xfers, s, s * 1000000 / xfers);
}
void
nano(char *s, uint64 n)
{
struct timeval td;
double micro;
tvsub(&td, &stop_tv, &start_tv);
micro = td.tv_sec * 1000000 + td.tv_usec;
micro *= 1000;
if (!ftiming) ftiming = stderr;
fprintf(ftiming, "%s: %.0f nanoseconds\n", s, micro / n);
}
void
micro(char *s, uint64 n)
{
struct timeval td;
double micro;
tvsub(&td, &stop_tv, &start_tv);
micro = td.tv_sec * 1000000 + td.tv_usec;
micro /= n;
if (!ftiming) ftiming = stderr;
fprintf(ftiming, "%s: %.4f microseconds\n", s, micro);
#if 0
if (micro >= 100) {
fprintf(ftiming, "%s: %.1f microseconds\n", s, micro);
} else if (micro >= 10) {
fprintf(ftiming, "%s: %.3f microseconds\n", s, micro);
} else {
fprintf(ftiming, "%s: %.4f microseconds\n", s, micro);
}
#endif
}
void
micromb(uint64 sz, uint64 n)
{
struct timeval td;
double mb, micro;
tvsub(&td, &stop_tv, &start_tv);
micro = td.tv_sec * 1000000 + td.tv_usec;
micro /= n;
mb = sz;
mb /= MB;
if (!ftiming) ftiming = stderr;
if (micro >= 10) {
fprintf(ftiming, "%.6f %.0f\n", mb, micro);
} else {
fprintf(ftiming, "%.6f %.3f\n", mb, micro);
}
}
void
milli(char *s, uint64 n)
{
struct timeval td;
uint64 milli;
tvsub(&td, &stop_tv, &start_tv);
milli = td.tv_sec * 1000 + td.tv_usec / 1000;
milli /= n;
if (!ftiming) ftiming = stderr;
fprintf(ftiming, "%s: %d milliseconds\n", s, (int)milli);
}
void
ptime(uint64 n)
{
struct timeval td;
double s;
tvsub(&td, &stop_tv, &start_tv);
s = td.tv_sec + td.tv_usec / 1000000.0;
if (!ftiming) ftiming = stderr;
fprintf(ftiming,
"%d in %.2f secs, %.0f microseconds each\n",
(int)n, s, s * 1000000 / n);
}
uint64
tvdelta(struct timeval *start, struct timeval *stop)
{
struct timeval td;
uint64 usecs;
tvsub(&td, stop, start);
usecs = td.tv_sec;
usecs *= 1000000;
usecs += td.tv_usec;
return (usecs);
}
void
tvsub(struct timeval * tdiff, struct timeval * t1, struct timeval * t0)
{
tdiff->tv_sec = t1->tv_sec - t0->tv_sec;
tdiff->tv_usec = t1->tv_usec - t0->tv_usec;
if (tdiff->tv_usec < 0 && tdiff->tv_sec > 0) {
tdiff->tv_sec--;
tdiff->tv_usec += 1000000;
assert(tdiff->tv_usec >= 0);
}
/* time shouldn't go backwards!!! */
if (tdiff->tv_usec < 0 || t1->tv_sec < t0->tv_sec) {
tdiff->tv_sec = 0;
tdiff->tv_usec = 0;
}
}
uint64
gettime(void)
{
return (tvdelta(&start_tv, &stop_tv));
}
double
timespent(void)
{
struct timeval td;
tvsub(&td, &stop_tv, &start_tv);
return (td.tv_sec + td.tv_usec / 1000000.0);
}
static char p64buf[10][20];
static int n;
char *
p64(uint64 big)
{
char *s = p64buf[n++];
if (n == 10) n = 0;
#ifdef linux
{
int *a = (int*)&big;
if (a[1]) {
sprintf(s, "0x%x%08x", a[1], a[0]);
} else {
sprintf(s, "0x%x", a[0]);
}
}
#endif
#ifdef __sgi
sprintf(s, "0x%llx", big);
#endif
return (s);
}
char *
p64sz(uint64 big)
{
double d = big;
char *tags = " KMGTPE";
int t = 0;
char *s = p64buf[n++];
if (n == 10) n = 0;
while (d > 512) t++, d /= 1024;
if (d == 0) {
return ("0");
}
if (d < 100) {
sprintf(s, "%.4f%c", d, tags[t]);
} else {
sprintf(s, "%.2f%c", d, tags[t]);
}
return (s);
}
char
last(char *s)
{
while (*s++)
;
return (s[-2]);
}
int
bytes(char *s)
{
int n = atoi(s);
if ((last(s) == 'k') || (last(s) == 'K'))
n *= 1024;
if ((last(s) == 'm') || (last(s) == 'M'))
n *= (1024 * 1024);
return (n);
}
void
use_int(int result) { use_result_dummy += result; }
void
use_pointer(void *result) { use_result_dummy += (int)result; }
void
insertinit(result_t *r)
{
int i;
r->N = 0;
for (i = 0; i < TRIES; i++) {
r->u[i] = 0;
r->n[i] = 1;
}
}
/* biggest to smallest */
void
insertsort(uint64 u, uint64 n, result_t *r)
{
int i, j;
if (u == 0) return;
for (i = 0; i < r->N; ++i) {
if (u/(double)n > r->u[i]/(double)r->n[i]) {
for (j = r->N; j > i; --j) {
r->u[j] = r->u[j-1];
r->n[j] = r->n[j-1];
}
break;
}
}
r->u[i] = u;
r->n[i] = n;
r->N++;
}
static result_t results;
void
print_results(void)
{
int i;
for (i = 0; i < results.N; ++i) {
fprintf(stderr, "%.2f ", (double)results.u[i]/results.n[i]);
}
}
void
get_results(result_t *r)
{
*r = results;
}
void
save_results(result_t *r)
{
results = *r;
save_median();
}
void
save_minimum()
{
if (results.N == 0) {
save_n(1);
settime(0);
} else {
save_n(results.n[results.N - 1]);
settime(results.u[results.N - 1]);
}
}
void
save_median()
{
int i = results.N / 2;
uint64 u, n;
if (results.N == 0) {
n = 1;
u = 0;
} else if (results.N % 2) {
n = results.n[i];
u = results.u[i];
} else {
n = (results.n[i] + results.n[i-1]) / 2;
u = (results.u[i] + results.u[i-1]) / 2;
}
save_n(n); settime(u);
}
/*
* The inner loop tracks bench.h but uses a different results array.
*/
static long *
one_op(register long *p)
{
BENCH_INNER(p = (long *)*p, 0);
return (p);
}
static long *
two_op(register long *p, register long *q)
{
BENCH_INNER(p = (long *)*q; q = (long*)*p, 0);
return (p);
}
static long *p = (long *)&p;
static long *q = (long *)&q;
double
l_overhead(void)
{
int i;
uint64 N_save, u_save;
static double overhead;
static int initialized = 0;
result_t one, two, r_save;
init_timing();
if (initialized) return (overhead);
initialized = 1;
if (getenv("LOOP_O")) {
overhead = atof(getenv("LOOP_O"));
} else {
get_results(&r_save); N_save = get_n(); u_save = gettime();
insertinit(&one);
insertinit(&two);
for (i = 0; i < TRIES; ++i) {
use_pointer((void*)one_op(p));
if (gettime() > t_overhead())
insertsort(gettime() - t_overhead(), get_n(), &one);
use_pointer((void *)two_op(p, q));
if (gettime() > t_overhead())
insertsort(gettime() - t_overhead(), get_n(), &two);
}
/*
* u1 = (n1 * (overhead + work))
* u2 = (n2 * (overhead + 2 * work))
* ==> overhead = 2. * u1 / n1 - u2 / n2
*/
save_results(&one); save_minimum();
overhead = 2. * gettime() / (double)get_n();
save_results(&two); save_minimum();
overhead -= gettime() / (double)get_n();
if (overhead < 0.) overhead = 0.; /* Gag */
save_results(&r_save); save_n(N_save); settime(u_save);
}
return (overhead);
}
/*
* Figure out the timing overhead. This has to track bench.h
*/
uint64
t_overhead(void)
{
uint64 N_save, u_save;
static int initialized = 0;
static uint64 overhead = 0;
struct timeval tv;
result_t r_save;
init_timing();
if (initialized) return (overhead);
initialized = 1;
if (getenv("TIMING_O")) {
overhead = atof(getenv("TIMING_O"));
} else if (get_enough(0) <= 50000) {
/* it is not in the noise, so compute it */
int i;
result_t r;
get_results(&r_save); N_save = get_n(); u_save = gettime();
insertinit(&r);
for (i = 0; i < TRIES; ++i) {
BENCH_INNER(gettimeofday(&tv, 0), 0);
insertsort(gettime(), get_n(), &r);
}
save_results(&r);
save_minimum();
overhead = gettime() / get_n();
save_results(&r_save); save_n(N_save); settime(u_save);
}
return (overhead);
}
/*
* Figure out how long to run it.
* If enough == 0, then they want us to figure it out.
* If enough is !0 then return it unless we think it is too short.
*/
static int long_enough;
static int compute_enough();
int
get_enough(int e)
{
init_timing();
return (long_enough > e ? long_enough : e);
}
static void
init_timing(void)
{
static int done = 0;
if (done) return;
done = 1;
long_enough = compute_enough();
t_overhead();
l_overhead();
}
typedef long TYPE;
static TYPE **
enough_duration(register long N, register TYPE ** p)
{
#define ENOUGH_DURATION_TEN(one) one one one one one one one one one one
while (N-- > 0) {
ENOUGH_DURATION_TEN(p = (TYPE **) *p;);
}
return (p);
}
static uint64
duration(long N)
{
uint64 usecs;
TYPE *x = (TYPE *)&x;
TYPE **p = (TYPE **)&x;
start(0);
p = enough_duration(N, p);
usecs = stop(0, 0);
use_pointer((void *)p);
return (usecs);
}
/*
* find the minimum time that work "N" takes in "tries" tests
*/
static uint64
time_N(long N)
{
int i;
uint64 usecs;
result_t r;
insertinit(&r);
for (i = 1; i < TRIES; ++i) {
usecs = duration(N);
insertsort(usecs, N, &r);
}
save_results(&r);
save_minimum();
return (gettime());
}
/*
* return the amount of work needed to run "enough" microseconds
*/
static long
find_N(int enough)
{
int tries;
static long N = 10000;
static uint64 usecs = 0;
if (!usecs) usecs = time_N(N);
for (tries = 0; tries < 10; ++tries) {
if (0.98 * enough < usecs && usecs < 1.02 * enough)
return (N);
if (usecs < 1000)
N *= 10;
else {
double n = N;
n /= usecs;
n *= enough;
N = n + 1;
}
usecs = time_N(N);
}
return (-1);
}
/*
* We want to verify that small modifications proportionally affect the runtime
*/
static double test_points[] = {1.015, 1.02, 1.035};
static int
test_time(int enough)
{
int i;
long N;
uint64 usecs, expected, baseline, diff;
if ((N = find_N(enough)) <= 0)
return (0);
baseline = time_N(N);
for (i = 0; i < sizeof(test_points) / sizeof(double); ++i) {
usecs = time_N((int)((double) N * test_points[i]));
expected = (uint64)((double)baseline * test_points[i]);
diff = expected > usecs ? expected - usecs : usecs - expected;
if (diff / (double)expected > 0.0025)
return (0);
}
return (1);
}
/*
* We want to find the smallest timing interval that has accurate timing
*/
static int possibilities[] = { 5000, 10000, 50000, 100000 };
static int
compute_enough()
{
int i;
if (getenv("ENOUGH")) {
return (atoi(getenv("ENOUGH")));
}
for (i = 0; i < sizeof(possibilities) / sizeof(int); ++i) {
if (test_time(possibilities[i]))
return (possibilities[i]);
}
/*
* if we can't find a timing interval that is sufficient,
* then use SHORT as a default.
*/
return (SHORT);
}
/*
* This stuff isn't really lib_timing, but ...
*/
void
morefds(void)
{
#ifdef RLIMIT_NOFILE
struct rlimit r;
getrlimit(RLIMIT_NOFILE, &r);
r.rlim_cur = r.rlim_max;
setrlimit(RLIMIT_NOFILE, &r);
#endif
}
void
touch(char *buf, int nbytes)
{
static psize;
if (!psize) {
psize = getpagesize();
}
while (nbytes > 0) {
*buf = 1;
buf += psize;
nbytes -= psize;
}
}
#if defined(hpux) || defined(__hpux)
int
getpagesize()
{
return (sysconf(_SC_PAGE_SIZE));
}
#endif
#if defined(WIN32)
#if !defined(__CYGWIN__)
int
getpagesize()
{
SYSTEM_INFO s;
GetSystemInfo(&s);
return ((int)s.dwPageSize);
}
#endif
LARGE_INTEGER
getFILETIMEoffset()
{
SYSTEMTIME s;
FILETIME f;
LARGE_INTEGER t;
s.wYear = 1970;
s.wMonth = 1;
s.wDay = 1;
s.wHour = 0;
s.wMinute = 0;
s.wSecond = 0;
s.wMilliseconds = 0;
SystemTimeToFileTime(&s, &f);
t.QuadPart = f.dwHighDateTime;
t.QuadPart <<= 32;
t.QuadPart |= f.dwLowDateTime;
return (t);
}
int
gettimeofday(struct timeval *tv, struct timezone *tz)
{
LARGE_INTEGER t;
FILETIME f;
double microseconds;
static LARGE_INTEGER offset;
static double frequencyToMicroseconds;
static int initialized = 0;
static BOOL usePerformanceCounter = 0;
if (!initialized) {
LARGE_INTEGER performanceFrequency;
initialized = 1;
usePerformanceCounter = QueryPerformanceFrequency(&performanceFrequency);
if (usePerformanceCounter) {
QueryPerformanceCounter(&offset);
frequencyToMicroseconds = (double)performanceFrequency.QuadPart / 1000000.;
} else {
offset = getFILETIMEoffset();
frequencyToMicroseconds = 10.;
}
}
if (usePerformanceCounter) QueryPerformanceCounter(&t);
else {
GetSystemTimeAsFileTime(&f);
t.QuadPart = f.dwHighDateTime;
t.QuadPart <<= 32;
t.QuadPart |= f.dwLowDateTime;
}
t.QuadPart -= offset.QuadPart;
microseconds = (double)t.QuadPart / frequencyToMicroseconds;
t.QuadPart = microseconds;
tv->tv_sec = t.QuadPart / 1000000;
tv->tv_usec = t.QuadPart % 1000000;
return (0);
}
#endif
[-- 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: Cygwin Performance
2001-12-04 7:19 ` Ralf Habacker
2001-12-04 16:44 ` Tim Prince
2001-12-04 21:27 ` Tim Prince
@ 2001-12-05 12:56 ` Tim Prince
2002-01-23 0:10 ` Ralf Habacker
2 siblings, 1 reply; 17+ messages in thread
From: Tim Prince @ 2001-12-05 12:56 UTC (permalink / raw)
To: Ralf Habacker, Cygwin
> > -----Original Message-----
> > From: Tim Prince [mailto:tprince@computer.org]
> > Sent: Sunday, December 02, 2001 10:58 PM
> > To: Ralf Habacker
> > Cc: Cygwin
> > Subject: Re: Old Thread: Cygwin Performance
> >
> >
The QueryPerformance() calls are still giving 1.00 second timing resolution
on an AthlonMP box (should be better than 10 microseconds on most other
boxes, with correct usage), but their use appears to be truer to the
original lmbench than the cygwin gettimeofday() with its 1.00 second
resolution.
I believed there were deficiencies in the way lmbench uses
QueryPerformance(), preserving only 31 bits of clock ticks from the time of
initialization, but I didn't succeed in showing any better way.
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: Cygwin Performance
2001-12-05 12:56 ` Tim Prince
@ 2002-01-23 0:10 ` Ralf Habacker
2002-01-26 11:29 ` Ralf Habacker
0 siblings, 1 reply; 17+ messages in thread
From: Ralf Habacker @ 2002-01-23 0:10 UTC (permalink / raw)
To: Cygwin; +Cc: Tim Prince
Hi Tim,
Sorry for late answer, I was busy with other things. Should the link below help with this ? We (the kde-cygwin
team) are using this for a special profiling lib for profiling the kde2 port.
http://www-106.ibm.com/developerworks/library/l-rt1/
Ralf Habacker
kde on cygwin http://kde-cygwin.sf.net
> -----Original Message-----
> From: Tim Prince [mailto:tprince@computer.org]
> Sent: Wednesday, December 05, 2001 9:36 PM
> To: Ralf Habacker; Cygwin
> Subject: Re: Old Thread: Cygwin Performance
>
>
>
> > > -----Original Message-----
> > > From: Tim Prince [mailto:tprince@computer.org]
> > > Sent: Sunday, December 02, 2001 10:58 PM
> > > To: Ralf Habacker
> > > Cc: Cygwin
> > > Subject: Re: Old Thread: Cygwin Performance
> > >
> > >
> The QueryPerformance() calls are still giving 1.00 second timing resolution
> on an AthlonMP box (should be better than 10 microseconds on most other
> boxes, with correct usage), but their use appears to be truer to the
> original lmbench than the cygwin gettimeofday() with its 1.00 second
> resolution.
>
> I believed there were deficiencies in the way lmbench uses
> QueryPerformance(), preserving only 31 bits of clock ticks from the time of
> initialization, but I didn't succeed in showing any better way.
>
>
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: Cygwin Performance
2002-01-23 0:10 ` Ralf Habacker
@ 2002-01-26 11:29 ` Ralf Habacker
2002-01-26 15:54 ` Old Thread: cygwin Performance Christopher Faylor
0 siblings, 1 reply; 17+ messages in thread
From: Ralf Habacker @ 2002-01-26 11:29 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]
Hi all,
while makeing some tests I recognized, that sometime select() and close() crashes, if the number of used file
descriptors is > 60.
With a value >93 select() crashes.
With a value between 61 and 81 a close() call crashes instead of select(), but it seems that this is caused by the
previous select() call.
Appended is a little test app for error reproducing.
$ ./test 60
dup
select
close
close2
$ ./test 61
dup
select
close
Segmentation fault (core dumped)
$ ./test 62
dup
select
close
Segmentation fault (core dumped)
...
$ ./test 81
dup
select
close
Segmentation fault (core dumped)
$ ./test 82
dup
select
close
close2
.....
$ ./test 92
dup
select
close
close2
$ ./test 93
dup
select
Segmentation fault (core dumped)
The select() crashes in the cygwin1.dll in the method "select_stuff::~select_stuff" like shown in the strace
snippet below
4604 7210385 [main] lat_select 2308 set_bits: ready 1
4401 7214786 [main] lat_select 2308 set_bits: me 0xA011808, testing fd 7 (/tmp/t904.0)
4738 7219524 [main] lat_select 2308 set_bits: ready 1
4472 7223996 [main] lat_select 2308 set_bits: me 0xA0117D8, testing fd 6 (/tmp/t904.0)
4487 7228483 [main] lat_select 2308 set_bits: ready 1
4573 7233056 [main] lat_select 2308 set_bits: me 0xA0117A8, testing fd 5 (/tmp/t904.0)
4601 7237657 [main] lat_select 2308 set_bits: ready 1
4601 7242258 [main] lat_select 2308 set_bits: me 0xA011778, testing fd 4 (/tmp/t904.0)
4422 7246680 [main] lat_select 2308 set_bits: ready 1
4597 7251277 [main] lat_select 2308 select_stuff::poll: returning 75
4576 7255853 [main] lat_select 2308 select_stuff::cleanup: calling cleanup routines
4623 7260476 [main] lat_select 2308 select_stuff::~select_stuff: deleting select records
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
14184 7274660 [main] lat_select 2308 handle_exceptions: In cygwin_except_handler exc 0xC0000005 at 0xB0 sp 0x22F91C
I hope this help to fix this bug
Ralf
[-- Attachment #2: test.c --]
[-- Type: application/octet-stream, Size: 901 bytes --]
#include <sys/types.h>
#include <sys/time.h>
#include <sys/fcntl.h>
#include <stdio.h>
fd_set set;
void
doit(int n, fd_set *set)
{
fd_set nosave = *set;
static struct timeval tv;
select(n, 0, &nosave, 0, &tv);
}
main(int ac, char **av)
{
char c;
int n, N, nfds,fd, fid;
char fname[L_tmpnam];
// morefds();
N = 61;
fname[0] = 0;
nfds = 0;
FD_ZERO(&set);
/* Create a temporary file for clients to open */
tmpnam(fname);
fd = open(fname, O_RDWR|O_APPEND|O_CREAT, 0666);
unlink(fname);
if (ac == 2) N = atoi(av[1]);
printf("dup\n");
for (n = 0; n < N; n++) {
fid = dup(fd);
if (fid == -1) break;
if (fid >= nfds) nfds = fid + 1;
FD_SET(fid, &set);
}
// BENCH(doit(nfds,&set), 0);
printf("select\n");
doit(nfds,&set);
printf("close\n");
for (fid = 0; fid < nfds; fid++) {
if (FD_ISSET(fid, &set)) {
close(fid);
}
}
printf("close2\n");
close(fd);
exit(0);
}
[-- 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: cygwin Performance
2002-01-26 11:29 ` Ralf Habacker
@ 2002-01-26 15:54 ` Christopher Faylor
2002-01-27 1:30 ` Ralf Habacker
0 siblings, 1 reply; 17+ messages in thread
From: Christopher Faylor @ 2002-01-26 15:54 UTC (permalink / raw)
To: cygwin
On Sat, Jan 26, 2002 at 08:14:47PM +0100, Ralf Habacker wrote:
>while makeing some tests I recognized, that sometime select() and
>close() crashes, if the number of used file descriptors is > 60.
grep /usr/include/sys/types.h for "FD_SETSIZE". You'll note that it is,
by default, 64. Set it to something higher, before invoking sys/types.h
if you need something higher.
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: cygwin Performance
2002-01-26 15:54 ` Old Thread: cygwin Performance Christopher Faylor
@ 2002-01-27 1:30 ` Ralf Habacker
0 siblings, 0 replies; 17+ messages in thread
From: Ralf Habacker @ 2002-01-27 1:30 UTC (permalink / raw)
To: cygwin
>
> On Sat, Jan 26, 2002 at 08:14:47PM +0100, Ralf Habacker wrote:
> >while makeing some tests I recognized, that sometime select() and
> >close() crashes, if the number of used file descriptors is > 60.
>
> grep /usr/include/sys/types.h for "FD_SETSIZE". You'll note that it is,
> by default, 64. Set it to something higher, before invoking sys/types.h
> if you need something higher.
Thanks
Ralf
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: Cygwin Performance
2001-12-02 10:24 ` Old Thread: Cygwin Performance Ralf Habacker
2001-12-02 12:05 ` Tim Prince
2001-12-02 13:58 ` Tim Prince
@ 2002-01-28 8:39 ` Ralf Habacker
2002-01-30 2:01 ` Ralf Habacker
2 siblings, 1 reply; 17+ messages in thread
From: Ralf Habacker @ 2002-01-28 8:39 UTC (permalink / raw)
To: cygwin
Hi all,
the last days I have run the lmbench benchmark suite with cygwin and Suse Linux 7.1 on a Toshiba Satellite Pro 4300
Serie with PIII 700 MHz, 320 MB RAM.
I was very surprised about the differences in some tests. While some tests produces expected results for example in
the "processor results" there are other tests, about I'm wondering if this is true, like the context
switching, *Local* Communication latencies and *Local* Communication bandwidths.
Because of this, I don't like to comment the results, but I'm asking if anybody else could confirm this results.
BTW: But if this is true, I know why kde2 runs so slowly :-)
Regards
Ralf
L M B E N C H 2 . 0 S U M M A R Y
------------------------------------
Basic system parameters
----------------------------------------------------
Host OS Description Mhz
--------- ------------- ----------------------- ----
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE CYGWIN_NT-5.0 i686-pc-cygwin 696
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
BRAMSCHE Linux 2.2.18 i686-pc-linux-gnu 697
Processor, Processes - times in microseconds - smaller is better
----------------------------------------------------------------
Host OS Mhz null null open selct sig sig fork exec sh
call I/O stat clos TCP inst hndl proc proc proc
--------- ------------- ---- ---- ---- ---- ---- ----- ---- ---- ---- ---- ----
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.24 419. 199. 2357. 0.11 67.0 11.K 20.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.24 389. 201. 1743. 0.11 67.4 11.K 21.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.23 391. 201. 1946. 0.11 67.1 11.K 20.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.24 392. 201. 1821. 0.11 67.6 11.K 21.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.24 393. 200. 2143. 0.11 67.2 11.K 21.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.24 390. 199. 1803. 0.11 67.0 11.K 20.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.25 393. 199. 1825. 0.11 67.1 11.K 21.K 45.K
BRAMSCHE CYGWIN_NT-5.0 696 0.01 1.24 389. 200. 1804. 0.11 66.9 11.K 20.K 45.K
BRAMSCHE Linux 2.2.18 697 0.45 0.62 9.89 42.8 76.9 4.43 12.2 441. 3873 20.K
BRAMSCHE Linux 2.2.18 697 1.64 2.33 41.7 44.8 90.2 4.82 12.2 474. 4453 20.K
BRAMSCHE Linux 2.2.18 697 1.65 2.40 18.1 21.4 76.8 4.71 11.5 463. 4308 19.K
BRAMSCHE Linux 2.2.18 697 1.65 2.37 33.1 38.6 99.3 4.53 11.2 438. 4430 19.K
BRAMSCHE Linux 2.2.18 697 1.65 2.44 35.1 38.9 83.4 4.43 11.9 467. 3821 20.K
BRAMSCHE Linux 2.2.18 697 1.74 2.38 35.0 38.8 72.9 4.73 11.3 439. 3839 20.K
BRAMSCHE Linux 2.2.18 697 1.55 2.47 33.2 38.8 76.8 4.82 12.3 404. 4421 20.K
BRAMSCHE Linux 2.2.18 697 1.64 2.25 33.0 37.4 76.9 4.52 11.8 418. 3807 20.K
Context switching - times in microseconds - smaller is better
-------------------------------------------------------------
Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K
ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw
--------- ------------- ----- ------ ------ ------ ------ ------- -------
BRAMSCHE CYGWIN_NT-5.0 5966. 5966.1 5917.6 4975.1 5200.8 6215.6 5200.8
BRAMSCHE CYGWIN_NT-5.0 4965. 5968.4 5929.4 4986.1 5198.8 4334.6 4323.4
BRAMSCHE CYGWIN_NT-5.0 4972. 5958.1 5948.1 5185.3 4954.6 4468.7 2446.4
BRAMSCHE CYGWIN_NT-5.0 5975. 5960.9 5947.7 4997.9 4958.0 2477.7 4317.9
BRAMSCHE CYGWIN_NT-5.0 5974. 4964.0 5950.3 5745.7 5166.1 5456.8 4428.5
BRAMSCHE CYGWIN_NT-5.0 5969. 5966.3 5940.5 4959.6 4958.1 4466.6 5324.8
BRAMSCHE CYGWIN_NT-5.0 5964. 5833.5 5940.6 4967.7 4955.9 4449.1 4433.3
BRAMSCHE CYGWIN_NT-5.0 4970. 5959.5 5933.2 3177.0 8706.5 4218.8 6200.8
BRAMSCHE Linux 2.2.18 3.290 16.4 29.6 23.4 148.6 191.0 149.2
BRAMSCHE Linux 2.2.18 3.530 12.6 25.1 19.8 161.3 31.4 162.6
BRAMSCHE Linux 2.2.18 3.540 10.3 32.3 17.4 148.9 31.2 149.0
BRAMSCHE Linux 2.2.18 3.310 10.4 44.0 16.6 160.4 31.6 160.0
BRAMSCHE Linux 2.2.18 3.290 18.9 33.0 26.0 147.8 37.4 150.7
BRAMSCHE Linux 2.2.18 3.470 18.1 22.6 15.4 147.7 38.7 147.8
BRAMSCHE Linux 2.2.18 3.310 10.4 45.1 9.6400 180.0 62.2 180.7
BRAMSCHE Linux 2.2.18 3.290 9.7500 55.1 17.7 180.5 30.0 181.0
*Local* Communication latencies in microseconds - smaller is better
-------------------------------------------------------------------
Host OS 2p/0K Pipe AF UDP RPC/ TCP RPC/ TCP
ctxsw UNIX UDP TCP conn
--------- ------------- ----- ----- ---- ----- ----- ----- ----- ----
BRAMSCHE CYGWIN_NT-5.0 5966. 14.7K 14.K 107.5 13.5K 650K
BRAMSCHE CYGWIN_NT-5.0 4965. 14.7K 13.K 107.1 13.5K 650K
BRAMSCHE CYGWIN_NT-5.0 4972. 10.0K 11.K 258.8 13.6K 650K
BRAMSCHE CYGWIN_NT-5.0 5975. 14.9K 14.K 107.3 13.5K 650K
BRAMSCHE CYGWIN_NT-5.0 5974. 14.9K 14.K 106.5 13.3K 550K
BRAMSCHE CYGWIN_NT-5.0 5969. 14.7K 13.K 178.5 13.5K 550K
BRAMSCHE CYGWIN_NT-5.0 5964. 14.7K 11.K 201.1 13.3K 650K
BRAMSCHE CYGWIN_NT-5.0 4970. 14.7K 14.K 107.1 13.5K 550K
BRAMSCHE Linux 2.2.18 3.290 19.2 39.6 76.8 85.3 128.0 238.0 214.
BRAMSCHE Linux 2.2.18 3.530 21.0 22.0 78.5 86.4 133.4 239.1 207.
BRAMSCHE Linux 2.2.18 3.540 18.9 42.3 78.0 85.4 134.0 245.0 211.
BRAMSCHE Linux 2.2.18 3.310 18.0 40.0 76.2 86.1 121.8 234.9 213.
BRAMSCHE Linux 2.2.18 3.290 19.4 18.1 75.9 85.7 122.5 235.2 213.
BRAMSCHE Linux 2.2.18 3.470 18.2 40.8 76.6 84.4 124.5 234.6 217.
BRAMSCHE Linux 2.2.18 3.310 17.9 43.1 76.3 87.0 126.0 235.8 211.
BRAMSCHE Linux 2.2.18 3.290 18.7 41.8 76.4 85.1 126.5 236.2 211.
File & VM system latencies in microseconds - smaller is better
--------------------------------------------------------------
Host OS 0K File 10K File Mmap Prot Page
Create Delete Create Delete Latency Fault Fault
--------- ------------- ------ ------ ------ ------ ------- ----- -----
BRAMSCHE CYGWIN_NT-5.0 5000.0 415.3 29.4K 5263.2 1448.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 684.5 412.0 29.4K 9803.9 1442.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 658.8 412.7 29.4K 9090.9 1442.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 682.1 419.8 31.2K 8695.7 1432.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 661.4 386.8 30.3K 7751.9 1427.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 648.1 405.2 30.3K 8620.7 1445.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 659.2 393.7 29.4K 9434.0 1437.0 5.00000
BRAMSCHE CYGWIN_NT-5.0 706.2 402.1 28.6K 4878.0 1438.0 5.00000
BRAMSCHE Linux 2.2.18 192.2 23.6 403.9 32.2 27.5K 950.0
BRAMSCHE Linux 2.2.18 194.6 24.2 417.0 33.0 23.6K 979.0
BRAMSCHE Linux 2.2.18 200.2 23.7 414.9 32.3 23.1K 939.0
BRAMSCHE Linux 2.2.18 193.1 24.5 411.9 33.1 27.3K 940.0
BRAMSCHE Linux 2.2.18 193.1 24.6 411.4 33.3 28.3K 938.0
BRAMSCHE Linux 2.2.18 193.1 24.7 410.8 33.2 27.3K 940.0
BRAMSCHE Linux 2.2.18 193.2 24.7 411.2 33.2 22.5K 920.0
BRAMSCHE Linux 2.2.18 193.1 24.6 411.4 33.0 27.2K 955.0
*Local* Communication bandwidths in MB/s - bigger is better
-----------------------------------------------------------
Host OS Pipe AF TCP File Mmap Bcopy Bcopy Mem Mem
UNIX reread reread (libc) (hand) read write
--------- ------------- ---- ---- ---- ------ ------ ------ ------ ---- -----
BRAMSCHE CYGWIN_NT-5.0 93.9 17.6 40.7 335.0 477.7 145.0 134.0 477. 195.9
BRAMSCHE CYGWIN_NT-5.0 104. 17.4 40.9 335.7 476.1 141.8 129.7 478. 191.6
BRAMSCHE CYGWIN_NT-5.0 130. 17.5 41.0 338.1 476.0 141.4 129.9 476. 194.3
BRAMSCHE CYGWIN_NT-5.0 130. 17.5 40.4 336.2 477.9 145.1 135.2 478. 201.1
BRAMSCHE CYGWIN_NT-5.0 130. 17.5 40.1 337.5 479.1 145.3 134.4 478. 201.2
BRAMSCHE CYGWIN_NT-5.0 130. 17.5 40.4 335.4 478.1 145.3 134.7 479. 200.8
BRAMSCHE CYGWIN_NT-5.0 130. 17.6 39.7 337.1 478.5 145.3 135.3 476. 200.1
BRAMSCHE CYGWIN_NT-5.0 130. 17.5 40.0 337.0 477.7 145.2 133.8 476. 200.9
BRAMSCHE Linux 2.2.18 343. 235. 64.4 177.7 238.5 71.5 61.4 238. 75.3
BRAMSCHE Linux 2.2.18 345. 225. 53.0 176.4 233.5 73.3 67.0 232. 87.4
BRAMSCHE Linux 2.2.18 326. 227. 57.6 176.4 232.7 75.9 69.0 236. 92.0
BRAMSCHE Linux 2.2.18 349. 154. 61.6 180.1 238.3 74.2 67.1 238. 94.3
BRAMSCHE Linux 2.2.18 341. 134. 41.1 177.8 238.5 74.5 67.0 234. 94.6
BRAMSCHE Linux 2.2.18 344. 198. 58.7 176.9 238.5 74.4 68.3 234. 94.7
BRAMSCHE Linux 2.2.18 343. 231. 42.2 177.6 238.4 73.5 68.0 238. 94.6
BRAMSCHE Linux 2.2.18 341. 218. 42.6 177.8 238.5 74.7 68.1 238. 94.5
Memory latencies in nanoseconds - smaller is better
(WARNING - may not be correct, check graphs)
---------------------------------------------------
Host OS Mhz L1 $ L2 $ Main mem Guesses
--------- ------------- ---- ----- ------ -------- -------
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.7
BRAMSCHE CYGWIN_NT-5.0 696 4.308 10.1 113.5
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.8
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.5
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.5
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.6
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.6
BRAMSCHE CYGWIN_NT-5.0 696 4.309 10.1 113.6
BRAMSCHE Linux 2.2.18 697 9.356 20.2 229.5
BRAMSCHE Linux 2.2.18 697 9.354 20.2 229.4
BRAMSCHE Linux 2.2.18 697 9.348 20.2 229.5
BRAMSCHE Linux 2.2.18 697 9.331 20.2 224.2
BRAMSCHE Linux 2.2.18 697 9.355 20.2 223.8
BRAMSCHE Linux 2.2.18 697 9.356 20.2 223.5
BRAMSCHE Linux 2.2.18 697 4.412 20.2 223.7
BRAMSCHE Linux 2.2.18 697 4.415 20.2 223.5
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: Cygwin Performance
2002-01-28 8:39 ` Old Thread: Cygwin Performance Ralf Habacker
@ 2002-01-30 2:01 ` Ralf Habacker
0 siblings, 0 replies; 17+ messages in thread
From: Ralf Habacker @ 2002-01-30 2:01 UTC (permalink / raw)
To: cygwin
[-- Attachment #1: Type: text/plain, Size: 448 bytes --]
Hi all,
this is my current patch for get running the lmbench-20 patch1 source from http://www.bitmover.com
Content
* initial patches from me.
* Tim Prince lib_timing.c patch.
* patch for disabling rpc checking without adding a new file.
* bug fix of lat_select check (based on a hint of Christopher Failor)
* prelimary fix for printing network informations
Open Things:
* full netstat -i support
* uptime is missing
Have fun
Ralf
[-- Attachment #2: lmbench_2002_01_30.dif --]
[-- Type: text/x-diff, Size: 20548 bytes --]
Common subdirectories: ./BitKeeper and ../LMbench_new/./BitKeeper
Common subdirectories: ./SCCS and ../LMbench_new/./SCCS
Only in ../LMbench_new/.: bin
Common subdirectories: ./doc and ../LMbench_new/./doc
Only in ../LMbench_new/.: lat_pipe.strace
Only in ../LMbench_new/.: lat_unix.strace
Common subdirectories: ./results and ../LMbench_new/./results
Only in ../LMbench_new/.: results.txt
Common subdirectories: ./scripts and ../LMbench_new/./scripts
Common subdirectories: ./src and ../LMbench_new/./src
Common subdirectories: ./BitKeeper/deleted and ../LMbench_new/./BitKeeper/deleted
Common subdirectories: ./BitKeeper/etc and ../LMbench_new/./BitKeeper/etc
Common subdirectories: ./BitKeeper/log and ../LMbench_new/./BitKeeper/log
Common subdirectories: ./BitKeeper/tmp and ../LMbench_new/./BitKeeper/tmp
Common subdirectories: ./BitKeeper/deleted/SCCS and ../LMbench_new/./BitKeeper/deleted/SCCS
Common subdirectories: ./BitKeeper/etc/SCCS and ../LMbench_new/./BitKeeper/etc/SCCS
Only in ../LMbench_new/./doc: Makefile.bak
Common subdirectories: ./doc/SCCS and ../LMbench_new/./doc/SCCS
Only in ../LMbench_new/./doc: USENIX.PS
Only in ../LMbench_new/./results: HTML
Only in ../LMbench_new/./results: PS
Common subdirectories: ./results/SCCS and ../LMbench_new/./results/SCCS
Only in ../LMbench_new/./results: i686-pc-cygwin
Only in ../LMbench_new/./results: i686-pc-linux-gnu
Only in ../LMbench_new/./results: tmp
Common subdirectories: ./scripts/SCCS and ../LMbench_new/./scripts/SCCS
diff -ubB ./scripts/lmbench ../LMbench_new/./scripts/lmbench
--- ./scripts/lmbench Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./scripts/lmbench Fri Jan 25 11:04:14 2002
@@ -84,8 +84,11 @@
echo \[`date`] 1>&2
echo \[`uptime`] 1>&2
-netstat -i | while read i
-do echo \[net: "$i"] 1>&2
+if test `uname -s | grep "CYGWIN" >/dev/null`; then
+ ifconfig /all
+else
+ netstat -i | while read i
+ do echo \[net: "$i"] 1>&2
set `echo $i`
case $1 in
*ame) ;;
@@ -94,8 +97,8 @@
done
;;
esac
-done
-
+ done
+fi
mount | while read i
do echo \[mount: "$i"] 1>&2
done
@@ -111,19 +114,34 @@
date >> ${OUTPUT}
echo Latency measurements >> ${OUTPUT}
+echo -n "*"
lat_syscall null
+echo -n "*"
lat_syscall read
+echo -n "*"
lat_syscall write
+echo -n "*"
lat_syscall stat $STAT
+echo -n "*"
lat_syscall fstat $STAT
+echo -n "*"
lat_syscall open $STAT
+echo -n "*"
for i in 10 100 250 500; do lat_select file $i; done
+echo -n "*"
for i in 10 100 250 500; do lat_select tcp $i; done
+echo -n "*"
lat_sig install
+echo -n "*"
lat_sig catch
+echo -n "*"
+echo -n "*"
lat_sig prot lat_sig
+echo -n "*"
lat_pipe
+echo -n "*"
lat_unix
+echo -n "*"
cp hello /tmp/hello
for i in fork exec shell; do lat_proc $i; done
rm /tmp/hello
@@ -141,6 +159,7 @@
lat_fs $FSDIR
echo "" 1>&2
fi
+echo -n "*"
if [ X"$DISKS" != X ]
then for i in $DISKS
@@ -151,6 +170,7 @@
fi
done
fi
+echo -n "*"
date >> ${OUTPUT}
echo Local networking >> ${OUTPUT}
@@ -166,19 +186,31 @@
for i in localhost
do
lat_udp $i
+echo -n "*"
lat_udp -$i
+echo -n "*"
lat_tcp $i
+echo -n "*"
lat_tcp -$i
+echo -n "*"
lat_rpc $i
+echo -n "*"
lat_rpc -$i
+echo -n "*"
lat_connect $i
+echo -n "*"
lat_connect -$i
+echo -n "*"
bw_tcp $i
+echo -n "*"
bw_tcp -$i
# I want a hot cache number
lat_http $i 8008 < ../../src/webpage-lm/URLS > /dev/null 2>&1
+echo -n "*"
lat_http $i 8008 < ../../src/webpage-lm/URLS
+echo -n "*"
lat_http -$i 8008
+echo -n "*"
done
for remote in $REMOTE
@@ -190,15 +222,24 @@
$RSH $remote -n 'cd /tmp; tar xf webpage-lm.tar; cd webpage-lm; ../lmhttp 8008' &
sleep 10
echo "[ Networking remote to $remote: `$RSH $remote uname -a` ]" 1>&2
+echo -n "*"
lat_udp $remote; lat_udp -$remote;
+echo -n "*"
lat_tcp $remote; lat_tcp -$remote;
+echo -n "*"
lat_rpc $remote udp; lat_rpc $remote tcp; lat_rpc -$remote;
+echo -n "*"
lat_connect $remote; lat_connect -$remote;
+echo -n "*"
bw_tcp $remote; bw_tcp -$remote
# I want a hot cache number
+echo -n "*"
lat_http $remote 8008 < ../../src/webpage-lm/URLS > /dev/null 2>&1
+echo -n "*"
lat_http $remote 8008 < ../../src/webpage-lm/URLS
+echo -n "*"
lat_http -$remote 8008
+echo -n "*"
RM=
for server in $SERVERS
do RM="/tmp/$server $RM"
@@ -209,55 +250,71 @@
date >> ${OUTPUT}
echo Bandwidth measurements >> ${OUTPUT}
bw_unix
+echo -n "*"
bw_pipe
+echo -n "*"
echo "" 1>&2
echo \"read bandwidth 1>&2
for i in $ALL; do bw_file_rd $i io_only $FILE; done
echo "" 1>&2
+echo -n "*"
echo "" 1>&2
echo \"read open2close bandwidth 1>&2
for i in $ALL; do bw_file_rd $i open2close $FILE; done
echo "" 1>&2
+echo -n "*"
echo \"Mmap read bandwidth 1>&2
for i in $ALL; do bw_mmap_rd $i mmap_only $FILE; done
echo "" 1>&2
+echo -n "*"
echo \"Mmap read open2close bandwidth 1>&2
for i in $ALL; do bw_mmap_rd $i open2close $FILE; done
echo "" 1>&2
rm -f $FILE
+echo -n "*"
echo \"libc bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i bcopy; done; echo "" 1>&2
+echo -n "*"
echo \"libc bcopy aligned 1>&2
for i in $HALF; do bw_mem $i bcopy conflict; done; echo "" 1>&2
+echo -n "*"
echo \"unrolled bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i fcp; done; echo "" 1>&2
+echo -n "*"
echo \"unrolled partial bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i cp; done; echo "" 1>&2
+echo -n "*"
echo "Memory read bandwidth" 1>&2
for i in $ALL; do bw_mem $i frd; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial read bandwidth" 1>&2
for i in $ALL; do bw_mem $i rd; done; echo "" 1>&2
+echo -n "*"
echo "Memory write bandwidth" 1>&2
for i in $ALL; do bw_mem $i fwr; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial write bandwidth" 1>&2
for i in $ALL; do bw_mem $i wr; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial read/write bandwidth" 1>&2
for i in $ALL; do bw_mem $i rdwr; done; echo "" 1>&2
+echo -n "*"
echo "Memory bzero bandwidth" 1>&2
for i in $ALL; do bw_mem $i bzero; done; echo "" 1>&2
+echo -n "*"
date >> ${OUTPUT}
msleep 250
Only in ../LMbench_new/./scripts: lmbench.bak
--- ./scripts/lmbench Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./scripts/lmbench Fri Jan 25 11:04:14 2002
@@ -84,8 +84,11 @@
echo \[`date`] 1>&2
echo \[`uptime`] 1>&2
-netstat -i | while read i
-do echo \[net: "$i"] 1>&2
+if test `uname -s | grep "CYGWIN" >/dev/null`; then
+ ifconfig /all
+else
+ netstat -i | while read i
+ do echo \[net: "$i"] 1>&2
set `echo $i`
case $1 in
*ame) ;;
@@ -94,8 +97,8 @@
done
;;
esac
-done
-
+ done
+fi
mount | while read i
do echo \[mount: "$i"] 1>&2
done
@@ -111,19 +114,34 @@
date >> ${OUTPUT}
echo Latency measurements >> ${OUTPUT}
+echo -n "*"
lat_syscall null
+echo -n "*"
lat_syscall read
+echo -n "*"
lat_syscall write
+echo -n "*"
lat_syscall stat $STAT
+echo -n "*"
lat_syscall fstat $STAT
+echo -n "*"
lat_syscall open $STAT
+echo -n "*"
for i in 10 100 250 500; do lat_select file $i; done
+echo -n "*"
for i in 10 100 250 500; do lat_select tcp $i; done
+echo -n "*"
lat_sig install
+echo -n "*"
lat_sig catch
+echo -n "*"
+echo -n "*"
lat_sig prot lat_sig
+echo -n "*"
lat_pipe
+echo -n "*"
lat_unix
+echo -n "*"
cp hello /tmp/hello
for i in fork exec shell; do lat_proc $i; done
rm /tmp/hello
@@ -141,6 +159,7 @@
lat_fs $FSDIR
echo "" 1>&2
fi
+echo -n "*"
if [ X"$DISKS" != X ]
then for i in $DISKS
@@ -151,6 +170,7 @@
fi
done
fi
+echo -n "*"
date >> ${OUTPUT}
echo Local networking >> ${OUTPUT}
@@ -166,19 +186,31 @@
for i in localhost
do
lat_udp $i
+echo -n "*"
lat_udp -$i
+echo -n "*"
lat_tcp $i
+echo -n "*"
lat_tcp -$i
+echo -n "*"
lat_rpc $i
+echo -n "*"
lat_rpc -$i
+echo -n "*"
lat_connect $i
+echo -n "*"
lat_connect -$i
+echo -n "*"
bw_tcp $i
+echo -n "*"
bw_tcp -$i
# I want a hot cache number
lat_http $i 8008 < ../../src/webpage-lm/URLS > /dev/null 2>&1
+echo -n "*"
lat_http $i 8008 < ../../src/webpage-lm/URLS
+echo -n "*"
lat_http -$i 8008
+echo -n "*"
done
for remote in $REMOTE
@@ -190,15 +222,24 @@
$RSH $remote -n 'cd /tmp; tar xf webpage-lm.tar; cd webpage-lm; ../lmhttp 8008' &
sleep 10
echo "[ Networking remote to $remote: `$RSH $remote uname -a` ]" 1>&2
+echo -n "*"
lat_udp $remote; lat_udp -$remote;
+echo -n "*"
lat_tcp $remote; lat_tcp -$remote;
+echo -n "*"
lat_rpc $remote udp; lat_rpc $remote tcp; lat_rpc -$remote;
+echo -n "*"
lat_connect $remote; lat_connect -$remote;
+echo -n "*"
bw_tcp $remote; bw_tcp -$remote
# I want a hot cache number
+echo -n "*"
lat_http $remote 8008 < ../../src/webpage-lm/URLS > /dev/null 2>&1
+echo -n "*"
lat_http $remote 8008 < ../../src/webpage-lm/URLS
+echo -n "*"
lat_http -$remote 8008
+echo -n "*"
RM=
for server in $SERVERS
do RM="/tmp/$server $RM"
@@ -209,55 +250,71 @@
date >> ${OUTPUT}
echo Bandwidth measurements >> ${OUTPUT}
bw_unix
+echo -n "*"
bw_pipe
+echo -n "*"
echo "" 1>&2
echo \"read bandwidth 1>&2
for i in $ALL; do bw_file_rd $i io_only $FILE; done
echo "" 1>&2
+echo -n "*"
echo "" 1>&2
echo \"read open2close bandwidth 1>&2
for i in $ALL; do bw_file_rd $i open2close $FILE; done
echo "" 1>&2
+echo -n "*"
echo \"Mmap read bandwidth 1>&2
for i in $ALL; do bw_mmap_rd $i mmap_only $FILE; done
echo "" 1>&2
+echo -n "*"
echo \"Mmap read open2close bandwidth 1>&2
for i in $ALL; do bw_mmap_rd $i open2close $FILE; done
echo "" 1>&2
rm -f $FILE
+echo -n "*"
echo \"libc bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i bcopy; done; echo "" 1>&2
+echo -n "*"
echo \"libc bcopy aligned 1>&2
for i in $HALF; do bw_mem $i bcopy conflict; done; echo "" 1>&2
+echo -n "*"
echo \"unrolled bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i fcp; done; echo "" 1>&2
+echo -n "*"
echo \"unrolled partial bcopy unaligned 1>&2
for i in $HALF; do bw_mem $i cp; done; echo "" 1>&2
+echo -n "*"
echo "Memory read bandwidth" 1>&2
for i in $ALL; do bw_mem $i frd; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial read bandwidth" 1>&2
for i in $ALL; do bw_mem $i rd; done; echo "" 1>&2
+echo -n "*"
echo "Memory write bandwidth" 1>&2
for i in $ALL; do bw_mem $i fwr; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial write bandwidth" 1>&2
for i in $ALL; do bw_mem $i wr; done; echo "" 1>&2
+echo -n "*"
echo "Memory partial read/write bandwidth" 1>&2
for i in $ALL; do bw_mem $i rdwr; done; echo "" 1>&2
+echo -n "*"
echo "Memory bzero bandwidth" 1>&2
for i in $ALL; do bw_mem $i bzero; done; echo "" 1>&2
+echo -n "*"
date >> ${OUTPUT}
msleep 250
diff -ubB ./src/Makefile ../LMbench_new/./src/Makefile
--- ./src/Makefile Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/Makefile Wed Jan 30 09:52:30 2002
@@ -85,7 +85,7 @@
LIBOBJS= $O/lib_tcp.o $O/lib_udp.o $O/lib_unix.o $O/lib_timing.o $O/lib_stats.o
lmbench: $(UTILS)
- @env CFLAGS=-O MAKE="$(MAKE)" MAKEFLAGS="$(MAKEFLAGS)" ../scripts/build all
+ @env CFLAGS="-O2" MAKE="$(MAKE)" MAKEFLAGS="$(MAKEFLAGS)" ../scripts/build all
results: lmbench
@../scripts/config-run
Only in ../LMbench_new/./src: Makefile.bak
Common subdirectories: ./src/SCCS and ../LMbench_new/./src/SCCS
diff -ubB ./src/bench.h ../LMbench_new/./src/bench.h
--- ./src/bench.h Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/bench.h Sun Jan 27 19:38:02 2002
@@ -4,6 +4,12 @@
#ifndef _BENCH_H
#define _BENCH_H
+// This is needed for lat_select
+#ifdef __CYGWIN__
+#define FD_SETSIZE 550
+#define NO_PORTMAPPER
+#endif
+
#ifdef WIN32
#include <windows.h>
typedef unsigned char bool_t;
@@ -34,9 +40,13 @@
#include <sys/socket.h>
#include <sys/un.h>
#include <sys/resource.h>
+#ifdef __CYGWIN__
+#include <w32api/rpc.h>
+#else
#define PORTMAP
#include <rpc/rpc.h>
#endif
+#endif
#ifndef HAVE_uint
typedef unsigned int uint;
@@ -239,9 +249,9 @@
* Please do not edit this file.
* It was generated using rpcgen.
*/
-
+#ifndef __CYGWIN__
#include <rpc/types.h>
-
+#endif
#define XACT_PROG ((u_long)404040)
#define XACT_VERS ((u_long)1)
#define RPC_XACT ((u_long)1)
Only in ../LMbench_new/./src: bench.h.bak
diff -ubB ./src/disk.c ../LMbench_new/./src/disk.c
--- ./src/disk.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/disk.c Sun Jan 27 08:30:13 2002
@@ -6,12 +6,12 @@
* Copyright (c) 1994-1997 Larry McVoy. All rights reserved.
* Bits of this are derived from work by Ethan Solomita.
*/
+#include "bench.h"
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
-#include "bench.h"
#ifndef sgi
#define NO_LSEEK64
diff -ubB ./src/lat_rpc.c ../LMbench_new/./src/lat_rpc.c
--- ./src/lat_rpc.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lat_rpc.c Sun Jan 27 19:52:51 2002
@@ -16,6 +16,8 @@
char *id = "$Id$\n";
#include "bench.h"
+#ifndef NO_PORTMAPPER
+
void client_main(int ac, char **av);
void server_main(void);
void benchmark(char *server, char* protocol);
@@ -225,3 +227,10 @@
}
return;
}
+#else
+int
+main(int ac, char **av)
+{
+ return 0;
+}
+#endif
Only in ../LMbench_new/./src: lat_rpc.c.bak
Only in ../LMbench_new/./src: lib_cygwin.c
diff -ubB ./src/lib_tcp.c ../LMbench_new/./src/lib_tcp.c
--- ./src/lib_tcp.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_tcp.c Sun Jan 27 19:36:45 2002
@@ -42,6 +42,7 @@
exit(4);
}
if (prog > 0) {
+#ifndef NO_PORTMAPPER
#ifdef LIBTCP_VERBOSE
fprintf(stderr, "Server port %d\n", sockport(sock));
#endif
@@ -51,6 +52,7 @@
perror("pmap_set");
exit(5);
}
+#endif
}
return (sock);
}
@@ -62,7 +64,9 @@
tcp_done(int prog)
{
if (prog > 0) {
+#ifndef NO_PORTMAPPER
pmap_unset((u_long)prog, (u_long)1);
+#endif
}
return (0);
}
@@ -159,7 +163,9 @@
bzero((void *) &s, sizeof(s));
s.sin_family = AF_INET;
bcopy((void*)h->h_addr, (void *)&s.sin_addr, h->h_length);
+
if (prog > 0) {
+#ifndef NO_PORTMAPPER
save_port = pmap_getport(&s, prog,
(u_long)1, IPPROTO_TCP);
if (!save_port) {
@@ -170,6 +176,7 @@
fprintf(stderr, "Server port %d\n", save_port);
#endif
s.sin_port = htons(save_port);
+#endif
} else {
s.sin_port = htons(-prog);
}
Only in ../LMbench_new/./src: lib_tcp.c.bak
diff -ubB ./src/lib_timing.c ../LMbench_new/./src/lib_timing.c
--- ./src/lib_timing.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_timing.c Sun Jan 27 19:19:09 2002
@@ -865,7 +865,8 @@
}
#endif
-#ifdef WIN32
+#if defined(WIN32)
+#if !defined(__CYGWIN__)
int
getpagesize()
{
@@ -874,6 +875,7 @@
GetSystemInfo(&s);
return ((int)s.dwPageSize);
}
+#endif
LARGE_INTEGER
getFILETIMEoffset()
diff -ubB ./src/lib_udp.c ../LMbench_new/./src/lib_udp.c
--- ./src/lib_udp.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_udp.c Sun Jan 27 19:44:17 2002
@@ -51,7 +51,9 @@
void
udp_done(int prog)
{
+#ifndef NO_PORTMAPPER
(void)pmap_unset((u_long)prog, (u_long)1);
+#endif
}
/*
Only in ../LMbench_new/./src: lib_udp.c.bak
diff -ubB ./src/lmdd.c ../LMbench_new/./src/lmdd.c
--- ./src/lmdd.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lmdd.c Sun Jan 27 08:29:33 2002
@@ -34,6 +34,8 @@
#define FLUSH
#endif
+#include "bench.h"
+
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
@@ -43,7 +45,6 @@
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
-#include "bench.h"
#undef ALIGN
#define ALIGN(x, bs) ((x + (bs - 1)) & ~(bs - 1))
Only in ../LMbench_new/./src: test.c
Only in ../LMbench_new/./src: test.c.bak
Only in ../LMbench_new/./src: test.exe
Only in ../LMbench_new/./src: test.i
Only in ../LMbench_new/./src: test.o
Only in ../LMbench_new/./src: test.s
diff -ubB ./src/timing.h ../LMbench_new/./src/timing.h
--- ./src/timing.h Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/timing.h Fri Nov 30 17:10:18 2001
@@ -42,7 +42,7 @@
uint64 usecs_spent(void);
void touch(char *buf, int size);
-#if defined(hpux) || defined(__hpux) || defined(WIN32)
+#if defined(hpux) || defined(__hpux) || (defined(WIN32) && !defined(__CYGWIN__))
int getpagesize();
#endif
Only in ../LMbench_new/./src: webpage-lm
--- ./src/bench.h Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/bench.h Sun Jan 27 19:38:02 2002
@@ -4,6 +4,12 @@
#ifndef _BENCH_H
#define _BENCH_H
+// This is needed for lat_select
+#ifdef __CYGWIN__
+#define FD_SETSIZE 550
+#define NO_PORTMAPPER
+#endif
+
#ifdef WIN32
#include <windows.h>
typedef unsigned char bool_t;
@@ -34,9 +40,13 @@
#include <sys/socket.h>
#include <sys/un.h>
#include <sys/resource.h>
+#ifdef __CYGWIN__
+#include <w32api/rpc.h>
+#else
#define PORTMAP
#include <rpc/rpc.h>
#endif
+#endif
#ifndef HAVE_uint
typedef unsigned int uint;
@@ -239,9 +249,9 @@
* Please do not edit this file.
* It was generated using rpcgen.
*/
-
+#ifndef __CYGWIN__
#include <rpc/types.h>
-
+#endif
#define XACT_PROG ((u_long)404040)
#define XACT_VERS ((u_long)1)
#define RPC_XACT ((u_long)1)
--- ./src/disk.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/disk.c Sun Jan 27 08:30:13 2002
@@ -6,12 +6,12 @@
* Copyright (c) 1994-1997 Larry McVoy. All rights reserved.
* Bits of this are derived from work by Ethan Solomita.
*/
+#include "bench.h"
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
-#include "bench.h"
#ifndef sgi
#define NO_LSEEK64
--- ./src/lat_rpc.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lat_rpc.c Sun Jan 27 19:52:51 2002
@@ -16,6 +16,8 @@
char *id = "$Id$\n";
#include "bench.h"
+#ifndef NO_PORTMAPPER
+
void client_main(int ac, char **av);
void server_main(void);
void benchmark(char *server, char* protocol);
@@ -225,3 +227,10 @@
}
return;
}
+#else
+int
+main(int ac, char **av)
+{
+ return 0;
+}
+#endif
--- ./src/lib_tcp.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_tcp.c Sun Jan 27 19:36:45 2002
@@ -42,6 +42,7 @@
exit(4);
}
if (prog > 0) {
+#ifndef NO_PORTMAPPER
#ifdef LIBTCP_VERBOSE
fprintf(stderr, "Server port %d\n", sockport(sock));
#endif
@@ -51,6 +52,7 @@
perror("pmap_set");
exit(5);
}
+#endif
}
return (sock);
}
@@ -62,7 +64,9 @@
tcp_done(int prog)
{
if (prog > 0) {
+#ifndef NO_PORTMAPPER
pmap_unset((u_long)prog, (u_long)1);
+#endif
}
return (0);
}
@@ -159,7 +163,9 @@
bzero((void *) &s, sizeof(s));
s.sin_family = AF_INET;
bcopy((void*)h->h_addr, (void *)&s.sin_addr, h->h_length);
+
if (prog > 0) {
+#ifndef NO_PORTMAPPER
save_port = pmap_getport(&s, prog,
(u_long)1, IPPROTO_TCP);
if (!save_port) {
@@ -170,6 +176,7 @@
fprintf(stderr, "Server port %d\n", save_port);
#endif
s.sin_port = htons(save_port);
+#endif
} else {
s.sin_port = htons(-prog);
}
--- ./src/lib_timing.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_timing.c Sun Jan 27 19:19:09 2002
@@ -865,7 +865,8 @@
}
#endif
-#ifdef WIN32
+#if defined(WIN32)
+#if !defined(__CYGWIN__)
int
getpagesize()
{
@@ -874,6 +875,7 @@
GetSystemInfo(&s);
return ((int)s.dwPageSize);
}
+#endif
LARGE_INTEGER
getFILETIMEoffset()
--- ./src/lib_udp.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lib_udp.c Sun Jan 27 19:44:17 2002
@@ -51,7 +51,9 @@
void
udp_done(int prog)
{
+#ifndef NO_PORTMAPPER
(void)pmap_unset((u_long)prog, (u_long)1);
+#endif
}
/*
--- ./src/lmdd.c Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/lmdd.c Sun Jan 27 08:29:33 2002
@@ -34,6 +34,8 @@
#define FLUSH
#endif
+#include "bench.h"
+
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
@@ -43,7 +45,6 @@
#include <sys/types.h>
#include <sys/wait.h>
#include <sys/time.h>
-#include "bench.h"
#undef ALIGN
#define ALIGN(x, bs) ((x + (bs - 1)) & ~(bs - 1))
--- ./src/Makefile Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/Makefile Wed Jan 30 09:52:30 2002
@@ -85,7 +85,7 @@
LIBOBJS= $O/lib_tcp.o $O/lib_udp.o $O/lib_unix.o $O/lib_timing.o $O/lib_stats.o
lmbench: $(UTILS)
- @env CFLAGS=-O MAKE="$(MAKE)" MAKEFLAGS="$(MAKEFLAGS)" ../scripts/build all
+ @env CFLAGS="-O2" MAKE="$(MAKE)" MAKEFLAGS="$(MAKEFLAGS)" ../scripts/build all
results: lmbench
@../scripts/config-run
--- ./src/timing.h Mon Jul 23 07:08:47 2001
+++ ../LMbench_new/./src/timing.h Fri Nov 30 17:10:18 2001
@@ -42,7 +42,7 @@
uint64 usecs_spent(void);
void touch(char *buf, int size);
-#if defined(hpux) || defined(__hpux) || defined(WIN32)
+#if defined(hpux) || defined(__hpux) || (defined(WIN32) && !defined(__CYGWIN__))
int getpagesize();
#endif
^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: Old Thread: Cygwin Performance
2001-12-01 6:33 ` Tim Prince
@ 2001-12-01 11:39 ` Ralf Habacker
0 siblings, 0 replies; 17+ messages in thread
From: Ralf Habacker @ 2001-12-01 11:39 UTC (permalink / raw)
To: Tim Prince; +Cc: Cygwin
>
> cygwin should have made some improvements in piping since then. Amazing the
> things I had time to do last year. At that time, I got over a few of the
> linux specific functions by the use of Chuck Wilson's useful packages, some
> of which should be integrated into cygwin now. I commented out sections of
> lmbench which I couldn't figure out how to port. This would be a useful
> port, particularly in view of the new performance issues brought up by XP.
I have get running lmbench 2.0 on cygwin with some patches (removing rpc functions).
Is there anyone who could verify this patch ? To whom should I send this patch ?
Regards
Ralf
> However, several of the organizations involved in lmbench are trying to stay
> clear of Bill Gates' vendetta against use of open software together with his
> products. I was not employed by such an organization at the time I was
> beating on lmbench.
> ----- Original Message -----
> From: "Piyush Kumar" <piyush@acm.org>
> To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
> Sent: Friday, November 30, 2001 6:49 AM
> Subject: Old Thread: Cygwin Performance
>
>
> >
> >
> > I picked this old thread from Oct 2000!!!
> > Tim reports that cygwin falls short by
> > performance compared to linux box by a
> > factor of 2 using lmbench. Is it still
> > the case? Or have things improved since
> > Oct 13(Unlucky date!! ;)??
> >
> > I was trying to compile lmbench 2.0 (Patch 2)
> > on my cygwin , no luck!!!! I couldnt compile it!
> > Anyone here has tried it before ?? Any luck?
> > I would be really interested in a lmbench port
> > on cygwin! If someone has already done it , please
> > let me know!
> >
> > Thanks,
> > --Piyush
> >
> >
> > =============================================================An Old Thread
> >
> > Re: Cygwin Performance Info
> > To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey" <cabbey at
> > chartermi dot net>
> > Subject: Re: Cygwin Performance Info
> > From: "Tim Prince" <tprince at computer dot org>
> > Date: Fri, 13 Oct 2000 19:12:40 -0700
> > References: <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
> >
> > --------------------------------------------------------------------------
> --
> > ----
> >
> > When I attempted to run lmbench on this old box both under linux and cygwi
> n,
> > there were some tests on which cygwin/w2k fell short of linux by a factor
> of
> > 2 or more (opening files, pipe throughput, and the like), and then there
> > were the cache statistics on which cygwin beat linux by a small margin. I
> > was expecting lmbench to become better adapted to cygwin, but I have no
> news
> > there.
> > ----- Original Message -----
> > From: "Chris Abbey" <cabbey@chartermi.net>
> > To: <cygwin@sourceware.cygnus.com>
> > Sent: Friday, October 13, 2000 4:51 PM
> > Subject: Re: Cygwin Performance Info
> >
> >
> > > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > > >Can someone tell me where the performance hit is in cygwin unix
> > > >emulation?
> > >
> > > whichever part you use the most inside your tightest inner loop.
> > >
> > > seriously.
> > >
> > > that's a big huge open ended question (not about cygwin, about ANY
> > > library/platform) that is as specific to your application as you can
> > > get. For example, if you spend 75% of your computing day manipulating
> > > text files and piping them and greping them and running file utils
> > > against them then the cr/lf translation may be a big hit for you.
> > > On the otherhand if most of your computation in a day is spent answering
> > > requests that come in on tcp/ip sockets then the remapping of winsock
> > > to netinet.h functions maybe your major headache. (note, I'm not trying
> > > to imply that either function has a performance problem, merely that
> they
> > > would be representative places that would have high invocation counts
> > > in the course of the given activity.)
> > >
> > > To really answer that for your application/workload then you need to
> > > get some form of performance detailing that can tell you how much time
> > > you are spending in any given method and how often it's called.
> > >
> > >
> > > --
> > > Want to unsubscribe from this list?
> > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> >
> >
> > --
> > 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/
>
>
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Old Thread: Cygwin Performance
2001-11-20 17:43 Piyush Kumar
2001-11-30 6:36 ` Piyush Kumar
@ 2001-12-01 6:33 ` Tim Prince
2001-12-01 11:39 ` Ralf Habacker
1 sibling, 1 reply; 17+ messages in thread
From: Tim Prince @ 2001-12-01 6:33 UTC (permalink / raw)
To: Piyush Kumar, Cygwin@Cygwin. Com
cygwin should have made some improvements in piping since then. Amazing the
things I had time to do last year. At that time, I got over a few of the
linux specific functions by the use of Chuck Wilson's useful packages, some
of which should be integrated into cygwin now. I commented out sections of
lmbench which I couldn't figure out how to port. This would be a useful
port, particularly in view of the new performance issues brought up by XP.
However, several of the organizations involved in lmbench are trying to stay
clear of Bill Gates' vendetta against use of open software together with his
products. I was not employed by such an organization at the time I was
beating on lmbench.
----- Original Message -----
From: "Piyush Kumar" <piyush@acm.org>
To: "Cygwin@Cygwin. Com" <cygwin@cygwin.com>
Sent: Friday, November 30, 2001 6:49 AM
Subject: Old Thread: Cygwin Performance
>
>
> I picked this old thread from Oct 2000!!!
> Tim reports that cygwin falls short by
> performance compared to linux box by a
> factor of 2 using lmbench. Is it still
> the case? Or have things improved since
> Oct 13(Unlucky date!! ;)??
>
> I was trying to compile lmbench 2.0 (Patch 2)
> on my cygwin , no luck!!!! I couldnt compile it!
> Anyone here has tried it before ?? Any luck?
> I would be really interested in a lmbench port
> on cygwin! If someone has already done it , please
> let me know!
>
> Thanks,
> --Piyush
>
>
> =============================================================An Old Thread
>
> Re: Cygwin Performance Info
> To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey" <cabbey at
> chartermi dot net>
> Subject: Re: Cygwin Performance Info
> From: "Tim Prince" <tprince at computer dot org>
> Date: Fri, 13 Oct 2000 19:12:40 -0700
> References: <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
>
> --------------------------------------------------------------------------
--
> ----
>
> When I attempted to run lmbench on this old box both under linux and cygwi
n,
> there were some tests on which cygwin/w2k fell short of linux by a factor
of
> 2 or more (opening files, pipe throughput, and the like), and then there
> were the cache statistics on which cygwin beat linux by a small margin. I
> was expecting lmbench to become better adapted to cygwin, but I have no
news
> there.
> ----- Original Message -----
> From: "Chris Abbey" <cabbey@chartermi.net>
> To: <cygwin@sourceware.cygnus.com>
> Sent: Friday, October 13, 2000 4:51 PM
> Subject: Re: Cygwin Performance Info
>
>
> > At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> > >Can someone tell me where the performance hit is in cygwin unix
> > >emulation?
> >
> > whichever part you use the most inside your tightest inner loop.
> >
> > seriously.
> >
> > that's a big huge open ended question (not about cygwin, about ANY
> > library/platform) that is as specific to your application as you can
> > get. For example, if you spend 75% of your computing day manipulating
> > text files and piping them and greping them and running file utils
> > against them then the cr/lf translation may be a big hit for you.
> > On the otherhand if most of your computation in a day is spent answering
> > requests that come in on tcp/ip sockets then the remapping of winsock
> > to netinet.h functions maybe your major headache. (note, I'm not trying
> > to imply that either function has a performance problem, merely that
they
> > would be representative places that would have high invocation counts
> > in the course of the given activity.)
> >
> > To really answer that for your application/workload then you need to
> > get some form of performance detailing that can tell you how much time
> > you are spending in any given method and how often it's called.
> >
> >
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
>
>
> --
> 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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Old Thread: Cygwin Performance
2001-11-20 17:43 Piyush Kumar
@ 2001-11-30 6:36 ` Piyush Kumar
2001-12-01 6:33 ` Tim Prince
1 sibling, 0 replies; 17+ messages in thread
From: Piyush Kumar @ 2001-11-30 6:36 UTC (permalink / raw)
To: Cygwin@Cygwin. Com
I picked this old thread from Oct 2000!!!
Tim reports that cygwin falls short by
performance compared to linux box by a
factor of 2 using lmbench. Is it still
the case? Or have things improved since
Oct 13(Unlucky date!! ;)??
I was trying to compile lmbench 2.0 (Patch 2)
on my cygwin , no luck!!!! I couldnt compile it!
Anyone here has tried it before ?? Any luck?
I would be really interested in a lmbench port
on cygwin! If someone has already done it , please
let me know!
Thanks,
--Piyush
=============================================================An Old Thread
Re: Cygwin Performance Info
To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey" <cabbey at
chartermi dot net>
Subject: Re: Cygwin Performance Info
From: "Tim Prince" <tprince at computer dot org>
Date: Fri, 13 Oct 2000 19:12:40 -0700
References: <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
----------------------------------------------------------------------------
----
When I attempted to run lmbench on this old box both under linux and cygwin,
there were some tests on which cygwin/w2k fell short of linux by a factor of
2 or more (opening files, pipe throughput, and the like), and then there
were the cache statistics on which cygwin beat linux by a small margin. I
was expecting lmbench to become better adapted to cygwin, but I have no news
there.
----- Original Message -----
From: "Chris Abbey" <cabbey@chartermi.net>
To: <cygwin@sourceware.cygnus.com>
Sent: Friday, October 13, 2000 4:51 PM
Subject: Re: Cygwin Performance Info
> At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> >Can someone tell me where the performance hit is in cygwin unix
> >emulation?
>
> whichever part you use the most inside your tightest inner loop.
>
> seriously.
>
> that's a big huge open ended question (not about cygwin, about ANY
> library/platform) that is as specific to your application as you can
> get. For example, if you spend 75% of your computing day manipulating
> text files and piping them and greping them and running file utils
> against them then the cr/lf translation may be a big hit for you.
> On the otherhand if most of your computation in a day is spent answering
> requests that come in on tcp/ip sockets then the remapping of winsock
> to netinet.h functions maybe your major headache. (note, I'm not trying
> to imply that either function has a performance problem, merely that they
> would be representative places that would have high invocation counts
> in the course of the given activity.)
>
> To really answer that for your application/workload then you need to
> get some form of performance detailing that can tell you how much time
> you are spending in any given method and how often it's called.
>
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
* Old Thread: Cygwin Performance
@ 2001-11-20 17:43 Piyush Kumar
2001-11-30 6:36 ` Piyush Kumar
2001-12-01 6:33 ` Tim Prince
0 siblings, 2 replies; 17+ messages in thread
From: Piyush Kumar @ 2001-11-20 17:43 UTC (permalink / raw)
To: Cygwin@Cygwin. Com
I picked this old thread from Oct 2000!!!
Tim reports that cygwin falls short by
performance compared to linux box by a
factor of 2 using lmbench. Is it still
the case? Or have things improved since
Oct 13(Unlucky date!! ;)??
I was trying to compile lmbench 2.0 (Patch 2)
on my cygwin , no luck!!!! I couldnt compile it!
Anyone here has tried it before ?? Any luck?
I would be really interested in a lmbench port
on cygwin! If someone has already done it , please
let me know!
Thanks,
--Piyush
=============================================================An Old Thread
Re: Cygwin Performance Info
To: <cygwin at sourceware dot cygnus dot com>, "Chris Abbey" <cabbey at
chartermi dot net>
Subject: Re: Cygwin Performance Info
From: "Tim Prince" <tprince at computer dot org>
Date: Fri, 13 Oct 2000 19:12:40 -0700
References: <4.3.2.7.0.20001013184237.00b6cd70@pop.bresnanlink.net>
----------------------------------------------------------------------------
----
When I attempted to run lmbench on this old box both under linux and cygwin,
there were some tests on which cygwin/w2k fell short of linux by a factor of
2 or more (opening files, pipe throughput, and the like), and then there
were the cache statistics on which cygwin beat linux by a small margin. I
was expecting lmbench to become better adapted to cygwin, but I have no news
there.
----- Original Message -----
From: "Chris Abbey" <cabbey@chartermi.net>
To: <cygwin@sourceware.cygnus.com>
Sent: Friday, October 13, 2000 4:51 PM
Subject: Re: Cygwin Performance Info
> At 19:23 10/13/00 -0400, Laurence F. Wood wrote:
> >Can someone tell me where the performance hit is in cygwin unix
> >emulation?
>
> whichever part you use the most inside your tightest inner loop.
>
> seriously.
>
> that's a big huge open ended question (not about cygwin, about ANY
> library/platform) that is as specific to your application as you can
> get. For example, if you spend 75% of your computing day manipulating
> text files and piping them and greping them and running file utils
> against them then the cr/lf translation may be a big hit for you.
> On the otherhand if most of your computation in a day is spent answering
> requests that come in on tcp/ip sockets then the remapping of winsock
> to netinet.h functions maybe your major headache. (note, I'm not trying
> to imply that either function has a performance problem, merely that they
> would be representative places that would have high invocation counts
> in the course of the given activity.)
>
> To really answer that for your application/workload then you need to
> get some form of performance detailing that can tell you how much time
> you are spending in any given method and how often it's called.
>
>
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
--
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/
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2002-01-30 2:01 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <008501c17af9$d044f4f0$8feb85ce@amr.corp.intel.com>
2001-12-02 10:24 ` Old Thread: Cygwin Performance Ralf Habacker
2001-12-02 12:05 ` Tim Prince
2001-12-02 13:58 ` Tim Prince
2001-12-04 7:19 ` Ralf Habacker
2001-12-04 16:44 ` Tim Prince
2001-12-04 21:27 ` Tim Prince
2001-12-05 12:56 ` Tim Prince
2002-01-23 0:10 ` Ralf Habacker
2002-01-26 11:29 ` Ralf Habacker
2002-01-26 15:54 ` Old Thread: cygwin Performance Christopher Faylor
2002-01-27 1:30 ` Ralf Habacker
2002-01-28 8:39 ` Old Thread: Cygwin Performance Ralf Habacker
2002-01-30 2:01 ` Ralf Habacker
2001-11-20 17:43 Piyush Kumar
2001-11-30 6:36 ` Piyush Kumar
2001-12-01 6:33 ` Tim Prince
2001-12-01 11:39 ` Ralf Habacker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).