They should put energy labels on programming languages. It’s convenient to use Python, but a waste of cpu cycles
It's just one paper of course, but the energy results weren't too surprising. C was the baseline. C++, Rust, and Java close behind. Languages like C# and Go near the middle, and then Python, Ruby, and Perl at the bottom for most energy used.
[0] https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sle...
I do agree that there is a point where the scale tips. I wonder where that is, and what kind of application we’re talking about then. Many applications are at their basic level old corner shop crud, really.
Do you feel the same way about (e.g.) modern mechanized farming compared to classic farming that used human labor (generally unfree and unpaid labor, such as serfs or slaves)?
"Efficiency" is not the only goal that matters.
Comparing manual labor to industrialized farming is comparing (paper) accounting books to programming.
Whether you add gps based differential seeding to just doing it by ‘feel’ but still with machines is the difference of programmer brain cycles. Efficiency is not all obviously and there are different efficiencies one can find relevant. Why is this controversial?
Your argument is that programmers should use less-convenient and more painful languages to save energy.
The argument that agriculture should be performed by unpaid peasants or slaves is exactly the same.
Edit: it doesn't actually matter if they are paid or not (although they generally weren't).
The history of human progress is pretty much defined by using energy to replace human scutwork.
99% of programming projects aren't "web scale" and the development costs far outweigh the operating hardware costs.
IMO the biggest problem is that the Python libraries ecosystem is just too good to miss out on. I absolutely hate Python but even I have to admit it is much easier to do some stuff in Python compared to other languages simply because of the libraries available to do basically anything you could dream of.
Once you break compatibility stuff doesn't work… and a fast python that can't run my software is less useful than a slow python that runs the software.
I’m certain that there exists some subset of python for which this is true, but so what?
Several languages have persisted beyond their natural shelf life due to their library ecosystems. For a period of time, CPAN was one of the best arguments for using Perl. More recently, Java's ecosystem is also a pretty good reason to use Java right now, even if you don't like the language.
Languages seem to thrive early due to initial ease of use (Python, particularly, but also relative uptake of Go vs Rust), but can wane due to a thousand cuts (or sigils in Perl's case).
John Carmack seems to think otherwise.
> "That means that in the time that Python can perform a single FLOP, an A100 could have chewed through 9.75 million FLOPS"
https://twitter.com/id_aa_carmack/status/1503844580474687493...
The OP's comment is that while Python's native interpreter is slow, Python code as a whole can still be fast since people will delegate the hot spots to non-Python libraries optimized for speed.
To refute that, you linked to John Carmack quoting Horace He saying that Python's native interpreter does CPU-based math slower than a GPU. But...that's why people writing Python use libraries to delegate math-intensive work to a GPU, which is the OP's point.
The code that is written in a language other than Python is often not written by the developer writing the Python code.
As an example, I've been fiddling with inferring automatic data extraction rules for data in scraped webpages.
The meat of the algorithm and its heuristics is in Python. The heavy lifting of parsing HTML and evaluating CSS selectors is done by a C parser that I did not write. For me, prototyping the heuristics in C would have been quite a bit slower.
If you pick up Go expecting it to be a "more efficient Python", you will be sorely disappointed.
This is not the case in Go.
If you expand into just "kind of Python-like", you have languages like Nim that approximately fill the hole of "efficient Python".
My impression, though, is a lot of the popular frameworks/libraries for Python lean heavily on runtime reflection in Python (e.g. Django). So people end up stuck to the full Python interpreter/runtime.
In Ruby, parens are optional for all methods, and only required if you need to force non-default precedence.
Returning the value of the last expression seems reasonable to me (just like a UNIX shell).
In Python, I'm bothered by the little inconsistencies. Why is str.len (or length, or size, or count, etc) not a method? Why len(str) instead?
And Python has plenty of oddball syntax: significant whitespace, triple quotes?? You get used to it of course.
Ruby and Python are about equally efficient -- if you're optimizing for code efficiency, both are bad choices. In many domains, that's not a critical metric, so we talk about developer efficiency. I'll argue that developers are more efficient when they are more happy, and for me that selects Ruby by a mile over Python.
But I won't pretend that it's more than a matter of taste. :)
Yes. Especially this. The whitespace thing in and of itself has kept me from ever developing a fondness for Python. Clearly there are plenty of people who aren't bothered by it. De gustibus.
They are both dynamic, OO scripting languages, whose main implementation has a GIL, but beyond that, they aren’t all that similar.
> However, it’s kind of like Python’s weird brother,
Methods-with-self-in-args-list isn’t the “weird” one?
> with optional parentheses for calls without arguments
Parens are optional in Ruby on method calls and method definitions except where necessary to resolve ambiguity (including in the newer special single-line method definition syntax, its not a special syntax option for no-arg methods
> auto-returning the result of the last expression
Ruby is basically an expression-oriented language [0], everything returns a value, and a sequence of expressions returns the last expression in the sequence. Explicit “return” lets you short-circuit that. Python is a statement-oriented language, and statements don’t return things except an explicit return tells the function its in to return something. Both are common kinds of languages, just very different. Neither is “weird”.
I agree that it's uncommon, but I do like the clarity it adds compared to something like "this" which magically refers to the current instance. Hasn't C++ just added something like it with "deducing this"?
Compile times are not the 25-50 ms of a Python interpreter startup, but they are similar to the 250-500 ms of a Go or D compile, at least for small light on metaprogramming loops kinds of programs, and with, say, the TinyC tcc backend.
Of course, big frameworks take a long time to import (or to compile). So, your comparison mileage may vary. And once "ready to go" and finished a Nim program can start up in sub-millisecond time like any C program (esp. if statically linked).
Reimplement a large enough, commonly used subset of python stdlib using this dialect and we may be in the business of writing cross platform apps (perhaps start with android and Ubuntu/Gnome)
In the majority of use cases, your runtime is dominated by I/O, and for the remaining use-cases, you either have low-level functions written in other languages wrapped in Python (numpy, etc.) or genuinely have a case Python is a terrible fit for (eg. low-level graphics programming or embedded).
Why bother making a new variant language with limitation and no real benefit?
https://twitter.com/id_aa_carmack/status/1503844580474687493...
In any case, if your program is waiting on network or file I/O, who cares whether the CPU could have executed one FLOP's worth of bytecode or 9.75 million FLOPs worth of native instructions in the meantime?
The post is highly relevant. Next time, if you don't understand why, just ask.
More specifically, overhead (Python + pyTorch in this case) is often a bottleneck when tensors are quite small comparatively. It also claims that overhead largely doesn't scale with problem size, so the overhead would only matter when running very small tensor operations with pyTorch with a very tight latency requirement. This is... rare in practice, but it does happen to occur, then sure, that's a good reason to not use Python as-is!
You can open some software such as htop right now, and it will show how much CPU time each process on your system has actually used. On my system the vast majority of processes spend the majority of their time doing nothing.
Is it true for all software? Of course not! Something like my compositor for example spends a lot of time doing software compositing which is fairly expensive, and it shows quite clearly in the stats that this is true.
Another use case was parsing proprietary, text-based file formats with ancient encodings. I believe I did use Python for that as there wasn't that much data to convert anyway and it just worked.
Personally, I think going all the way to Nim [2] is more satisfying than a "gradually typed" system, though.
The biggest strength of Python is an ecosystem built on a blend of python code and native extensions, leveraging Python’s strength as a glue language. Dumping the runtime while remaining compatible with the extension ecosystem is quite a challenge, as is adding static typing and taking full advantage of it while also maintaining compatibility with existing ecosystem of code which is a mix of untyped and typed in the existing (optional) type system.
Which is probably why most “more efficient” Python efforts don’t try to do both of those things. Some did, or at least replacing the runtime, but most of them fizzled, not because they didn’t offer benefits, but because burning access to the existing ecosystem wasn’t worth those benefits. OTOH, what we see now is efforts to improve the base interpreter while maintaining compatibility, and opt-in compilation tools that can be used within Python, with a subset of Python or a statically-typed Python-like language that builds to extensions for the Python runtime. Examples include mypyc, Cython, Numba, etc.
…A silly proclamation, of course.
I'm not advocating for it, but it's an interesting thought experiment.
Might be nice for embedded devices though, but they already run C/C++...
Generally I’d expect less efficient languages to be more user friendly (well, a language which has neither advantage is just bad, why is anybody using it?). So, hypothetically these companies should get away with spending fewer programmer-hours on things. They won’t have to run the coffee pots, and air conditioners as late.
Give me at least ksh and awk, they don't use much resources and are infinitely handy.