Hello Rene > > > Hello Rene, > > > > Can you say what your Windows file system is? Is it FAT32 or NTFS? What > > is yours disk/partition size? > > I have a 10 GBytes partition for Windows. It is NTFS with a paging file > size of 768 MB (value recommended by Windows/XP). Thank you. > > > > 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). > but a different compiler. Sure, I paid attention. I would say the different run-time libraries. I don't think the compiler quality alone can give you the factor 2 for I/O benchmarks. > > Could you send the result of the same tests on your machine? > I am installing the full cygwin ( I had no Cygwin gcc so far). Then I'll try. (Thanks the Axel's configure that made it easy). > > I did no > see it myself (my file system is NTFS) > > well! you run only one OS. It would be interesting to see how much you > get with Linux or CYGWIN on your machine. > > Rene Brun > > > > > 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