Author Topic: Energy consumption for different programming languages  (Read 21556 times)

0 Members and 10 Guests are viewing this topic.

Online tggzzz

  • Super Contributor
  • ***
  • Posts: 23122
  • Country: gb
  • Numbers, not adjectives
    • Having fun doing more, with less
Re: Energy consumption for different programming languages
« Reply #100 on: April 02, 2025, 09:28:17 pm »
Actually several CMSs use Java, which I'm not sure is an interpreted language. Its performance has surprised me quite a bit by how good it is (only 2 times more energy and 1.9 times slower than compiled C).
Considering that there are processors capable of running directly Java bytecode, maybe it should be considered a compiled language.

Modern runtime environments for Java and C# uses Just-In-Time (JIT) compilation, which translates bytecode into native machine code at runtime. Additionally, they offer Ahead-Of-Time (AOT) compilation, allowing bytecode to be precompiled into a native executable. When executing a precompiled application, the runtime verifies whether the bytecode has changed since compilation. If it remains unchanged, the precompiled native code is executed directly. Otherwise, the runtime may either fall back to JIT compilation or produce an error, depending on the configuration.

Today, many programming languages, including JavaScript, use JIT compilation, so it is incorrect to call them interpreted. JIT-compiled languages are also compiled, but the translation into machine instructions happens at runtime on the target system rather than during development. This allows for optimizations tailored to the specific processor executing the code. Unlike the classic C compilation, where the compiler must generate generic code to support multiple processor architectures, a JIT compiler can adapt the instructions in real time, optimizing execution based on the actual hardware.

Java has long had an extra technique, in its HotSpot compiler. HotSpot is effectively profile based optimisation done automatically and concurrently while the program is executing.

It makes optimizations that are impossible for simple JITters and AoT compilers.
There are lies, damned lies, statistics - and ADC/DAC specs.
Glider pilot's aphorism: "there is no substitute for span". Retort: "There is a substitute: skill+imagination. But you can buy span".
Having fun doing more, with less
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->