[yt-dev] Speed comparison relative to 2.X

[Nathan Goldbaum]

Here's the same test, but with 'particle_mass' replaced with 'Density'
and 'Msun' replaced with 'g/cm**3'.

yt 2.x (dd1ca98)
20.84s user 1.27s system 99% cpu 22.171 total

yt 3.0 (1b17b7e)
21.23s user 0.86s system 99% cpu 22.180 total

yt-3.0 unitrefactor (8131901d)
49.88s user 2.08s system 90% cpu 57.584 total

Here are the top functions in the profile for the unitrefactor test:

http://paste.yt-project.org/show/4313/

So still about the same 30 second slowdown compared to the other two,
with a lot of the overhead inside of new unitrefactor stuff.

I'm not sure what the best strategy for further optimizations is.  I
suspect most of the YTArray and YTquantity instances are being created
inside of field detection.  Would it be possible to alter the field
detection algorithm to more efficiently store random test data?

On Fri, Feb 14, 2014 at 4:47 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Nathan,
>
> Thanks for running this! I suspect the particles might be particularly bad
> right now because of caching being disabled. What is the timing for gas
> density?
>
> -Matt
>
> On Feb 14, 2014 7:38 PM, "Nathan Goldbaum" <nathan12343 at gmail.com> wrote:
>>
>> Hi all,
>>
>> Matt asked me to look at the performance of unitrefactor relative to
>> 2.X and the current 3.0 codebase. I've done that using the following
>> test script: http://paste.yt-project.org/show/4312
>>
>> The script cycles through a time series, printing out particle masses
>> for each dataset.  In a perfect world, this should be an i/o-bound
>> operation.
>>
>> Currently the timings for running this test are as follows:
>>
>> yt 2.x (dd1ca98)
>> 18.37s user 1.43s system 99% cpu 19.997 total
>>
>> yt 3.0 (1b17b7e)
>> 48.76s user 1.81s system 99% cpu 50.743 total
>>
>> yt-3.0 unitrefactor (8131901df14c)
>> 78.72s user 2.00s system 99% cpu 1:20.85 total
>>
>> So about a thirty second difference between each of the versions.
>>
>> Clearly this isn't the best news given that we're moving to 3.0 going
>> forward.  That said, I don't think there has been a lot of focus on
>> 3.0 performance, so it's possible (likely even) there's some
>> low-hanging fruit for performance optimizations.  There was also a big
>> refactor of how i/o works for Enzo datasets (moving away from
>> hdf5_light_reader toward h5py) - maybe that explains some of the
>> difference between 2.x and 3.0.
>>
>> Hope this is helpful,
>>
>> -Nathan
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>