Linux 6.2 Likely To Enjoy Measurable Power-Savings While Idle Or Lightly Loaded

[furtadopires]

Every time I see some "Power management" and "kernel" in the same sentence, my AMD notebook trembles in fear.

[marios]

Wrong once more. If we are talking about Anroid Java at least, it doesn't run JVM but rather compiles to native code. If you download an app from Play store, you download a precompiled binary for architecture and this has been around for at least half a decade. You are not running Java in userspace at all.

But don't let that stop you from posting uninformed dribble.

This is bullshit and I am not even going to waste my time on proving it. Anyone who can google, can see for themselves.

[mdedetrich]

This is bullshit and I am not even going to waste my time on proving it. Anyone who can google, can see for themselves.

Yup https://developer.android.com/guide/app-bundle/faq

There have always been rare cases on Android when APKs cannot directly transfer from one device to another, regardless of whether the app is published via APKs or AABs. Specifically, when APKs have been optimized for a device (for example, for a specific chip architecture) then transferring those APKs directly to another device may encounter issues if the target device doesn't match the properties of the original device. In these situations, an APK or set of APKs that are appropriate for the target device need to be installed.

The play store has been deploying optimized bundles specific for the architecture for a while now.

[sinepgib]

The play store has been deploying optimized bundles specific for the architecture for a while now.

TIL. The last I knew was they were using AOT during install. That doesn't mean it doesn't run on a heavy runtime tho (not sure whether it is heavy or not, just that being AOT doesn't make it not true).

[openminded]

>> Uradzislau
Japanese spelling breaks in. This is what Vladislav sounds like when pronounced by a native Japanese.

[juarezr]

TIL. The last I knew was they were using AOT during install. That doesn't mean it doesn't run on a heavy runtime tho (not sure whether it is heavy or not, just that being AOT doesn't make it not true).

Android 4.4/5.0 introduced ART (Android Runtime) that uses AOT (Ahead-Of-Time) at the installation phase instead of JIT (Just-In-Time) at the start/run phase.
Even that ART is improving a lot since that, there are many by-design deficiencies that a JIT/AOT compiler can improve in many cases but can't optimize entirely as:

• All function calls are virtual function calls
• Small objects are placed in the Heap
• Object memory overhead (13 bytes for each object, 30 for strings, etc...)
• Garbage collection pauses
• Lack of inline assembly for extreme hot functions (commonly mitigated by using FFI but with an extra burden on dev)

Of course, it's always a question of trade-offs between speed, productivity, and security/sandboxing.

[sinepgib]

Android 4.4/5.0 introduced ART (Android Runtime) that uses AOT (Ahead-Of-Time) at the installation phase instead of JIT (Just-In-Time) at the start/run phase.

Right, I knew the change to ART was then (I only learned about it a few days ago tho, for all I knew we were still using Dalvik), but thought the AOT at installation phase was much more recent (say 8.0).

Even that ART is improving a lot since that, there are many by-design deficiencies that a JIT/AOT compiler can improve in many cases but can't optimize entirely as:

• All function calls are virtual function calls
• Small objects are placed in the Heap
• Object memory overhead (13 bytes for each object, 30 for strings, etc...)
• Garbage collection pauses
• Lack of inline assembly for extreme hot functions (commonly mitigated by using FFI but with an extra burden on dev)

Of course, it's always a question of trade-offs between speed, productivity, and security/sandboxing.

Why doesn't AOT fix virtual function calls and small objects in the heap part? I can see why GC pauses can't be solved (even then, they can be mitigated a lot just by using the stack more, and aren't solved entirely by static compilation) and the lack of inline assembly, but size and escape analysis can be performed at an early phase when generating bytecode and the same applies to whether functions can be devirtualized. If you get to prove at that time whether a function call resolves to a specific function you can remove the virtual call, it sounds more like a generics problem than an AOT problem. If you can prove an object is smaller than certain threshold you can put it on the stack and avoid all the book keeping fields and overhead, and this alone reduces the load on the GC (in fact it's one of the main reasons Go and Python get by with a relatively primitive GC while Java needs a much more sophisticated one, they simply try their best to not give it any work to do).

EDIT: I'm assuming it runs a GC because AFAIR the ART is backwards compatible with Dalvik programs that rely on it.

[mdedetrich]

Android 4.4/5.0 introduced ART (Android Runtime) that uses AOT (Ahead-Of-Time) at the installation phase instead of JIT (Just-In-Time) at the start/run phase.
Even that ART is improving a lot since that, there are many by-design deficiencies that a JIT/AOT compiler can improve in many cases but can't optimize entirely as:

• All function calls are virtual function calls
• Small objects are placed in the Heap
• Object memory overhead (13 bytes for each object, 30 for strings, etc...)
• Garbage collection pauses
• Lack of inline assembly for extreme hot functions (commonly mitigated by using FFI but with an extra burden on dev)

Of course, it's always a question of trade-offs between speed, productivity, and security/sandboxing.

Android also does devirtualization via CHA (class hierarchy analysis) now as well https://source.android.com/docs/core...e/improvements

TIL. The last I knew was they were using AOT during install. That doesn't mean it doesn't run on a heavy runtime tho (not sure whether it is heavy or not, just that being AOT doesn't make it not true).

Well you are kind of being pedandatic at that point since you can argue that even typical C/Rust programs have a runtime unless you statically link EVERYTHING

Point is that Android running bytecode on a virtual machine (i.e. Dalvik) hasn't been happening for like a decade now.

[sinepgib]

Well you are kind of being pedandatic at that point since you can argue that even typical C/Rust programs have a runtime unless you statically link EVERYTHING

No, because typical C/Rust programs run (by default) a much lighter runtime. For a start, they don't use a GC that either runs concurrently with your code or pauses the whole execution every once in a while or both, nor copy the whole set of living objects*. Yes, being pedantic, both have a runtime. But putting those in the same category is a joke.

*Granted, nowadays they use generational GC which makes it copy much fewer objects.

Point is that Android running bytecode on a virtual machine (i.e. Dalvik) hasn't been happening for like a decade now.

The original claim was that using Java for most of the user space is a power draw. That's essentially what the meme said. So, unless the argument is "that's only because Java is typically executed as bytecode" then it doesn't follow just by itself.

It's seriously not about being pedantic. Either claim wrt energy waste is unsourced and IMO unjustified based on that. Does it drain a lot? I don't know. Does it NOT drain a lot? I don't know either. I haven't seen a comparison. Certainly it must be better than regular usage of Java, but not necessarily by that much. My guesstimate would be that it's rather good FWIW. I'd like to see if there's any comparison of average power consumption between iPhones (Swift user space, IIRC reference counted so with a relatively light runtime, and binary) and Android to get a better idea of this.

EDIT: of course, unless any difference is HUGE the comparison would be worthless, different hardware and all.