* 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
* 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
* 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
* 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
* 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
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).