Interesting. However, I can write something in C that uses all CPU's
100%.
"C Is The Greenest Programming Language" by: Chris Lott
https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
Developing in C is a magnitude more effort than in C++, and if you've
Oh well. As long as it works, who cares? Buy a faster computer.
For instance, I regularly use a variant of std:string that the char
const* constructor checks if the input is from 'read only' memory, and
if it is reuses that data instead of making a copy, at least until in
wants to change it. ...
Le 23/11/2021 à 08:21, Juha Nieminen a écrit :
Oh well. As long as it works, who cares? Buy a faster computer.
This sentence shows that you quite obviously got what "green" means.
In comp.lang.c++ Guillaume <mes...@bottle.org> wrote:
Le 23/11/2021 à 08:21, Juha Nieminen a écrit :
Oh well. As long as it works, who cares? Buy a faster computer.
This sentence shows that you quite obviously got what "green" means.
I have no idea what you are talking about.
Maybe you missed the fact that that sentence you quoted is sarcastic?
But the surprising, and thus interesting result from their paper is that
this is not universally true. You can see one example when looking at
the data for Go and Lisp in the paper:
Go is fast (only 183% slower than C), but energy inefficient (323% more energy consumed than C).
Lisp is slow (240% slower than C) but energy efficient (127% more energy consumed than C).
On 23/11/2021 20:59, Manfred wrote:[...]
The reason is not just because of the added value of the environmental
footprint in today's public opinion; the fact is that heat dissipation
is a major bottleneck in IC technology, so in order for a modern
processor to perform according to nowadays' standards and not melt after
a few minutes of operation, it /has/ to be built with efficient technology.
Absolutely. I remember reading that the first Itanium processors had
higher power densities than the core of a nuclear reactor - these
devices handle a lot of power in a small space, and it all ends up as heat.
But then comes "modern" programming, with all its fuzz of managed code,
JIT gibber, thousands of DLL dependencies, etc., not to forget "modern"
OS's that eat Tflops just to perform even the simplest of tasks, and
there goes all of that efficiency.
Wirth's law - "Software gets slower faster than hardware gets faster" -
is over 20 years old, and there is no sign of a change yet. That's one
of the reasons I like programming small microcontrollers - it's all /my/ code, and there's no fuzz or gibber unless I put it in myself.
On 11/23/2021 11:35 PM, David Brown wrote:
On 23/11/2021 20:59, Manfred wrote:[...]
About anecdotes..The reason is not just because of the added value of the environmental
footprint in today's public opinion; the fact is that heat dissipation
is a major bottleneck in IC technology, so in order for a modern
processor to perform according to nowadays' standards and not melt after >>> a few minutes of operation, it /has/ to be built with efficient
technology.
Absolutely. I remember reading that the first Itanium processors had
higher power densities than the core of a nuclear reactor - these
devices handle a lot of power in a small space, and it all ends up as
heat.
I remember during my university days a professor showing the difference
in power management for different technologies; something like a 1MB RAM
chip built on TTL would have to dissipate kilowatts of power....
Again, I agree that it's a poor way to
express it.
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
On 11/23/2021 6:17 AM, Otto J. Makela wrote:
Lynn McGuire <lynnmcguire5@gmail.com> wrote:
"C Is The Greenest Programming Language" by: Chris LottPerhaps one contributing factor is that not so much development
https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
is any longer done using C or C++, and the programs that are run
(and still being developed) were originally created in the era
when CPU power was much lower than these days, so code
optimization was more important.
I write C++ and Fortran code just about every day for our software
products.
Do you consider this to be a common situation?
"C Is The Greenest Programming Language" by: Chris Lott
  https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
"Have you ever wondered if there is a correlation between a computer’s energy consumption and the choice of programming languages? Well, a
group Portuguese university researchers did and set out to quantify it.
Their 2017 research paper entitled Energy Efficiency across Programming Languages / How Do Energy, Time, and Memory Relate? may have escaped
your attention, as it did ours."
  https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
