Hi Valeri, Thanks for running the benchmarks on your machine. They confirm my numbers. As you can see CYGWIN gcc3.2 gives a much better result than VisualC++. It is interesting to see this competition. It could well be that in the case of VisualC++, a better tuning could be achieved, but this is also true for CYGWIN. Are you going to investigate your point with TFile::SysOpen? Rene Brun On Mon, 5 May 2003, Valeri Fine wrote: > Hello Rene > I've compiled and installed ROOT with win32gcc (optimized) and compared > it with > one from http://root.bnl.gov (compiled with VC6, optimized) > > There are two results ( in "Rootmarks" ): > Win32gcc VC6 > Benchmark.C 180.52 212.95 > Stress.c 251.7 96.8 > > > The first line is easy to explain by X11 layer impact > (that Win32gcc has to use). > > I would like to call your attention that on Windows > the figures reported by "benchmark.C" were ALWAYS a factor 2 of that > reported by "stress" on Windows (for one and the same binaries) > That none have paid attention to yet. > > I think the main difference between ROOT I/O WIN32 and cygwin is a > default flags chosen (internally) to implement "open" C-runtime > subroutine from either MSVCRT and libc > > (See: > http://support.microsoft.com/default.aspx?scid=kb;en-us;131324 > and > http://support.microsoft.com/default.aspx?scid=kb;EN-US;98756 > > That was discussed a while ago and the idea of using the WIN32 > "CreateFile" vs "standard" "open" was not accepted because it would have > entailed two different codes for Unix and Windows (Too expansive to > maintain) > In my mind that time there was no TFile::SysOpen method yet. > > That is a theory. One has to re-implement TFile::SysOpen to get the bold > numbers. Of course the best solution would be to move TFile::Sys<family> > to TSystem class to make the TFile source free of the platform specific > lines. > > Anyway my believe cygwin doesn't use (they can not use) any entry from > MSVCRT so the have to use CreateFile() directly. I think the factor 2 in > I/O performance is good enough to provide a special implementation of > SysOpen method. > > Valeri > > > -----Original Message----- > > From: Rene Brun [mailto:brun@pcbrun.cern.ch] > > Sent: Monday, April 28, 2003 11:25 AM > > To: Faine, Valeri > > Cc: roottalk@pcroot.cern.ch > > Subject: RE: [ROOT] Problem with the new win32gcc target > > > > 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