There is something a bit wacky about a performance service implemented in an interpreted language like Python whether it is tuned or auto-cpufreq. Tuned does seem to be as good as it gets for the moment.
x86 cpus don't have the power efficiency to do the work we now expect of them in thin and light laptops with difficult thermal constraints. You can push them one way or another. You can have them fast with a fan like a jet engine or you can have them cold and running like a 10 year old computer or put the dial somewhere inbetween but there is only so much you can do.
TuneD doesn't have throughput or latency requirements, it should just tell the kernel what to do, perfect for python. If it's installed with the system python it'll share pages well with other Python applications.
And x86 not being power efficient is hardly true for the modern AMD mobile chips, it's not quite the "iPad" experience but it's very good. Comparing to Apple is unfair IMHO since M* is essentially an iPhone CPU with a souped up power budget, many years of optimization across both hardware, kernel and userspace that we don't have.
But when the whole Python interpreter machinery has to run in the background, that will prevent your system from going to lower power states more often.
“It does not matter for this case” times 100 is how we get these power-hungry systems.
I’m with the sibling commenter: Python’s heavy-weight-ness and overhead is a thing, yes, but it’s not the same kind of overhead that gets us to power hungry bloated systems—that stuff has more to do with (on the server) wakeups, memory thrashing from async GC, and careless addition of all sorts of background threads/services to applications without considering efficiency. On the desktop, bloat/overhead have more to do with questionable design choices made by UI frameworks, security/container layers that defeat some performance optimizations, and regular bloated browser-in-a-box GUI apps.
Python is a bad choice for high-throughput systems but not for reasons that make it power inefficient when used in a scripting capacity like tuned.
It's more likely someone using higher-level constructs for something that'll spend most of it's time doing NOTHING will write code that does less. Asyncio helps you write code that does nothing most of the time.
You think the Python interpreter just randomly executes stuff for shits and giggles? No but it does use more memory than something compiled to native.
Meanwhile: TLP is implemented in Bash.
Stop spreading FUD please it contributes negatively to the world.
What machinery?
I haven't tested Intel's efficiency cores (E-cores) myself - would these address the need for desktops/laptops?
Apple and many arm mobile platforms also have a mix of performance and efficiency cores so it seems to be a proven approach. I guess it comes down to implementation. Intel's efficiency cores by themselves (eg N series) apparently make nice little appliances, often better value than something like a RPi. I don't know how much they help their higher performance devices conserve energy.
I have one of Intel's old desktop class processors in a refurbished ex-office mini-desktop plugged into a power meter running a few services for the household and the idle usage isn't terrible. I don't understand why my laptop doesn't run colder and longer given the years of development between them.
There is also the race to idle strategy where you spike the performance cores to get back to idle which probably works well with a lot of office usage but not so well with something more demanding like games or benchmarks.
Thanks, that comment saved me from spending time looking at it.