"Abstract: This paper presents a study of the runtime, memory usage and energy consumption of twenty seven well-known soft- ware languages. We monitor the performance of such lan- guages using ten different
programming problems, expressed in each of the languages. Our results
show interesting find- ings, such as, slower/faster languages consuming less/more energy, and how memory usage influences energy consump- tion.
We show how to use our results to provide software engineers support to decide which language to use when energy efficiency is a concern."
On 11/22/2021 2:19 PM, Lynn McGuire wrote:
"C Is The Greenest Programming Language" by: Chris Lott
https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
"Have you ever wondered if there is a correlation between a computer’s
energy consumption and the choice of programming languages? Well, a
group Portuguese university researchers did and set out to quantify
it. Their 2017 research paper entitled Energy Efficiency across
Programming Languages / How Do Energy, Time, and Memory Relate? may
have escaped your attention, as it did ours."
   https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf >>
"Abstract: This paper presents a study of the runtime, memory usage
and energy consumption of twenty seven well-known soft- ware
languages. We monitor the performance of such lan- guages using ten
different programming problems, expressed in each of the languages.
Our results show interesting find- ings, such as, slower/faster
languages consuming less/more energy, and how memory usage influences
energy consump- tion. We show how to use our results to provide
software engineers support to decide which language to use when energy
efficiency is a concern."
Humm... Perhaps, a main question can be, is there such a thing as a
"green" programmer? One can write crappy and bloated code in C, that
goes much slower than, say Python.
efficient code in C... Therefore, the quality of a programmer seems to
just want to come into play, so to speak...
Using undefined behavior wrt the standard can be a key aspect to writing faster, more efficient code. Possible scenario: This os has built-in User-space Read-Copy-Update (URCU). However, if I use it then my program
is no longer portable...
Can things be greener with a talented programmer and a low-level
language... Yes!
Can things be greener with a crappy programmer and a low-level
language... Humm, No? By chance? Unknown...?
On 23/11/2021 19:59, Manfred wrote:
On 11/23/2021 5:51 PM, David Brown wrote:
On 23/11/2021 16:50, Kenny McCormack wrote:
In article <snivri$15p1$1@gioia.aioe.org>, Manfred
<noname@add.invalid> wrote:
On 11/22/2021 11:19 PM, Lynn McGuire wrote:
Our results show interesting find- ings, such as, slower/faster
languages consuming less/more energy, and how memory usage influences >>>>>> energy consump- tion
I find the correlation slower/faster language respectively less/more >>>>> energy quite confusing. In fact I believe it is the opposite.
Yes. I think this was misstated/sloppily-written in the original text. >>>>
It depends, of course, on what exactly you mean by a "slower" language. >>>> It is true that if you run the CPU at a slower speed (and that would
make
for a slower processing model), then you will use less energy.
It is /not/ true that running the CPU at a slower speed uses less energy >>> - at least, it is often not true. It is complicated.
There are many aspects that affect how much energy is taken for a given
calculation.
Regarding programming languages, it is fairly obvious that a compiled
language that takes fewer instructions to do a task using optimised
assembly is going to use less energy than a language that has less
optimisation and more assembly instructions, or does some kind of
interpretation. Thus C (and other optimised compiled languages like
C++, Rust or Ada) are going to come out top.
It is less obvious how the details matter. Optimisation flags have an
effect, as do choices of instruction (as functional blocks such as SIMD
units or floating point units) may be dynamically enabled. For some
target processors, unrolling a loop to avoid branches will reduce energy >>> consumption - on others, rolled loops to avoid cache misses will be
better. Some compilers targeting embedded systems (where power usage is >>> often more important) have "optimise for power" as a third option to the >>> traditional "optimise for speed" and "optimise for size".
The power consumption for a processor is the sum of the static power and >>> the dynamic power. Dynamic power is proportional to the frequency and
the square of the voltage. And energy usage is power times time.
A processor that is designed to run at high frequency is likely to have
high-leakage transistors, and therefore high static power - when the
circuits are enabled. But the faster you get the work done, the higher >>> a proportion of the time you can have in low-power modes with minimal
static power. On the other hand, higher frequencies may need higher
voltages.
As a rule of thumb, it is better to run your cpu at its highest
frequency - or at the highest it can do without raising the voltage -
and get the calculation done fast. Then you can spend more time in
low-power sleep modes. However, entering and exiting sleep modes takes >>> time and energy, so you don't want to do it too often - hence the
"big-little" processor combinations where you have a slower core that
can be switched on and off more efficiently.
I am not sure about that "rule" - in general modern integrated
electronics waste most energy during state transitions, and that is
directly coupled with clock frequency, but I admit there may be more
to it that I don't know.
One consideration about the balance between clock speed and efficiency
is that it is totally relative to how old the technology is. I am
pretty confident that an old Pentium is much less efficient than a
modern i7 (just to consider popular PC stuf only), even if the latter
runs faster than the former.
The reason is not just because of the added value of the environmental
footprint in today's public opinion; the fact is that heat dissipation
is a major bottleneck in IC technology, so in order for a modern
processor to perform according to nowadays' standards and not melt
after a few minutes of operation, it /has/ to be built with efficient
technology.
But then comes "modern" programming, with all its fuzz of managed
code, JIT gibber, thousands of DLL dependencies, etc., not to forget
"modern" OS's that eat Tflops just to perform even the simplest of
tasks, and there goes all of that efficiency.
This is why talk of the greenest language is nonsense.
How about writing efficient applications?Yes, and that includes choosing the right language.
might be 1000 processes on my PC right now).That's a different matter than applications. It still affects overall
Access any webpage, and the fast download speeds mask how much data is
being transmitted, which all still requires code to process it. Hardware
can barely keep up.
Or, how about efficient compilers? David Brown always contemptuously dismisses mine even though they are fast, yet they show that the basic
job of source->binary translation can be done 1-2 magnitutes faster than
the heavy-duty compilers he favours.
(For a couple of years one of my compilers was run as interpreted,
dynamic bytecode. It was still double the speed of gcc!)
On Wed, 24 Nov 2021 11:54:50 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
I doubt I could for example write a RB tree system better than thatimplemented
in the C++ STL. It has 30 years of refining behind it.
So you can directly implement that algorithm in C. yes, it gets messier,
but you CAN do it.
But there's no guarantee that it would be any faster.
Indeed, but your argument that C always produces more efficient code than C++
probably hasn't been true for 20 years.
FLAW: Not ALWAYS, but CAN, big difference.
Yes, C++ idioms can generate complex code faster than C, and allows
things to be put into libraries that C can't readily do, and thus an
expert can right the library and 'lend' that expertise to an ordinary
code by them using the library. A custom coded C version can do just as
well, because you can express the same instruction sequences in C as
were generated in C++, you just need to be or explicit about it.
Not always. eg:
#include <iostream>
constexpr int func(int cnt)
{
int val = 1;
while(--cnt) val *= 2;
return val;
}
int main()
{
constexpr int val = func(10);
std::cout << val << std::endl;
return 0;
}
In C++14 and onwards func() will literally be run by the compiler at compile time and the result hard coded into the binary. No C compiler can do that not because the language couldn't do it in theory, but because its never been specified in the standard.
On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
I doubt I could for example write a RB tree system better than that >implemented
in the C++ STL. It has 30 years of refining behind it.
So you can directly implement that algorithm in C. yes, it gets messier,
but you CAN do it.
Indeed, but your argument that C always produces more efficient code than C++
probably hasn't been true for 20 years.
FLAW: Not ALWAYS, but CAN, big difference.
Yes, C++ idioms can generate complex code faster than C, and allows
things to be put into libraries that C can't readily do, and thus an
expert can right the library and 'lend' that expertise to an ordinary
code by them using the library. A custom coded C version can do just as
well, because you can express the same instruction sequences in C as
were generated in C++, you just need to be or explicit about it.
In comp.lang.c++ DozingDog@thekennel.co wrote:
constexpr int func(int cnt)
{
int val = 1;
while(--cnt) val *= 2;
return val;
}
int main()
{
constexpr int val = func(10);
std::cout << val << std::endl;
return 0;
}
In C++14 and onwards func() will literally be run by the compiler at compile >> time and the result hard coded into the binary. No C compiler can do that not
because the language couldn't do it in theory, but because its never been
specified in the standard.
Actually gcc (and probably clang) will inline that function and calculate it >at compile time in C. You'll need a much more complicated constexpr function >for it to not be calculated at compile time by the compiler in C.
"C Is The Greenest Programming Language" by: Chris Lott
  https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
