Re: performance of a program with MakeClass vs MakeSelector, and global variable

From: John Idarraga <idarraga_at_cern.ch>
Date: Tue, 6 Jul 2010 17:19:15 -0400


Hello Marc,

Well, I made a little test program and I don't see the difference you report. There must be something I am not understanding. Here's a sample code so we can sync:

class C1 {

public:
  C1();
  ~C1(){};
  void Fill(int);
  TH1F * GetHistoPtr(){return m_h;};

private:
  TH1F * m_h;   

};

C1::C1(){
  m_h = new TH1F("h1","h1",100,0.,10.);
}

void C1::Fill(int nT){
  m_h->FillRandom("gaus",nT);
}

-------------------------------------- hola.C ---

compile this with ACLIC

[0] .L hola.C++g

then run with the following macro

  gSystem->Load("hola_C.so");

  C1 a;
  a.Fill(1000000);
  TH1F * h = a.GetHistoPtr();   

  cout << "histo : " << h << " | max = " << h->GetMaximum() << endl;

}

-------------------------------------- runhola.C ---

$ time root -l -q -b runhola.C

Finally, if I make that "TH1F * m_h" a global, the timing is roughly the same. So I can't reproduce your problem. Is this what you have in mind ?

John Idarraga

On Tue, 2010-07-06 at 22:47 +0200, Marc Escalier wrote:
> > I would make that histogram a member of your class, then later when the
> > Loop() is finished you return a pointer of that histogram using a public
> > member of your class. Another solution is to make that histogram a
> > global var. That would be the very easy solution. Either way you will
> > be able to compile your code.

> 
> thanks John,
> 
> indeed, if i make the histogram a member of the class (like i did in the 
> "option 3"
> 
> (option 3 :)
> >>>> *if now, i put the histogram in "local variables" in the class of the
> >>>> Selector (declaration in the header .h and memory allocation in the Begin())
> >>>> then the performance of the MakeSelector approach is twice faster as
> >>>> compared to the MakeClass approach
> 
> then the code will be very fast
> 
> actually, the main point is why is it very fast when the variable is 
> local to the class while it is very slow when it is a global variable of the main 
> program that call the instance of the class
> 
> 
> 
> ===================
> 
> On Tue, 6 Jul 2010, John Idarraga wrote:
> 

> > Hello Marc,
> >

> > I would make that histogram a member of your class, then later when the
> > Loop() is finished you return a pointer of that histogram using a public
> > member of your class. Another solution is to make that histogram a
> > global var. That would be the very easy solution. Either way you will
> > be able to compile your code.
> >

> > Another good reason to compile your code. If you are using a lot of
> > stdlib stuff ... compiling is highly recommended.
> >

> > cheers !
> >

> > John
> >

> > On Tue, 2010-07-06 at 22:28 +0200, Marc Escalier wrote:
> >> thanks John for your suggestions,
> >>
> >> my problem is that it doesn't compile for the following reason :
> >> when compiling, the histogram is unknown to the method of the class :
> >>
> >> the reason is that :
> >>
> >> {
> >> TH1F *myhisto
> >>
> >> InstanceOfClass.Loop(*without parameters*)
> >> }
> >>
> >> with :
> >> InstanceOfClass.Loop()
> >> {
> >> work on myhisto that still is accessible "because of the rules of cint"
> >> }
> >>
> >> so it would not compile (i do interpreted code because it is easier to
> >> debug and because the gain in speed when compiling is only 10 %. I
> >> showed to Rene some time ago that indeed the gain was only 10 % for the
> >> specific way of class that i'm using where there is plenty of vectors,
> >> which is not optimized for root. But i don't have the choice about the
> >> class : it is an "official" format.)
> >>
> >> thanks
> >> ======================
> >> On Tue, 6 Jul 2010, John Idarraga wrote:
> >>
> >>> By the way, before running valgrind --tool=callgrind, compile your macro
> >>> with debugging symbols
> >>>
> >>> 1) if compiling using ACLIC
> >>>
> >>> .L mystuff.C++g
> >>>
> >>> 2) if you are compiling by hand you need to pass this flag to g++
> >>>
> >>> -g3
> >>>
> >>> cheers,
> >>>
> >>> John
> >>>
> >>> On Tue, 2010-07-06 at 19:14 +0200, Marc Escalier wrote:
> >>>> Hello,
> >>>>
> >>>> i observed a strange phenomena with root (i guess it doesn't depend on
> >>>> the version, but just in case, it is root 5.22.)
> >>>>
> >>>> Let's consider a minimum program developped from a MakeClass() and a
> >>>> concurrent one with MakeSelector()
> >>>> *if the two programs don't fill histogram, i find the same performance
> >>>> in time of execution
> >>>>
> >>>> *if i fill the histogram with a MakeClass approach or a MakeSelector
> >>>> approach, for which the histogram has been declared in the main program
> >>>> as a global variable
> >>>> then the MakeSelector approach is about 10 times slower than the
> >>>> MakeClass approach (doing exactly same stuff) (and with desactivation on
> >>>> almost all the branches to speed up the process in the two cases)
> >>>>
> >>>> the program is something like :
> >>>>
> >>>> {
> >>>> Declaration of a histogram
> >>>> Call Instance of a Class and loop on it and fill the histogram with
> >>>> dummy values
> >>>> or
> >>>> Call Instance of a Selector and loop on it and fill the histogram with
> >>>> dummy values
> >>>> }
> >>>>
> >>>> *if now, i put the histogram in "local variables" in the class of the
> >>>> Selector (declaration in the header .h and memory allocation in the Begin())
> >>>> then the performance of the MakeSelector approach is twice faster as
> >>>> compared to the MakeClass approach
> >>>>
> >>>> Would you have an idea of the behaviour
> >>>>
> >>>> thank you very much
> >>>>
> >>>> just in case you would need more info on the program, it is here (lxplus) :
> >>>> /afs/cern.ch/user/e/escalier/public/ForRene
> >>>> time root -b -q -x main.C
> >>>> to see the differences to apply, you can replace the differences by
> >>>> making comment/uncomment of the parts with "option 1", "option 2",
> >>>> "option 3"
> >>>> (
> >>>> "grep option 1" *
> >>>> "grep option 2" *
> >>>> "grep option 3" *
> >>>> )
> >>>>
> >>>
> >>>
> >>
> >
> >
> 
Received on Tue Jul 06 2010 - 23:04:59 CEST

This archive was generated by hypermail 2.2.0 : Wed Jul 07 2010 - 05:50:01 CEST