Hi Valeri, On Mon, 28 Apr 2003, Faine, Valeri wrote: > 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). > > 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. Could you send the result of the same tests on your machine? > 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