<div dir="ltr">I've reproduced similar timings using a FLASH dataset that I think is smaller than the one you're working with.  Follow the issue I've created to track this here: <div><br></div><div><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><div><div><div><br></div><div>Thanks for the report Dan!  Hopefully now that we have a test script that shows similar timings, we should be able to work on making this faster.</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 27, 2014 at 11:39 AM, Kacper Kowalik <span dir="ltr"><<a href="mailto:xarthisius.kk@gmail.com" target="_blank">xarthisius.kk@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>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>
</span>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>
<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>
<div><div><br>
> -Matt<br>
><br>
> On Thu, Nov 27, 2014 at 2:17 PM, Matthew Turk <<a href="mailto:matthewturk@gmail.com" target="_blank">matthewturk@gmail.com</a>> 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" target="_blank">dsfenn@gmail.com</a>> wrote:<br>
>>> Hi Nathan,<br>
>>><br>
>>> I've attached the html output of pyprof2html. I did it for two cases--a<br>
>>> large file on a fast disk, and a somewhat smaller file on a slower disk. In<br>
>>> both cases, I only used one processor. The output is not real meaningful to<br>
>>> me, since I'm not familiar with the code, and I'm not much of a python<br>
>>> programmer.<br>
>>><br>
>>> I'll work on doing this with one of the yt datasets, and let you know 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" target="_blank">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" target="_blank">dsfenn@gmail.com</a>> wrote:<br>
>>>>><br>
>>>>> Hi everyone. Is it normal for slices to take substantially longer to be<br>
>>>>> created if they're made from a derived field rather than an intrinsic one?<br>
>>>>><br>
>>>>> Specifically, I'm having an issue creating an axis-aligned slice using<br>
>>>>> the divergence of the velocity field. It's taking around 6.5 minutes just to<br>
>>>>> make the slice, whereas if I use temperature or density, it takes 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. 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 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 is<br>
>>>> spending most of its time. You can also visualize this in more depth if you<br>
>>>> dump the profile data to a file, and then use pyprof2html or 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 installed<br>
>>>> separately using pip.<br>
>>>><br>
>>>> It would be great if you could file an issue about this.  Even better if<br>
>>>> you can reproduce it using one of the test datasets on <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 the<br>
>>>>> number of processors I'm using. I've used 1, 12, and 24 processors, with<br>
>>>>> identical results, even though I'm calling enable_parallelism(), 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 beneficial. A<br>
>>>>> similar operation in VisIt completes much faster, so I'm wondering if I've<br>
>>>>> misconfigured something, or if there is something I can do to speed 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" target="_blank">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" target="_blank">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" target="_blank">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" target="_blank">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>
</div></div><br>_______________________________________________<br>
yt-users mailing list<br>
<a href="mailto:yt-users@lists.spacepope.org" target="_blank">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></blockquote></div><br></div></div>