[pythran] Re: Preliminary results benchmark NBabel CO2 production + OpenMP implementation?

  • From: Jochen S <cycomanic@xxxxxxxxx>
  • To: pythran@xxxxxxxxxxxxx
  • Date: Wed, 27 Jan 2021 22:14:05 +0100

Thinking about this some more, I believe the energy should be conserved so
that's what we're checking. I just had a look at some of the julia
implementations and they also differ quite a bit in their energies, except
for the original nbabel.jl which seems to go from E=-0.25 to E=0.5 in one
step, which seems non-physical to me. I guess the code is somewhat
numerically unstable, so if one would want to use this for simulations,
you'd have to adopt some sort of adaptive step-size, which somewhat raises
the question if this was the best code for comparison of the different
languages (not criticising you Pierre, I think this is really cool!).


On Wed, Jan 27, 2021 at 5:15 PM Jochen S <cycomanic@xxxxxxxxx> wrote:

Hi Pierre,

I just had a look at your code earlier and I get different energies
between the omp and non-omp version. I don't think that's expected?

make bench1k
t = 10.00, E = -0.2196519645, dE/E = +0.0000016603

make bench1k_omp
t = 10.00, E = -0.2362802267, dE/E = -0.0000019963

I had a look at the code, but didn't see anything obvious sticking out.



On Wed, Jan 27, 2021 at 3:52 PM PIERRE AUGIER <
pierre.augier@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Finally, it wasn't difficult to adapt the C OpenMP code
https://github.com/jodavies/nbody/blob/openmp/src/nbody.c#L234 and I get
a Pythran version with a very good scaling!

Julia is a bit faster in sequential but the scaling is better for
Pythran, which makes it slightly faster for 12 threads (figures attached).
Anyway, such differences are not really meaningful.

But it's really good to have an efficient parallel implementation in
Python.

----- Mail original -----
De: "Jochen S" <cycomanic@xxxxxxxxx>
À: "pythran" <pythran@xxxxxxxxxxxxx>
Envoyé: Mardi 26 Janvier 2021 22:26:26
Objet: [pythran] Re: Preliminary results benchmark NBabel CO2
production + OpenMP implementation?

Was about to say the same thing. Even leaving aside power consumption at
rest, embedded energy is quite significant, so you always want to try
utilise your machine to the highest degree possible.

On Tue, Jan 26, 2021 at 8:51 PM PIERRE AUGIER <
pierre.augier@xxxxxxxxxxxxxxxxxxxxxx> wrote:

Even with a quite bad scaling for elapsed time, parallel computing
tends
to decrease CO2 production as measured by these types of studies
because we
consider that the node is fully taken by the process. The power of the
whole node counts for this process even if only one core is used and we
could theoretically use the computer for other tasks. Moreover, the
power
at rest is not at all negligible compared to the power when one core is
running. For example, with the node I used for this experiment, the
power
at rest is ~100 W, the power for sequential computing is ~130 W and
with 12
threads only ~220 W.

Moreover there is a cost in CO2/hour associated with the computer
building.

Decreasing the elapsed time is therefore very important in term of CO2
production.


----- Mail original -----
De: "Neal Becker" <ndbecker2@xxxxxxxxx>
À: "pythran" <pythran@xxxxxxxxxxxxx>
Envoyé: Mardi 26 Janvier 2021 18:02:13
Objet: [pythran] Re: Preliminary results benchmark NBabel CO2
production
+ OpenMP implementation?

I don't see how it's possible that parallel processing could reduce
total energy consumption.  Now if you specify a deadline to produce
the results, it might be possible that a single computational element
power consumption might scale nonlinearly with clock speed, and in
that case running multiple cores at lower clock might produce the
result in the allotted time while consuming less energy, but I don't
think we had a time limit.

On Tue, Jan 26, 2021 at 11:53 AM Serge Guelton
<serge.guelton@xxxxxxxxxxxxxxxxxxx> wrote:

On Tue, Jan 26, 2021 at 02:07:43PM +0100, PIERRE AUGIER wrote:
Hi,

Here are some preliminary results of an experiment on energy
consumption
measurement at Grid'5000
(https://www.grid5000.fr/w/Energy_consumption_monitoring_tutorial
).
The goal is
to have enough to be able to submit a serious comment to a recent
article
published in Nature Astronomy (Zwart, 2020) which recommends to
stop
using and
teaching Python because of the ecological impact of computing.

2 figures are attached (the code is here
https://github.com/paugier/nbabel):

1. fig_bench_nbabel.png: CO2 production versus elapsed time for
different
implementations. This figure can be compared with


https://raw.githubusercontent.com/paugier/nbabel/master/py/fig/fig_ecolo_impact_transonic.png
taken from Zwart (2020).

The implementations labeled "nbabel.org" have been found on
https://www.nbabel.org/ and have recently been used in the
article
by Zwart
(2020). Note that these C++, Fortran and Julia implementations are
not well
optimized. However, I think they are representative of many C++,
Fortran and
Julia codes written by scientists.

There is one simple Pythran implementation which is really fast
(slightly slower
than the fastest implementation in Julia but it is not a big
deal).

Note that of course these results do not show that Python is
faster
that C++!!
We just show here that it's easy to write in Python **very**
efficient
implementations of numerically intensive problems.

2. fig_bench_nbabel_parallel_julia.png shows similar results as a
function of
the number of threads for a parallel Julia implementation.

The scaling is not very good but parallelization can of course
decrease elapsed
time and CO2 production.

If the scaling is not very good, then is parallelization good in
terms
of CO2
production? Imean, if using 1 core, you spend 10s and using 2 cores
you
spend
15s, then overall, what's the energy consumed in the first and
second
case? If
the nergy spent is linear to the number of core, then the
single-threaded option
is better, energy-wise?



--
Those who don't understand recursion are doomed to repeat it



Other related posts:

  1. Home
  2. pythran
  3. Archive
  4. 01-2021