Python - Energy Hungry?

Interesting comments at Slashdot:

" C and Rust significantly outperformed other languages in energy efficiency. In fact, they were roughly 50% more efficient than Java and 98% more efficient than Python. It’s not a surprise that C and Rust are more efficient than other languages. What is shocking is the magnitude of the difference."

Hmmm…partly explains why AI/ML/DL training consume so much time and energy?

1 Like

I’m not even going to talk about the sysdmin-level SQL that I routinely run at work :sweat_smile:

3 Likes

You are aware that most all AI/ML libraries are written in C/C++? Python is just the glue code an average person(professor/non developer) can learn well enough to hack crap together.

2 Likes

But my Pi Pico only draws a few miliamps running micropython or C++

1 Like

Send enough queries and lights flicker? :smirk:

Not aware - don’t really care. The Rust learning curve appears to be rather steep/long. Ran across something stating one can learn enough Python in 2-3 days and be writing code. Rust is more like ~2 weeks. Not a pgmr -just found the article interesting.

I remember talk in the Common Room several years ago that Rust was the next big thing.

After decades of hearing that programmer time is much more valuable than computer time, it is rather surprising to see this.

2 Likes

Figuratively speaking … yes.

The DB will tolerate up to 31 LEFT JOIN operations in a single query on large tables. The hilarious solution to this is to UNION disparate tables and/or means of performing coarse filtering … then performing a fine filter against the enormous data set.

I don’t let contractor developers see these queries.

At a former employer they often found it more cost-effective to upgrade the cluster than optimize the code when it came to an app that was truly core to the business. The code itself was by any reasonable measure worth many orders of magnitude more than the hardware it ran on.

There is of course a limit to throwing hardware at the problem and developers were eventually forced to make their code more efficient.

2 Likes

Opportunity to do some necro threading here
Ran across this on SlashDot -

Wonder if this might help speed up the AI/ML/DL learning curve.

Essentially, @SWA is right; however, I would like to clarify a couple things here:

  1. Energy efficiency, and other efficiencies, are not features of a language; they are features of a language implementation. A programming language is just a bunch of rules for generating valid strings (syntax) and analyzing its semantics (type systems and inference rules). The physical world is only relevant when we start talking about how the language is actually implemented (how well the compilers and interpreters are written). There is nothing about python (especially with type hints) that prevents it form being compiled and there is nothing about C that prevents it from being interpreted in an even less efficient manner than python. There are many python compilers out there and while they aren’t as efficient as Rust or C, they significantly close the gap.

  2. Most data science libraries are just wrappers for C. Numpy’s core is C, Pandas’s core is numpy, Slklearn, pytorch and tensorflow’s libraries and their dependencies are all written on top of C/C++. There are other libraries written on top of Julia and Rust. When you are executing python code in data science, you are almost always executing C code. There is going to be overhead from using Python as an interface, but this is nowhere even in the same universe as using raw python. If energy efficiency is a concern, then it just makes sense to write the core intense computations in a well-implemented, compiled language and then write an interface in some higher level interpreted language like python.

So the debate over the “efficiency of languages” is almost always a waste of time and often non-sensical. Very, very, very few large systems are going to be written exclusively in one language. Even if a developer writes an entire application for a business in Python, it almost certainly will have non-Python dependencies lurking somewhere.

Furthermore, we are leaving out the biggest issue of using languages like Rust, C, C++, etc: how easy it is to fuck up and create inefficiencies, leaks and so forth. C would be unsafe even for God himself to program in, but no one is more dangerous than an enraged programmer who has to write less intuitive, low level code that he has to build over and over and over again. These benchmark comparisons between well-implemented algorithms don’t even reflect reality. Whose to say that a programmer with 3 years experience in rust is going to write more efficient code than someone with 20 years in python? What about the pressures of bringing products to market and never fixing shitty codebases because there is always other things to do? No one is going to redesign everything, or even a significant chunk of things, with Rust so Rust programs are going to have to interface with other codebases, meaning that Rust may not be addressing any bottleneck in many use cases when we expect it to.

You know what Python has that most other languages don’t have? Really, really fast prototyping. Not having a compiler does increase debugging times (the compiler’s bitching does give you more hints), but I can try out ideas extremely fast in Python. That’s the core sell of interpreted languages. But no one talks about the energy that is saved by the soft factors. Instead, people talk about the hard factors like they are playing a trading card game with attack points and defense points. Yes, the hard factors like speed and power efficiency are important; however, the soft factors (ease of use, flexibility, size of standard library, development community, documentation, etc) are what matters most in creating a productive workflow and generating new ideas. We can only guess how much energy is saved in that case.

3 Likes

It has recently come to my attention that some TI graphing calculators include CircuitPython. I’ll have to see how much of the language is included.

While the hobby world has been flocking to Python, I’ve been happily trudging along with my Arduino Nano, ESP8266,… C related classes. When the Pico W came out, I bought eight and announced two classes. I’m coming up to speed on MicroPython and preparing class material. Wow! I’m really impressed.

I’ve done over 50 DMS classes with the Arduino IDE and various platforms and the two biggest concerns are getting all student PCs configured and the amount of time to compile and load when debugging on slow PCs. Setup time for Thonny is trivial and execution starts immediately. I will likely shift most of my classes to Pico W.

1 Like

I’d look at anything other than the Arduino IDE, which I think is an abysmal, amateurish attempt at a development environment. VS Code, Visual Studio Community Edition, anything but Arduino.

1 Like

Oh good grief. :roll_eyes: You’re just spoiled. :smirk: It was never intended to be a “professional dev system”. Entry level basics for the hobbyist and non engineering types out there. Free, downloaded, and works just fine offline. Doesn’t have to call home to some mother borg ship. V2.0 - whenever it’s released may have more of those bells and whistles you’re addicted to.

1 Like

Visual Studio Code is free and doesn’t need to phone home. And it’s also completely cross-platform.

1 Like

While I agree with you on the technical side, I promote my classes to attract beginners in and state that you do not have to know anything about electronics or programming. When they finish class and look at youtube for beginners or talk to friends, they will see that their world is heavily oriented toward Arduino IDE.

I attended the recent Visual Code/PlatformIO class sponsored by DPRG. Awesome!

At one time, I supported what is now called IBM Rational Clear Case. I’m well aware of Arduino IDE problems but I’ll stay with it as I transition to MicroPython.

Would you be interested in picking up on Arduino training as I am moving away and leaving an almost vacuum? I’ll be glad to help. There is lots of demand at DMS and we need Arduino C based classes.

NOOOOO!!! :frowning:
I know you’ll be missed.
But things happen, so I will act like an adult and say “You’ll do great wherever you’re going! Don’t be a stranger.”

1 Like

Thanks for pointing out the confusion of my comment! I had mentioned earlier in this thread the I will likely shift my classes from the Arduino C language to MicroPython, primarily on Pico W’s. I will still be around DMS and hope to do 3 or 4 microcontroller classes per month.

Let’s all get together and twist @mdredmond 's arm until he steps up and starts running classes in C language programming of microcontrollers!

1 Like

WHEW!
I see now how I misread, including missing the context clues…

HEY MATT!
Do this, eh.
:smiley:

1 Like

As I was writing the above, I got a PM from @bobbycounts, a new member interested in teaching microcontrollers.

Please welcome him! We need teachers and electronics/microcontroller classes.

1 Like