Thanks to Britton's addition to support memory output on macs, I was able to benchmark the different kd-tree options Stephen put in on a small dataset on my laptop.<div><br></div><div>The runs were using the default Fortran kd-tree with the version of YT mentioned in my previous mail (pulling in the changeset of the memory output for mac), and the new one with the "C" kd-tree ran with the following tip:</div>

<div><br></div><div><div>changeset:   4980:a9d0a3e89a59</div><div>branch:      yt</div><div>tag:         tip</div><div>user:        Britton Smith <<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>></div>

<div>date:        Sun Nov 20 13:44:40 2011 -0500</div><div>summary:     Put fallback method for getting memory usage inside the if tree so</div><div><br></div><div>All the runs are on the 256 cube Enzo dataset with 4 mpi tasks</div>
<div><br></div><div>Results:</div><div><br></div><div>1)  WholeVol.png</div><div>Running parallelHF on the whole volume multiple times in the same script, I see no noticeable peak memory increase after 11 runs, which is good.</div>
<div><br></div><div>2) RegionFtree.png</div><div>Running parallelHF on subvolume 1/64th the size of the whole volume at a time, I see a steady increase in the minimum memory.  Although there are peaks at different subvolumes due to the different distribution of particles at different spacial region, I would expect the minimum to fluctuate, but it seems to go up constantly.</div>
<div><br></div><div>3) RegionCtree.png</div><div>Running paralllelHF on subvolume 1/64th the size of the whole volume, but with the "C" kd-tree.  Memory seems to increase a bit like the Fortran case, but it just took way too long so I killed it after the 17th subvolume was done.</div>
<div><br></div><div>4) CompareF_Ctree.png</div><div>This shows that the C kd-tree's memory savings is definitely noticeable.  However, the cost in time is great.  For the same 17 subvolumes, the Fortran kd-tree took 7 minutes according to the log, but it took the C kd-tree method 1 hour and 31 minutes!</div>
<div><br></div><div>5) CompareF_restart.png</div><div>This is the Fortran kd-tree ran from subvolume 0 to 63 non-stop, compare to just starting at subvolume 62 to 63.  I've shifted the restart with zeroes at the front so you can get a sense of the corresponding value if it were non-stop.  There's a gap between the memory used, showing less memory at the same subvolume, but from a fresh restart of python.</div>
<div><br></div><div>After looking at the graphs, I think the memory only builds up when doing parallelHF with the subvolume defined.  And as long as the code doesn't crash on the first subvolume, it would probably be faster to just let the machine run out of memory and restart from where it stopped, than to use the C kd-tree.</div>
<div><br></div><div>From</div><div>G.S.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><br><div class="gmail_quote">On Sat, Nov 19, 2011 at 12:31 PM, Britton Smith <span dir="ltr"><<a href="mailto:brittonsmith@gmail.com" target="_blank">brittonsmith@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey guys,<br><br>I just issued a pull request to include more robust calculation of memory usage for when the /proc directory doesn't exist.  This is why it doesn't work on macs.  If someone wants to check that out and pull it in, then that should help Geoffrey.<br>

<font color="#888888">
<br>Britton</font><div><div></div><div><br><br><div class="gmail_quote">On Sat, Nov 19, 2011 at 11:48 AM, Stephen Skory <span dir="ltr"><<a href="mailto:s@skory.us" target="_blank">s@skory.us</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Geoffrey,<br>
<div><br>
> I must have missed something, because I'm re-running the 256 cube on my<br>
> lappy but I kept getting the following:<br>
> yt : [INFO     ] 2011-11-19 11:03:51,866 All done! Max Memory = 0 MB<br>
<br>
</div>Yes, I should have warned you. Sorry. The way memory is calculated on<br>
Linux doesn't work on Mac OS X. You are welcome to try to find a way<br>
that does! The pertinent code is here:<br>
<br>
<a href="http://hg.yt-project.org/yt/src/68227951f9b3/yt/funcs.py#cl-123" target="_blank">http://hg.yt-project.org/yt/src/68227951f9b3/yt/funcs.py#cl-123</a><br>
<br>
and google/yahoo/bing/ask jeeves/lycos/altavista/stackoverflow/etc..<br>
are your friend. Good luck, and if you find success, make a pull<br>
request and we'll add it!<br>
<div><div><br>
--<br>
Stephen Skory<br>
<a href="mailto:s@skory.us" target="_blank">s@skory.us</a><br>
<a href="http://stephenskory.com/" target="_blank">http://stephenskory.com/</a><br>
<a href="tel:510.621.3687" value="+15106213687" target="_blank">510.621.3687</a> (google voice)<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
yt-dev mailing list<br>
<a href="mailto:yt-dev@lists.spacepope.org" target="_blank">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
<br></blockquote></div><br></div>