"Have you ever wondered if there is a correlation between a computer’s energy consumption and the choice of programming languages? Well, a
23.11.2021 00:19 Lynn McGuire kirjutas:
"C Is The Greenest Programming Language" by: Chris Lott
https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
"Have you ever wondered if there is a correlation between a computer’s
energy consumption and the choice of programming languages? Well, a
In my experience, any efforts towards more efficient software are easily defeated by users throwing more data to the program.
Wow, so you can fully analyze a 1024x1024 microscope image in less than
a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
in the next version!
So, you managed to speed up the calculation time of morphological
features by 50%. Fine, now we want to calculate 1000 features instead of
the former 20!
Thus I'm afraid any hopes for a "green" programming language are at best naïve.
In my experience, any efforts towards more efficient software
are easily defeated by users throwing more data to the program.
[...] Most object-oriented languages don't really care about,
especially, memory consumption. Especially garbage-collected OO
languages don't give a flying F about memory consumption. [...]
A humorous statement, considering that there were OOP systems,
including garbage collection, running years before even the
predecessor to C++, "C with Classes", existed.
Note by the way that using garbage collection very likely reduced
the overall memory footprint, because all the places where there
would have been code to free memory no code is needed, replaced
by a single piece of code in the memory manager.
Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code <861r2c4k8w.fsf@linuxsc.com> thusly:
A humorous statement, considering that there were OOP systems,
including garbage collection, running years before even the
predecessor to C++, "C with Classes", existed.
Are you thinking of Smalltalk or LISP?
Note by the way that using garbage collection very likely reduced
the overall memory footprint, because all the places where there
would have been code to free memory no code is needed, replaced
by a single piece of code in the memory manager.
An interesting hypothesis, but I'm not convinced without data.
A humorous statement, considering that there were OOP systems,
including garbage collection, running years before even the
predecessor to C++, "C with Classes", existed. And these systems
ran on hardware platforms that don't have enough memory to run
probably any C++ compiler of the last 20+ years.
Note by the way that using garbage collection very likely reduced
the overall memory footprint, because all the places where there
would have been code to free memory no code is needed, replaced
by a single piece of code in the memory manager.
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
A humorous statement, considering that there were OOP systems,
including garbage collection, running years before even the
predecessor to C++, "C with Classes", existed. And these systems
ran on hardware platforms that don't have enough memory to run
probably any C++ compiler of the last 20+ years.
Note by the way that using garbage collection very likely reduced
the overall memory footprint, because all the places where there
would have been code to free memory no code is needed, replaced
by a single piece of code in the memory manager.
What systems had so little memory that they couldn't even run a C++
compiler, yet had an operating system that offered a memory manager
with GC? And, ostensibly, was a multitasking OS (given that you are
arguing the programs had an overall smaller memory footprint).
There was no operating system in the conventional sense of the
term. Garbage collection was part of the VM underlying the
OOP environment. Multitasking was done in and by the OOP
environment itself, with "stack frames" being objects, and so
could be queued for later resumption, switched between, etc.
Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code <86v8zl29yr.fsf@linuxsc.com> thusly:
There was no operating system in the conventional sense of the
term. Garbage collection was part of the VM underlying the
OOP environment. Multitasking was done in and by the OOP
environment itself, with "stack frames" being objects, and so
could be queued for later resumption, switched between, etc.
Smalltalk and LISP Machine environments are really quite different
from what we assume computers are like today. [...]
legalize+jeeves@mail.xmission.com (Richard) writes:
Smalltalk and LISP Machine environments are really quite different
from what we assume computers are like today. [...]
Lisp machines are special purpose hardware. Smalltalk VMs
run on standard hardware, much like Java bytecode interpreters
do today.
Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code <86lezftoq5.fsf@linuxsc.com> thusly:
legalize+jeeves@mail.xmission.com (Richard) writes:
Smalltalk and LISP Machine environments are really quite different
from what we assume computers are like today. [...]
Lisp machines are special purpose hardware. Smalltalk VMs
run on standard hardware, much like Java bytecode interpreters
do today.
I was thinking of the Smalltalk workstations from the 80s like those
made by Tektronix. I don't think they used a VM, but ran on the bare
metal.
As I recall Tektronix was one of four companies licensed by Xerox
to port a Smalltalk-80 VM to other systems. One motivation for
offering these licenses was to help debug the writing in
"Smalltalk-80: The language and its implementation", where most
of the implementation part was about how the VM works and how to
write one. Given that, it would be strange if the Tektronix
effort did not use a VM but instead ran a standard Smalltalk
image on bare hardware.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 113 |
| Nodes: | 8 (1 / 7) |
| Uptime: | 06:12:17 |
| Calls: | 2,497 |
| Calls today: | 14 |
| Files: | 8,644 |
| Messages: | 1,902,088 |