Hello Rene, Can you say what your Windows file system is? Is it FAT32 or NTFS? What is yours disk/partition size? Anyway this sounds we should look more carefully how Cygwin opens and reads/writes Windows file. Very likely they use WIN32 API directly rather some Posix-mimic wrappers. I'll try to make small test using Win32 API and the POSIX API under VC++. Factor 2 it is something one should understand. (Taking in account Cygwin application uses the same operating system and the same file system). I did no see it myself (my file system is NTFS) Valeri > -----Original Message----- > From: Rene Brun [mailto:brun@pcbrun.cern.ch] > Sent: Sunday, April 27, 2003 3:16 PM > To: Valeri Fine > Cc: axel@fnal.gov; roottalk@pcroot.cern.ch > Subject: RE: [ROOT] Problem with the new win32gcc target > > Hi Valeri, Axel, > > I have run the standard ROOT benchmarks on my new laptop > (DELL Inspiron 8500 2.4 GHz, 512 MB RAM) > The system is dual boot. I can run RedHat 7.3 > or Windows XP Professional. Under Windows, I have installed > the normal win32 version with VisualC++7.NET and also CYGWIN > with gcc3.2. As you can see Linux gives always the best results. > It is interesting to notice that CYGWIN with gcc3.2 gives also > better results than Windows VisualC++. > The results under Windows are obtained with the Windows XP > standard configuration. I have run with large files to > minimize cache effects. More benchmarks are welcome. > > > win32 VC++7 optimized > ===================== > -stress -b 30 : RealTime = 42.48 seconds CpuTime = 28.32 seconds > -stress -b 1000 : RealTime = 101.99 seconds CpuTime = 83.13 seconds > -Event 10000 0 0 1 : RealTime = 113.41 seconds CpuTime = 40.37 seconds > -Event 10000 0 0 20: RealTime = 85.89 seconds CpuTime = 12.08 seconds > -bench -b : RealTime = 69.22 seconds CpuTime = 28.07 seconds > > > wingcc gcc3.2 optimized > ======================= > -stress -b 30 : RealTime = 25.00 seconds CpuTime = 13.06 seconds > -stress -b 1000 : RealTime = 83.37 seconds CpuTime = 59.81 seconds > -Event 10000 0 0 1 : RealTime = 104.42 seconds CpuTime = 52.51 seconds > -Event 10000 0 0 20: RealTime = 62.65 seconds CpuTime = 13.15 seconds > -bench -b : RealTime = 65.22 seconds CpuTime = 27.69 seconds > > Linux RH7.3 gcc3.2 optimized > ============================ > -stress -b 30 : RealTime = 15.34 seconds CpuTime = 13.12 seconds > -stress -b 1000 : RealTime = 64.05 seconds CpuTime = 60.94 seconds > -Event 10000 0 0 1 : RealTime = 64.10 seconds CpuTime = 45.72 seconds > -Event 10000 0 0 20: RealTime = 22.26 seconds CpuTime = 12.64 seconds > -bench -b : RealTime = 30.11 seconds CpuTime = 24.31 seconds > > Rene Brun > > On > Sun, 27 > Apr > 2003, Valeri Fine wrote: > > > Hello Axel, > > > > > Hi Valeri, > > > > > > Is that your assumption or do you have any evidence that cygwin i/o is > > > moved into a separate process? > > [Valeri Fine] > > To be precise I have to look the current cygwin source code up. > > However many years ago (probably 7 yeas ago) I was close watching cygwin > > development and there was a separate Cygwin process that time. > > Of course the same thing can be achieved with some sort of the global > > area available for all Cygwin processes with some synchronization > > mechanism to access this area. > > > > Ok, I've founds. The current Cygwin docs says: > > > > " When a binary linked against the library is executed, the Cygwin DLL > > is loaded into the application's text segment. Because we are trying > > to emulate a UNIX kernel which needs access to all processes running > > under it, the first Cygwin DLL to run creates shared memory areas that > > other processes using separate instances of the DLL can access. This is > > used to keep track of open file descriptors and assist fork and exec, > > among other purposes. In addition to the shared memory regions, every > > process also has a per_process structure that contains information such > > as process id, user id, signal masks, and other similar process-specific > > information. > > " > > > > The I/O benchmarking issue was discussed that time also. > > I suspect the "times()" subroutine from Cygwin doesn't count some time > > spent for I/O. > > Axel have you any figures with no ROOT. Just a simple I/O example > > compiled with VC++ and gcc? I have no gcc installed at the moment to > > check it myself right away. > > > > Just my 2 cents; > > > > > As far as I know cygwin1.dll just acts as > > > a wrapper for win32 functions, providing posix interfaces (it does > > much > > > more, but that's what it does concerning i/o functions). There's no > > such > > > thing as a "cygwin process". > > > > > > Cheers, Axel. > > > > > > > -----Original Message----- > > > > From: owner-roottalk@pcroot.cern.ch > > > > [mailto:owner-roottalk@pcroot.cern.ch] On Behalf Of Valeri Fine > > > > Sent: Sunday, April 27, 2003 6:10 AM > > > > To: 'Rene Brun'; 'Damir Buskulic' > > > > Cc: roottalk@pcroot.cern.ch > > > > Subject: RE: [ROOT] Problem with the new win32gcc target > > > > > > > > > > > > Hello Rene, > > > > > > > > > I see that all ROOT benchmarks using gcc3.2 run at the > > > > same speed as > > > > > on native Linux. The I/O benchmarks like stress run much better > > > > (nearly > > > > > a factor 2!) than under MS win32. I am currently running > > > > more tests > > > > > to understand why. > > > > > > > > [Valeri Fine] > > > > Comparing the benchmarks please take in account when you run > > > > ROOT under Cygwin the part jobs is provided by other > > > > processes (Those started by Cygwin DLL to provide UNIX-like > > > > I/O for example). That time may not have been counted > > > > properly by the "regular" ROOT benchmarks. > > > > > > > > Valeri > > > > > > > > > > > > > > This option looks potentially attractive because it has the > > > > advantages > > > > > of Linux and Windows combined in an efficient way. > > > > > > > > > > Rene Brun > > > > > > > > > > > > > > > On > > > > > Fri, 25 > > > > > Apr 2003, Damir Buskulic wrote: > > > > > > > > > > > Hi, > > > > > > > > > > > > I tried to compile root on Windows (Me) with the yet unanounced > > > > win32gcc > > > > > > target. But I didn't succeed. Here are the steps I took : > > > > > > > > > > > > - install cygwin in it's full glory (with xfree+gcc+...) from > > the > > > > web > > > > > > - download and prepare the root sources > > > > > > - set up the environment variables as described for windows > > > > > > - try to do "make". It ends up at the first call of depend.sh > > with > > > > > > > > > > > > build/unix/depend.sh main/src/h2root.d "-pipe -Wall > > > > -Woverloaded-virtual > > > > > > -D_DLL -Iinclude -I/usr/X11R6/include" main/src/h2root.cxx > > > > > > > main/src/h2root.d > > > > > > > > > > > > Does anyone has ideas about what is going on ? or is it > > > > too early to > > > > try > > > > > > without clear instructions ? > > > > > > > > > > > > Cheers > > > > > > > > > > > > Damir > > > > > > > > > > > > > > > > > > ===================================================================== > > > > > > | Damir Buskulic | Universite de Savoie/LAPP > > > > | > > > > > > | | Chemin de Bellevue, B.P. 110 > > > > | > > > > > > | Tel : +33 (0)450091600 | F-74941 Annecy-le-Vieux > > Cedex > > > > | > > > > > > | e-mail: buskulic@lapp.in2p3.fr | FRANCE > > > > | > > > > > > > > > > > > ===================================================================== > > > > > > mailto:buskulic@lapp.in2p3.fr > > > > > > > > > > > > > > > > >
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:11 MET