Re: Python's carbon guilt
On 10/10/20 9:58 AM, Peter Pearson wrote: > Python advocates might want to organize their thoughts on > this subject before their bosses spring the suggestion: > > From > https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : > > . . . Astronomers should also abandon popular programming languages > such as Python in favor of efficient compiled languages. Languages > such as Fortran and C++, Zwart calculates, are more than 100 times > more carbon efficient than Python because they require fewer > operations. Most of the math heavy lifting is done by compiled code that is merely called from Python. I seriously doubt there is anything to save by abandoning Python for something that is harder to use, slower, and probably burns way more electricity with all those compile cycles that they'd be forced to do. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On 10/10/2020 11:58 AM, Peter Pearson wrote: Python advocates might want to organize their thoughts on this subject before their bosses spring the suggestion: From https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change : . . . Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are more than 100 times more carbon efficient than Python because they require fewer operations. Here is my reply to the "senior correspondent for astronomy..." who wrote the columm. --- Dear Mr. Clery: You report that Zwart of Leiden U says ... "Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are more than 100 times more carbon efficient than Python because they require fewer operations." Summary counter claim: the claim is phony. As actually used by astronomers for computationally intensive tasks, Python is nearly if not as 'carbon efficient' -- because nearly all the computation is done with machine code compiled from C, Fortran, C++, or whatever. (I am not an expert here, but am reporting to you a summary of what is generally known among experienced Python users. I am leaving out numerous details. Feel free to contact scientific Python experts for more.) Here is how anti-Python, pro-OtherLanguage people come up with such misleading numbers as '100x slower'. Confuse the issue by ascribing efficiency to languages rather than implementations. Then compare a relatively efficient 'production' implementation of some algorithm in OtherLanguage to an computer inefficient (but human efficient) 'development' implementation in Python that ignores how Python is being used in practice by scientific communities, such as the astronomy community. Step 1: Create a file with couple of numerically intensive functions such as matrix_init and matrix_invert written in directly compiled OtherLanguage. Add calls to matrix_init and matrix_invert. Time one or more runs. Step 2: Naively translate OtherLanguage directly into Python. Don't allow imports. Time one or more runs with the CPython interpreter. Compare the OtherLanguage time to this worst case Python time. Imply that users of Python are stupid enough to stop here for production usage. I consider this a bit slanderous. In practice, Python users inverting matrices, for instance, import the compiled numpy module, which among other things, wraps the standard Linpack package, which uses machine-specific, assemble-coded, Basic Linear Algebra Subroutines (BLAS) when available. In practice, I have read, the overhead of calling C libraries from Python instead of C is only a few percent. The original and still main Python implementation, CPython, is written in C. It interprets Python code, which is 'slow', but the Python code can include calls to fast, compiled, pre-written C functions. CPython was designed from the beginning to be extended with other other modules and functions written in C. (Fortran extensions were included either immediately or soon after, but I don't know which.) Some of these are included in the standard library, others from third-parties. Since the release of Python 1.0 in 1992, real-world Python users, have been extending CPython when appropriate for production usage. Indeed, numerical scientific computation was Python's first 'killer application'. Now, most every open-source C library with significant usage has been wrapped. There are at least hundreds. The current standard numerical package, numpy, is the third, and the needs of astronomers were among those that contributed to the design. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On 10/10/20 2:35 PM, Marco Sulla wrote: > He should also calculate the carbon dioxide emitted by brains that > works in C++ only. I omit other sources. > yes, methane is an alleged greenhouse gas as well -- https://mail.python.org/mailman/listinfo/python-list
RE: Python's carbon guilt
People have a tendency to go too far in their religious zeal, Peter. We could go back to writing on chalkboards to do calculations then re-use the chalk dust when erasing to write again. Many computers do almost nothing 90+ percent of the time. Want to outlaw those or force them to accept random jobs from the internet when relatively idle? But all kidding aside, anything used frequently and not changed often might be a good candidate for an efficient solution that uses fewer resources. Yet our computers, so far, have been in many ways getting cheaper and in many cases use less electricity to do the same number of calculations. But there are tradeoffs such as optimizing speed over memory use or other resources that are external and thus slower. The ultimate carbon cost can sometimes be for carbon-based organisms, most of them suitable to be called human. When you measure how long it takes them to develop applications and verify they have minimal bugs, you may notice that some development environments seem to take lots more time than others for common tasks. Interactive has huge advantages in many cases. Slowest would be asking people to go back to writing in machine code, not very portably. The reality is that speed and other resource use do matter for anything run often or that would take a very long time. Languages like python and R acknowledge that and quite a few parts are now replaced by calls to libraries in other language or C/C++ code. But often that is done only later when the code is not going to be changed regularly. I think there is a reality here. The costs of computing end sometimes of power usage, often are dropping. The users like getting extra features and underneath the covers, that often means lots of extra IF statements or other checks, or loops that keep checking regularly to see if they need to do anything. If you program a GUI that allows the user to click or type in many places at random, there can be lots of overhead even when done in a compiled language. True speed and efficiency might require removing lots of features entirely as too expensive. It may well be cheaper to do some operations on matrices where every row/column is of the same object type but there are very serious advantages to allowing a mixed type operation such as a data.frame where each column is a hidden vector of some type or even at times to allowing every cell/item to be of any object type. The overhead rises in terms of storage and CPU time used but it allows higher levels of abstraction and often the ability to write code with fewer lines that handles many more conditions, sometimes invisibly. Consider how computing is being used and ask if a little more carbon footprint there may reduce the carbon footprint elsewhere. Would you rather have people spend years or months developing some app that can be used in a way that reduces overall carbon dioxide production? If your answer is that you can have it both ways, fine. But you may have trouble hiring enough people willing to work under those constraints and you may be told of lots of things they won't feel comfortable doing and it may take longer and ... A question. Are recent compiled languages that add features as small and fast as earlier ones? For example, many older languages required a function to take a fixed number of arguments in a fixed order and of exactly the types mentioned when created. Some interpreted languages allow lots of additional functionality, some of which could easily be provided such as allowing named arguments in any order, or allowing additional optional arguments or default values and so on. Much of this could be done in a compiled way, but with additional compile time and even run-time cost. But some features, by definition, must be at run time and especially for code that modifies itself or creates new objects dynamically. IF you want some of these new features, how would you supply them in a compiled way without adding lots of the overhead you want to reduce? Carbon guilt should not be taken seriously as an immediate goal as compared to an overall goal. If we make more people able to work from home or nearby offices and avoid long commutes, does it matter if your remote work is much more carbon friendly than the costs to travel and then still use other energy there for lighting and more computers and ... -Original Message- From: Python-list On Behalf Of Peter Pearson Sent: Saturday, October 10, 2020 11:58 AM To: python-list@python.org Subject: Python's carbon guilt Python advocates might want to organize their thoughts on this subject before their bosses spring the suggestion: From https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confr ont-their-role-and-vulnerability-climate-change : . . . Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calcu
Re: Python's carbon guilt
He should also calculate the carbon dioxide emitted by brains that works in C++ only. I omit other sources. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On Sun, Oct 11, 2020 at 3:01 AM Peter Pearson wrote: > > Python advocates might want to organize their thoughts on > this subject before their bosses spring the suggestion: > > From > https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : > > . . . Astronomers should also abandon popular programming languages > such as Python in favor of efficient compiled languages. Languages > such as Fortran and C++, Zwart calculates, are more than 100 times > more carbon efficient than Python because they require fewer > operations. > > Ahh, yes, a new way for people to worship the little tin god. How cute. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's carbon guilt
On 2020-10-10 15:58:18 +, Peter Pearson wrote: > Python advocates might want to organize their thoughts on > this subject before their bosses spring the suggestion: > > From > https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : > > . . . Astronomers should also abandon popular programming languages > such as Python in favor of efficient compiled languages. Languages > such as Fortran and C++, Zwart calculates, are more than 100 times > more carbon efficient than Python because they require fewer > operations. > It would be interesting on which data he based these calculations. For simple benchmarks of numerical code that's almost certainly true, but I doubt anyone writes code intended to run on a supercomputer in plain Python. Surely such programs would use numpy or other specialized libraries which are already written in C or Fortran and may even use a GPU if present? There is of course still some overhead, but it's much smaller. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | h...@hjp.at |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Python's carbon guilt
Python advocates might want to organize their thoughts on this subject before their bosses spring the suggestion: >From >https://www.sciencemag.org/news/2020/10/we-re-part-problem-astronomers-confront-their-role-and-vulnerability-climate-change > : . . . Astronomers should also abandon popular programming languages such as Python in favor of efficient compiled languages. Languages such as Fortran and C++, Zwart calculates, are more than 100 times more carbon efficient than Python because they require fewer operations. -- To email me, substitute nowhere->runbox, invalid->com. -- https://mail.python.org/mailman/listinfo/python-list
