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