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

From: Marc Escalier <escalier_at_lal.in2p3.fr>
Date: Tue, 6 Jul 2010 23:57:39 +0200

thanks John
for the time you spent for the help

i'm making a minimum example to show the stuff

i will reply to you in private

if i find a solution afterwards, thanks to your help, then i would summarize to the forum what was the problem

---

On Tue, 6 Jul 2010, John Idarraga wrote:

> Also, just to picture what you can do with callgrind, here's an analysis
> of the code I just sent. Please see the figure attached.
>
> For instance. You see how the C1::Fill(int) member takes 66.73% of the
> run which is, of course, all due to TH1::FillRandom(). Now, in an
> interesting insight of TH1::FillRandom() you can see that more than half
> of the time is spent in calls to TMath::BinarySearch<>(). And so on and
> so fort. If you are wondering where your code is spending time, this is
> a good way to go.
>
> cheers,
>
> John
>
> 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:57:44 CEST