VMD-L Mailing List

From: Axel Kohlmeyer (akohlmey_at_gmail.com)
Date: Fri Jun 03 2011 - 13:57:27 CDT

On Fri, Jun 3, 2011 at 2:02 PM, John Stone <johns_at_ks.uiuc.edu> wrote:
>
> Benjamin,
>  Your "inner loop" proc is creating an atom selection that it is
> not getting deleted either within the proc that makes it, nor within
> the outer loop that calls it.  This is likely the cause of your slowdown.

john,

the selection should be automatically deleted due to the
(crazy) local proxy variable scoping trick that is employed
when atom selections are created (this is something really
worth getting rid of, BTW).

the problem may be that it only will be deleted when the
proc goes out of scope, so there may be a lot of selections
being created and then deleted in a block. not sure how well
Tcl responds to this. for this simple example, there is no need
to generate the selection in the innerloop, but just pass it as
an argument. that may be interesting to compare and see
if the slowdown is really dependent on the atomselection creation
or not.

cheers,
    axel.

>
> Cheers,
>  John Stone
>  johns_at_ks.uiuc.edu
>
> On Fri, Jun 03, 2011 at 05:23:25PM +0100, Benjamin Hall wrote:
>>
>> On 2 Jun 2011, at 12:27, Axel Kohlmeyer wrote:
>>
>> > On Thu, Jun 2, 2011 at 4:39 AM, Benjamin Hall
>> > <benjamin.hall_at_bioch.ox.ac.uk> wrote:
>> >> Hi
>> >>
>> >> I've encountered an odd problem with for loops in tcl in VMD, whereby over the course of extended loops (>10000 iterations) in subroutines the individual loops seem to become slower as the loop progresses. The scripts are typically looping through frames in a trajectory in a manner similar to the below structure
>> >>
>> >> for { set i 0 }  { $i < [molinfo top get numframes] } { incr i } {
>> >>        some_other_function $i
>> >>        puts "."
>> >> }
>> >>
>> >> As the loop progresses, the rate of printing "." visibly slows. I've not noticed any memory leaks (the some_other_function typically contains several atomselect commands),  but I've seen this happen in a couple of unrelated scripts which do the same kind of looping through frames. If I rerun the loop, the initial speeds appear the same. I've not been able to sensibly benchmark the script, though I would if someone could suggest a benchmarking tool for tcl. Has anyone else observed this kind of behaviour, and could anyone suggest a likely cause/solution for the problem?
>> >
>> > no, i have not seen this. however, there are a lot of possible reasons
>> > why "some_other_function" can slow down over the course of iterations,
>> > e.g. by inefficiently walking or searching growing lists. memory leaks
>> > is a less likely option, but the slowdown would be drastic when you run
>> > out of available memory and go into swap.
>> >
>> > timing in tcl can be done with the "clock" command. check out the
>> > tcl/tk wiki (you can find it from www.tcl.tk) which contains lots of little
>> > useful codelets and discussions on how to do things in tcl.
>> >
>>
>> Thanks. I've used time in the below example; unfortunately this produces values in realtime rather than cputime, but it seems to reproduce what I can see when running scripts which do something similar. I get up to a ~10% slow down after ~1000 cycles, and this appears to increase steadily with more cycles (I'm running loops  with > 40000 repeats). Apologies if I'm doing something foolish but I'd appreciate any pointers or tips. I don't think it is CPU throttling as running "outerloop; outerloop" shows an initial speed up
>>
>> proc outerloop {   } {
>>       set outfile [open benchmark.txt w]
>>       set numframes 5000
>>       set increment 1
>>
>>       for {set i 0} {$i < $numframes} {incr i $increment} {
>>               set bm [inner_loop]
>>               puts $outfile "$bm"
>>               if { [expr ($i/$increment) % 2] == 0} {
>>                       set linestring "-"
>>               } else {
>>                       set linestring "|"
>>               }
>>
>>               puts -nonewline "\r$linestring"
>>       }
>>       close $outfile
>> }
>>
>> proc inner_loop { } {
>>       set bm [time { for {set i 0} {$i < 20 } {incr i } {
>>               set DPPC_number [atomselect top "all" frame 0]
>>       } } ]
>>       return $bm
>> }
>>
>> Thanks
>>
>> Ben
>>
>>
>> > cheers,
>> >     axel.
>> >
>> >> Thanks
>> >>
>> >> Ben
>> >> ************************************************************************
>> >> Benjamin A. Hall
>> >> Structural Bioinformatics & Computational Biochemistry Unit / OCISB
>> >> University of Oxford
>> >> http://sbcb.bioch.ox.ac.uk/hall.php
>> >> +44 (0)1865 613304
>> >> benjamin.hall_at_bioch.ox.ac.uk
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Dr. Axel Kohlmeyer
>> > akohlmey_at_gmail.com  http://goo.gl/1wk0
>> >
>> > Institute for Computational Molecular Science
>> > Temple University, Philadelphia PA, USA.
>>
>> ************************************************************************
>> Benjamin A. Hall
>> Structural Bioinformatics & Computational Biochemistry Unit / OCISB
>> University of Oxford
>> http://sbcb.bioch.ox.ac.uk/hall.php
>> +44 (0)1865 613304
>> benjamin.hall_at_bioch.ox.ac.uk
>>
>>
>>
>>
>>
>>
>>
>
> --
> NIH Resource for Macromolecular Modeling and Bioinformatics
> Beckman Institute for Advanced Science and Technology
> University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
> http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
> http://www.ks.uiuc.edu/Research/vmd/       Fax: 217-244-6078
> 

-- 
Dr. Axel Kohlmeyer
akohlmey_at_gmail.com  http://goo.gl/1wk0
Institute for Computational Molecular Science
Temple University, Philadelphia PA, USA.