(untitled)

Do modern day programmers put too little empathis on the energy consumption of their programs?

I guess so. I wouldn't even know what to look for in my program to optimize it in that regard. Compared to performance, which is at least a little bit understandable to human intuition, energy consumption seems quite magical.

What's with the distinction of "modern day"? Programmers of the past never cared about this junk.

Wasn't Lua supposed to be fast?

>>5229 considering java's running in a vm, it's doing pretty damn good

>>5233 lol, did you read the thread? It isn't about performance but energy consumption

>>5237 Dude, second column of the damn chart.

>>5229 How did the data for this table collected? Some of those value seem strange.

>>5239 http://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf

>>5230 Honestly, it's mostly a question of how well you've built multithreading(does it busy-wait ever, etc.), how often you access memory, and how well you've serialized your operations to work well with the processor.

Basically, it looks like the main factors are a lightweight runtime and efficient CPU usage. Total memory used seemed to be mostly uncorrelated with energy consumption which allowed Java to do fairly well.

>>5229 No. Look at the graph, nobody is running Perl code 24/7 The web people are the only group that actually runs extremely uneffcient code.

performance = energy efficiency. period, the end. the faster your program executes, the more time your CPU can spend idle. The problem is modern programmers ignoring performance gains that don't effect the UX on an 8GB/quad core intel desktop processor. They basically think it's ok to pollute the OS with a bunch of ram usage and heavy threads/JS even if it kills battery/the environment.

>>5250 >performance = energy efficiency. period, the end. the faster your program executes, the more time your CPU can spend idle. performance is not a real energy/work metric, its as stupid buzzword people use to hype obsolete languages. the whole 'less is more' meme died when CISC killed RISC

>>5251 Now just when did RISC get killed off? It seems to still be relevant. In fact it seems to be more relevant than CISC.

>>5233 LuaJIT makes it fast, and they're probably not using that.

>>5256 theyre cheap to make and easy to port to which is why they get used in servers a lot

>>5240 After reading the paper I have a feeling that the author of this paper tried very hard to convince the readers that there is more to "faster execution == less power consumption", but in my regards he failed to do so. If we will look closely on the data provider then only Go ranks as 14 in energy and 7 in time (maybe some measurement error?), all the other languages are more or less very close in the energy/time ranking (example PHP energy: 21, time: 20, or Fortran energy: 10, time 14). In my understanding those are negligible differences. The paper also gives only detail information about 3 (out of 10) problems they measure time and energy consumption on (And based on that data the differences in faster languages is less power hungry is more clearly seen in my opinion.). Looking on the CPU level, less CPU instruction will cause shorter execution time of a program but also less power consumption as the CPU has less to do. Yes some languages score better than other during those tests but its because under the hood they do less then other languages (maybe we should program everything in assembly for the best energy efficiency?). The paper does not give also any hint what to do to write energy efficient code (except stating that you should use languages that score better on the test) because they simply can't point out what should be done. Besides, on the end of the day you will never be looking on how much power the application will use when considering which language to use (and if you will then according to this paper you should use only C, Rust, C++, Ada and Java), because a good implementation of a algorithm will be more important than the language you use (considering you won't try to use scripting languages for low level stuff, or low level languages to implement abstract things).

>>5305 >"faster execution == less power consumption", Wouldn't memory access be a factor that impacts performances but not power? I mean a language that uses multiple levels of pointer indirection to support virtual functions and reflection and crap like that. Those extra layers of memory indirection will slow down the execution time but not necessarily add load to the CPU right? At worst the CPU is just idle while waiting for IO. >Do modern day programmers put too little empathis on the energy consumption of their programs? No. If you are writing code under an OS, then power consumption is not your problem. If you don't have an OS, then C/C++/Ada are your only options anyway.

>>5233 It's those results that are stupid. Performance isn't a property of a language. It's a property of the language's implementation. Publishing performance comparisons of C and Lua is a clear sign that the author has no understanding of what he's measuring. Lua has at least two implementations that I'm aware of: the Lua virtual machine written by programmers from PUC-Rio, and Lua JIT written by some wizard. C has countless implementations; every single C compiler out there is a completely distinct implementation.

>>5229 They do! Modern power-management techniques are so advanced that software running on your phone can get your precise location by measuring battery voltages and correlating them to cell tower map. Purely magnificent!

>>5308 >Wouldn't memory access be a factor that impacts performances but not power? True, but only up to a point. Let assume we have program A and B written in two different languages. Let assume that those programs implement the same solution to a given problem but program A works slower and need less power to execute. Program A works slower because of a lot of memory IO. But we also assume that both programs implement the same solution (only implemented in a different language), so on a basic computation level we need to be doing the same operations (add those two numbers, sort this list, calculate sqrt, and so on). So the only reason that A would have more memory IO is that the language used to create A implements some additional memory management (think not mutable variables in let's say python, or a garbage collector). But this also means that the CPU needs to use more instructions to handle this extra memory management. So A can't use less power because it uses more CPU instructions to perform additional memory management. At the end of the day it really boils down to the number of operation the CPU performs. And don't forget that when you compile a program to bytecode there isn't something like virtual function on that level any more. This is a abstraction used by an programming language and not the CPU. The above reasoning should hold also if we are talking about program A and B used in a interpeter.

>>5346 >So A can't use less power because it uses more CPU instructions to perform additional memory management. Yes A will never be faster than B. What I mean is the gap between performance may be large but the gap between execution time might not be if the extra latency is only IO. So really there may not be a definite correlation between execution time and power consumption. >And don't forget that when you compile a program to bytecode there isn't something like virtual function on that level any more. This is a abstraction used by an programming language and not the CPU. Virtual functions are a form of run time polymorphism so extra code needs to run on the CPU, it's not just a language abstraction. Usually it takes the form of an extra table of pointers like C++ vtables, which is where the memory IO argument comes from.

>>5357 Oh, OK. Now I see what you mean. Yeah you might be right.