<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">Thanks Matt. I'll give that a try and see how much of a speedup I get with my large datasets.<div><br></div><div>Dan</div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-12-01 14:30 GMT-05:00 Matthew Turk <span dir="ltr"><<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dan,<br>
<br>
I've opened a PR with some optimizations:<br>
<br>
<a href="https://bitbucket.org/yt_analysis/yt/pull-request/1322/first-attempt-at-speeding-up-ghost-zone/diff" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-request/1322/first-attempt-at-speeding-up-ghost-zone/diff</a><br>
<br>
-Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Nov 28, 2014 at 10:19 AM, Daniel Fenn <<a href="mailto:dsfenn@gmail.com">dsfenn@gmail.com</a>> wrote:<br>
> Thanks everyone for your help.<br>
><br>
> Nathan, I'm glad you were able to reproduce the behavior. I'm following the<br>
> issue that you created to keep updated.<br>
><br>
> Matt, I'll be sure to give periodic reminders if I don't hear anything for a<br>
> while. This functionality would be extremely helpful to me, but it's not<br>
> really feasible with the current speeds, so it's something I have a strong<br>
> incentive to keep on top of.<br>
><br>
> Thanks again,<br>
><br>
> Dan<br>
><br>
> 2014-11-27 15:53 GMT-05:00 Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>>:<br>
><br>
>> I've reproduced similar timings using a FLASH dataset that I think is<br>
>> smaller than the one you're working with.  Follow the issue I've created to<br>
>> track this here:<br>
>><br>
>><br>
>> <a href="https://bitbucket.org/yt_analysis/yt/issue/944/slices-of-fields-that-need-ghost-zones-are" target="_blank">https://bitbucket.org/yt_analysis/yt/issue/944/slices-of-fields-that-need-ghost-zones-are</a><br>
>><br>
>> Thanks for the report Dan!  Hopefully now that we have a test script that<br>
>> shows similar timings, we should be able to work on making this faster.<br>
>><br>
>> On Thu, Nov 27, 2014 at 11:39 AM, Kacper Kowalik <<a href="mailto:xarthisius.kk@gmail.com">xarthisius.kk@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On 11/27/2014 01:31 PM, Matthew Turk wrote:<br>
>>> > Hi Dan (and Nathan),<br>
>>> ><br>
>>> > I take that back, I was looking at the wrong file.  IO is a very small<br>
>>> > portion of the time -- a lot of it is spent in units-related<br>
>>> > activities.  I'm going to dig in to see what the time is spent in, but<br>
>>> > I think there is likely some location where a lot of teeny tiny unit<br>
>>> > operations are happening, over and over and over, and that's killing<br>
>>> > the performance.  Looks like it's in sanitize_units_add and<br>
>>> > sanitize_units_mul, which gets called in data_containers.py (line 549)<br>
>>> > in the selector creation.<br>
>>> ><br>
>>> > Following that further down, I believe the issue is inside the<br>
>>> > RegionSelector, which gets generated a ton of times, and which is<br>
>>> > doing all unitful operations even after converting the values to the<br>
>>> > units it knows they should be in.  I think this might be fixable by<br>
>>> > using the .d attributes inside the RegionSelector __init__.<br>
>>> ><br>
>>> > Dan, if you get an example of this working with the sample datasets on<br>
>>> > the website, that would be very useful to work on.<br>
>>> ><br>
>>> > Kacper, what do you think about adding speed tests to the CI system?<br>
>>><br>
>>> It's already there, see for example [1]. There's one "but"... we would<br>
>>> need pretty decent box to make those kind of tests meaningful. I bet<br>
>>> that 99.99% of fluctuation in [1] are caused by buildbox load rather<br>
>>> code changes.<br>
>>><br>
>>> Cheers,<br>
>>> Kacper<br>
>>><br>
>>> [1]<br>
>>><br>
>>> <a href="http://tests.yt-project.org/job/py2.7-yt-3.0_answer.enzo.moving7/lastCompletedBuild/testReport/history/" target="_blank">http://tests.yt-project.org/job/py2.7-yt-3.0_answer.enzo.moving7/lastCompletedBuild/testReport/history/</a><br>
>>><br>
>>> > -Matt<br>
>>> ><br>
>>> > On Thu, Nov 27, 2014 at 2:17 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>><br>
>>> > wrote:<br>
>>> >> Hi Dan,<br>
>>> >><br>
>>> >> Looking this over, I think the problem is definitely that the ghost<br>
>>> >> zone generation is currently quite stupid in 3.0.  We're revving up<br>
>>> >> for a 3.1 release, but I think for 3.2 or even within the 3.1 cycle we<br>
>>> >> can aim to have this fixed; I've implemented some simple caching that<br>
>>> >> should speed it up, but which has some issues presently that keep it<br>
>>> >> from being fully functional and effective.<br>
>>> >><br>
>>> >> One issue that we've (well, I say "we" but I'm the most guilty) had<br>
>>> >> lately is keeping track of things and ensuring that blockers and<br>
>>> >> important new features are added with reasonable time.  This has come<br>
>>> >> up repeatedly in the user survey that's currently out.  You've been in<br>
>>> >> IRC lately and I wonder if maybe you could help us to keep track of<br>
>>> >> this, by reminding me once in a while if it slips off the radar?  It<br>
>>> >> seems the bug tracker is not the best place, and making sure that we<br>
>>> >> have the underscoring that comes from mentioning and communicating can<br>
>>> >> really help to prioritize things.<br>
>>> >><br>
>>> >> -Matt<br>
>>> >><br>
>>> >> On Thu, Nov 27, 2014 at 10:26 AM, Daniel Fenn <<a href="mailto:dsfenn@gmail.com">dsfenn@gmail.com</a>><br>
>>> >> wrote:<br>
>>> >>> Hi Nathan,<br>
>>> >>><br>
>>> >>> I've attached the html output of pyprof2html. I did it for two<br>
>>> >>> cases--a<br>
>>> >>> large file on a fast disk, and a somewhat smaller file on a slower<br>
>>> >>> disk. In<br>
>>> >>> both cases, I only used one processor. The output is not real<br>
>>> >>> meaningful to<br>
>>> >>> me, since I'm not familiar with the code, and I'm not much of a<br>
>>> >>> python<br>
>>> >>> programmer.<br>
>>> >>><br>
>>> >>> I'll work on doing this with one of the yt datasets, and let you know<br>
>>> >>> how it<br>
>>> >>> goes.<br>
>>> >>><br>
>>> >>> Thanks for your help.<br>
>>> >>><br>
>>> >>> Dan<br>
>>> >>><br>
>>> >>> 2014-11-27 0:08 GMT-05:00 Nathan Goldbaum <<a href="mailto:nathan12343@gmail.com">nathan12343@gmail.com</a>>:<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> On Wed, Nov 26, 2014 at 8:09 PM, Daniel Fenn <<a href="mailto:dsfenn@gmail.com">dsfenn@gmail.com</a>><br>
>>> >>>> wrote:<br>
>>> >>>>><br>
>>> >>>>> Hi everyone. Is it normal for slices to take substantially longer<br>
>>> >>>>> to be<br>
>>> >>>>> created if they're made from a derived field rather than an<br>
>>> >>>>> intrinsic one?<br>
>>> >>>>><br>
>>> >>>>> Specifically, I'm having an issue creating an axis-aligned slice<br>
>>> >>>>> using<br>
>>> >>>>> the divergence of the velocity field. It's taking around 6.5<br>
>>> >>>>> minutes just to<br>
>>> >>>>> make the slice, whereas if I use temperature or density, it takes<br>
>>> >>>>> around 10<br>
>>> >>>>> seconds or so for the same dataset.<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> Velocity divergence is particularly expensive because it needs ghost<br>
>>> >>>> zones, which must be filled in using cascading interpolation.<br>
>>> >>>> Depending on<br>
>>> >>>> the AMR structure in your data, this might be quite expensive.<br>
>>> >>>><br>
>>> >>>> That said, 6.5 minutes for a slice is pretty bad.<br>
>>> >>>><br>
>>> >>>> Is there any chance you can profile the execution of your script? If<br>
>>> >>>> you<br>
>>> >>>> run your script like so:<br>
>>> >>>><br>
>>> >>>> $ python -m cProfile myscript.py<br>
>>> >>>><br>
>>> >>>> you should get a summary printed to stdout of where the interpreter<br>
>>> >>>> is<br>
>>> >>>> spending most of its time. You can also visualize this in more depth<br>
>>> >>>> if you<br>
>>> >>>> dump the profile data to a file, and then use pyprof2html or<br>
>>> >>>> snakeviz to<br>
>>> >>>> load and display the data, e.g:<br>
>>> >>>><br>
>>> >>>> $ python -m cProfile -o out.cprof myscript.py<br>
>>> >>>> $ pyprof2html out.cprof<br>
>>> >>>><br>
>>> >>>> cProfile comes with pyhon, but pyp4orf2html and snakeviz must be<br>
>>> >>>> installed<br>
>>> >>>> separately using pip.<br>
>>> >>>><br>
>>> >>>> It would be great if you could file an issue about this.  Even<br>
>>> >>>> better if<br>
>>> >>>> you can reproduce it using one of the test datasets on<br>
>>> >>>> <a href="http://yt-project.org/data" target="_blank">yt-project.org/data</a><br>
>>> >>>> and attach a script that we can run ourselves.<br>
>>> >>>><br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> I also notice that the amount of time it takes is not dependent on<br>
>>> >>>>> the<br>
>>> >>>>> number of processors I'm using. I've used 1, 12, and 24 processors,<br>
>>> >>>>> with<br>
>>> >>>>> identical results, even though I'm calling enable_parallelism(),<br>
>>> >>>>> and I can<br>
>>> >>>>> see that all the processes are running.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> I read in the docs that slice operations aren't generally done in<br>
>>> >>>>> parallel, but in this case it seems that maybe it would be<br>
>>> >>>>> beneficial. A<br>
>>> >>>>> similar operation in VisIt completes much faster, so I'm wondering<br>
>>> >>>>> if I've<br>
>>> >>>>> misconfigured something, or if there is something I can do to speed<br>
>>> >>>>> things<br>
>>> >>>>> up.<br>
>>> >>>>><br>
>>> >>>>> I'd appreciate any thoughts anyone has on the subject.<br>
>>> >>>>><br>
>>> >>>>> Thanks,<br>
>>> >>>>><br>
>>> >>>>> Dan<br>
>>> >>>>><br>
>>> >>>>> _______________________________________________<br>
>>> >>>>> yt-users mailing list<br>
>>> >>>>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> >>>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>> >>>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> _______________________________________________<br>
>>> >>>> yt-users mailing list<br>
>>> >>>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> >>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>> >>>><br>
>>> >>><br>
>>> >>><br>
>>> >>> _______________________________________________<br>
>>> >>> yt-users mailing list<br>
>>> >>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> >>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>> >>><br>
>>> > _______________________________________________<br>
>>> > yt-users mailing list<br>
>>> > <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> > <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>> ><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> yt-users mailing list<br>
>>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> yt-users mailing list<br>
>> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
>> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
>><br>
><br>
><br>
> _______________________________________________<br>
> yt-users mailing list<br>
> <a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
> <a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
><br>
_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org">yt-users@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org</a><br>
</div></div></blockquote></div><br></div>