Results NBabel benchmark CO2 production versus time: good new for PyPy map-improvements
Hi, I did some timing and energy consumption measurements with https://www.grid5000.fr/w/Energy_consumption_monitoring_tutorial I think the results tend to validate the approach used in the branch map-improvements (https://foss.heptapod.net/pypy/pypy/-/tree/branch/map-improvements). I attach one of the first figure including a run using an interpreter build with these changes (http://buildbot.pypy.org/nightly/map-improvements-3.7/pypy-c-jit-latest-linu...). To be compared with https://raw.githubusercontent.com/paugier/nbabel/master/py/fig/fig_ecolo_imp... taken from Zwart (2020). The implementation run with PyPy map-improvements is faster than the implementations using Numba, Fortran and C++ (with flags like -Ofast and -march=native activated!) ! It's a great result! Congratulation! For people interested, the code for the benchmarks and the measurement is here https://github.com/paugier/nbabel Pierre
Hi Pierre, wow, those numbers are quite something! I suppose the C++ code could be optimized some more? Do you plan to submit that soon? Would it make your story easier if I tried to push ahead with getting map-improvements merged? Also, would you maybe be interested in (co-?)writing a blog post for the PyPy blog?: https://morepypy.blogspot.com/ Cheers, Carl Friedrich On 1/25/21 8:44 PM, PIERRE AUGIER wrote:
----- Mail original -----
Yes, of course! The C++ code is really not great. Even the Fortran code could easily be optimized a bit more. However, I think they are representative of many C++ and Fortran codes written by scientists.
Do you plan to submit that soon? Would it make your story easier if I tried to push ahead with getting map-improvements merged?
I do not plan to submit that very soon. However, I plan to contact the editors very soon. My point of view is the following: I don't think it would be honest to include in a paper the point using map-improvements before this branch is merged so I would rather wait for it...
Also, would you maybe be interested in (co-?)writing a blog post for the PyPy blog?: https://morepypy.blogspot.com/
Yes, I can really help on such blog post! But I'm definitively not the right guy to explain the principle of map-improvements! Also, for me, the possible comment in Nature Astronomy has a higher priority.
Hi Pierre, wow, those numbers are quite something! I suppose the C++ code could be optimized some more? Do you plan to submit that soon? Would it make your story easier if I tried to push ahead with getting map-improvements merged? Also, would you maybe be interested in (co-?)writing a blog post for the PyPy blog?: https://morepypy.blogspot.com/ Cheers, Carl Friedrich On 1/25/21 8:44 PM, PIERRE AUGIER wrote:
----- Mail original -----
Yes, of course! The C++ code is really not great. Even the Fortran code could easily be optimized a bit more. However, I think they are representative of many C++ and Fortran codes written by scientists.
Do you plan to submit that soon? Would it make your story easier if I tried to push ahead with getting map-improvements merged?
I do not plan to submit that very soon. However, I plan to contact the editors very soon. My point of view is the following: I don't think it would be honest to include in a paper the point using map-improvements before this branch is merged so I would rather wait for it...
Also, would you maybe be interested in (co-?)writing a blog post for the PyPy blog?: https://morepypy.blogspot.com/
Yes, I can really help on such blog post! But I'm definitively not the right guy to explain the principle of map-improvements! Also, for me, the possible comment in Nature Astronomy has a higher priority.
participants (2)
-
Carl Friedrich Bolz-Tereick -
PIERRE AUGIER