However, in the end if you want every bit of performance you have to use SIMD intrinsics or write asm directly, so even C can be 8x times or more slower than a manually optimized code.
As a percentage of the totality of software engineering, virtually nobody looks at energy optimization.
Smart phones? Well, the manufacturers likely pay attention to this to some degree. However, I can guarantee you that almost none of the millions of app developers working on third party apps ever look at energy as an optimization vector.
That was my point, the carbon footprint of computing systems is dominated --and permanently marked-- by the energy-dominant language running on it.
PS, big O isn't everything. The constant factors that big O hides are in fact meaningful and can make or break an algorithm. Some languages make some constants worse by having extra overhead in some places or better when they have special facilities.
See also: sorting algorithms deferring to insertion sort O(n²) for small runs, galactic algorithms.
See also: languages where everything is a pointer to dynamic memory, vs languages that have actual values. The language default "dictionary" implementation and its time and space complexities. I could go on. For energy efficiency, or memory efficiency, or speed, choice of language does matter, and depending on the size and nature of the data, can overshadow algorithmic choices.
No. Please read the paper I posted. It’s the language.
You also sound like you are talking to a bunch of morons who don't understand the difference between time complexity and the computational/implementation realities of different languages.
On a personal note, I started my hardware/software development career in the early '80's, writing non-trivial applications in assembly language for a dozen different processors and, of course, designing entire computers from scratch. On from there through languages such as C, C++, Forth, APL, LISP, various Basics and, eventually pretty much all of the "modern" languages. During that time I designed and manufactured custom bit-sliced micro-coded processors with discrete chips in the early days and, PLD/PAL's and, later-on, FPGA's. Sure, I use Python a lot today, yet, I know what I am walking into when I do. I also use lots of C/C++ and, these days, ARM assembler.
Slow code that is both time and energy inefficient is a modern reality. Virtually nobody coming out of a typical university CS curriculum today is exposed to coding without objects. Bloated, slow and, yes, high energy-consuming code is almost normal these days. Look at almost any open source codebase for evidence of this. And, frankly, as machines become faster, nobody cares, because inefficient code works just fine.
Sometimes I compare it to sailing. When there's lots of wind everyone is a sailor. When wind is minimal, you better know what you are doing. Today people benefit from processors running multiple cores at multi-GHz clock rates with tens of gigabytes of memory and terabytes of storage. Of course that leads to bloat and inefficiency at every level! Why wouldn't it?