Comment published in Nature Astronomy about The ecological impact of computing with Python
Locked
12
12
Comment published in Nature Astronomy about The ecological impact of computing with Python
 
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
In reply to this post by PIERRE AUGIER
On Tue, 2020-11-24 at 16:47 +0100, PIERRE AUGIER wrote:
> Hi, > > I recently took a bit of time to study the comment "The ecological > impact of high-performance computing in astrophysics" published in > Nature Astronomy (Zwart, 2020, > https://www.nature.com/articles/s41550-020-1208-y, > https://arxiv.org/pdf/2009.11295.pdf), where it is stated that "Best > however, for the environment is to abandon Python for a more > environmentally friendly (compiled) programming language.". > > I wrote a simple Python-Numpy implementation of the problem used for > this study (https://www.nbabel.org) and, accelerated by Transonic- > Pythran, it's very efficient. Here are some numbers (elapsed times in > s, smaller is better): > > > # particles | Py | C++ | Fortran | Julia | > > -------------|-----|-----|---------|-------| > > 1024 | 29 | 55 | 41 | 45 | > > 2048 | 123 | 231 | 166 | 173 | > > The code and a modified figure are here: > https://github.com/paugier/nbabel (There is no check on the results > for https://www.nbabel.org, so one still has to be very careful.) > > I think that the Numpy community should spend a bit of energy to show > what can be done with the existing tools to get very high performance > (and low CO2 production) with Python. This work could be the basis of > a serious reply to the comment by Zwart (2020). > > Unfortunately the Python solution in https://www.nbabel.org is very > bad in terms of performance (and therefore CO2 production). It is > also true for most of the Python solutions for the Computer Language > Benchmarks Game in > https://benchmarksgame-team.pages.debian.net/benchmarksgame/ (codes > here > https://salsa.debian.org/benchmarksgame-team/benchmarksgame#what-else > ). > > We could try to fix this so that people see that in many cases, it is > not necessary to "abandon Python for a more environmentally friendly > (compiled) programming language". One of the longest and hardest task > would be to implement the different cases of the Computer Language > Benchmarks Game in standard and modern Python-Numpy. Then, optimizing > and accelerating such code should be doable and we should be able to > get very good performance at least for some cases. Good news for this > project, (i) the first point can be done by anyone with good > knowledge in Python-Numpy (many potential workers), (ii) for some > cases, there are already good Python implementations and (iii) the > work can easily be parallelized. > > It is not a criticism, but the (beautiful and very nice) new Numpy > website https://numpy.org/ is not very convincing in terms of > performance. It's written "Performant The core of NumPy is well- > optimized C code. Enjoy the flexibility of Python with the speed of > compiled code." It's true that the core of Numpy is well-optimized C > code but to seriously compete with C++, Fortran or Julia in terms of > numerical performance, one needs to use other tools to move the > compiled-interpreted boundary outside the hot loops. So it could be > reasonable to mention such tools (in particular Numba, Pythran, > Cython and Transonic). > > Is there already something planned to answer to Zwart (2020)? right, you should not write the core of an N-Body simulation in Python :). I completely disagree with the focus on programming languages/tooling, quite honestly. A PhD who writes performance critical code, must get the education necessary to do it well. That may mean learning something beyond Python, but not replacing Python entirely. In one point the opinion notes: NumPy, for example, is mostly used for its advanced array handling and support functions. Using these will reduce runtime and, therefore, also carbon emission, but optimization is generally stopped as soon as the calculation runs within an unconsciously determined reasonable amount of time, such as the coffee-refill timescale or a holiday weekend. IMO, this applies to any other programming language just as much. If your correlation is fast enough, you will not invest time in implementing an fft based algorithm. If you iterate your array in Fortran instead of C-order in your C++ program (which new users may just do randomly), you are likely to waste more(!) cpu cycles then if you were using NumPy :). Personally, I am always curious how much of that "GPUs are faster" factor is actually due to the effort spend on making it faster... My angle is that in the end, it is far more about technical knowledge than about using the "right" language. An example: At an old workplace we had had some simulations running five times slower, because years earlier someone forgot to set `RELEASE=True` in the default config, always compiling in debug mode! But honestly, if it was 5 times faster, we probably would probably have done at least 3 times as many simulations :). Aside from that, most complex C/C++ programs can probably be sped up significantly just as well. In the end, my main reading is that code running on power-hungry machines (clusters, workstations) should maybe be audited for performance. Yes! (Although even then, reduces tend to get used, no matter how much you have!) As for actually doing something to reduce the carbon footprint, I think the vast majority of our users would have more impact if they throttle their CPUs a bit rather than worry about what tool they use to do their job :). Cheers, Sebastian > > Any opinions or suggestions on this potential project? > > Pierre > > PS: Of course, alternative Python interpreters (PyPy, GraalPython, > Pyjion, Pyston, etc.) could also be used, especially if HPy ( > https://github.com/hpyproject/hpy) is successful (C core of Numpy > written in HPy, Cython able to produce HPy code, etc.). However, I > tend to be a bit skeptical in the ability of such technologies to > reach very high performance for low-level Numpy code (performance > that can be reached by replacing whole Python functions with > optimized compiled code). Of course, I hope I'm wrong! IMHO, it does > not remove the need for a successful HPy! > > -- > Pierre Augier - CR CNRS > http://www.legi.grenoble-inp.fr > LEGI (UMR 5519) Laboratoire des Ecoulements Geophysiques et > Industriels > BP53, 38041 Grenoble Cedex, > France tel:+33.4.56.52.86.16 > _______________________________________________ > NumPy-Discussion mailing list > [hidden email] > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
signature.asc (849 bytes)
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
In reply to this post by Jerome Kieffer
On Tue, 2020-11-24 at 18:41 +0100, Jerome Kieffer wrote:
> Hi Pierre, > > I agree with your point of view: the author wants to demonstrate C++ > and Fortran are better than Python... and environmentally speaking he > has some evidences. > > We develop with Python, Cython, Numpy, and OpenCL and what annoys me > most is the compilation time needed for the development of those > statically typed ahead of time extensions (C++, C, Fortran). > > Clearly the author wants to get his article viral and in a sense he > managed :). But he did not mention Julia / Numba and other JIT > compiled > languages (including matlab ?) that are probably outperforming the > C++ / Fortran when considering the development time and test-time. > Beside this the OpenMP parallelism (implicitly advertized) is far > from > scaling well on multi-socket systems and other programming paradigms > are needed to extract the best performances from spercomputers. > than computational speed when it comes to performance [1]. That shows the impressive scale and complexity of efficient code. So, I could possibly argue that the most important thing may well be accessibility of algorithms. And I think that is what a large chunk of Scientific Python packages are all about. Whether or not that has an impact on the environment... Cheers, Sebastian [1] This was the first resource I found, I am sure there are plenty: https://www.lanl.gov/conferences/salishan/salishan2004/womble.pdf > Cheers, > > Jerome > > _______________________________________________ > NumPy-Discussion mailing list > [hidden email] > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
In reply to this post by YueCompl
 Hello, We’re trying to do a part of this in the TACO team, and with a Python wrapper in the form of PyData/Sparse. It will allow an abstract array/scheduling to take place, but there are a bunch of constraints, the most important one being that a C compiler cannot be required at runtime. However, this may take a while to materialize, as we need an LLVM backend, and a Python wrapper (matching the NumPy API), and support for arbitrary functions (like universal functions). -- Sent from Canary
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Measuring running time of a program in arbitrary programming language is not an objective metric. Otherwise force everyone code in Assembler and we would be done as quick as possible. Hire 5 people to come to the workplace for 6 months to optimize it and we will be done with their transportation. There is a reason for not doing so. Alternatively, any time that will be shaved off from this will be spent on extremely inefficient i9 laptops that developers have while debugging the type issues. As the author themselves admit, the development speed would justify the loss encountered from the actual code running. So this study is suggestive at the very least just; like my rebuttal, very difficult to verify. I do Industrial IoT for a living, and
while I wholeheartedly agree with the intentions,
I would seriously question the power metrics given here because similarly I can easily show a steel factory to be very efficient if I am not careful. Especially tying the code quality to the programming language is a very slippery slope that I have been listening to in the last 20 years from Fortran people. > I think we, the community, does have to take it seriously. NumPy
and the rest of the ecosystem is trying to raise money to hire
developers. This sentiment, which is much wider than a single paper, is a
prevalent roadblock. I don't get this sentence. On Tue, Nov 24, 2020 at 7:29 PM Hameer Abbasi <[hidden email]> wrote:
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
In reply to this post by Hameer Abbasi
Great to know.
Skimmed through the project readme, so TACO currently generating C code as intermediate language, if the purpose is about tensors, why not Numba's llvmlite for it? I'm aware that the scheduling code tend not to be array programs, and llvmlite may have tailored too much to optimize more general programs well. How is TACO going in this regard? Compl
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
 Hello, TACO consists of three things:
So it combines arrays with scheduling, and also sparse tensors for a lot of different applications. It also includes an auto-scheduler. The code thus generated is on par or faster than, e.g. MKL and other equivalent libraries, with the ability to do fusion for arbitrary expressions. This is, for more complicated expressions involving sparse operands, big-O superior to composing the operations. The limitations are:
As for why not Numba/llvmlite: Re-writing TACO is a large task that would be hard to do, wrapping/extending it is much easier. Best regards, Hameer Abbasi -- Sent from Canary
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
Re: Comment published in Nature Astronomy about The ecological impact of computing with Python
|
|
Yeah, I get it. llvmlite would only do composition, while TACO is doing fusion. This is more promising!
Best regards, Compl
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion |
Showing by examples how Python-Numpy can be efficient even for computationally intensive tasks
|
|
| Free forum by Nabble | Edit this page |