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.

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? And efficient OSes (there
might be 1000 processes on my PC right now).

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 11/22/2021 11:10 PM, Juha Nieminen wrote:
> In comp.lang.c++ Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Interesting. However, I can write something in C that uses all CPU's
>> 100%.
>
> I don't think that's the point.
>

Humm... I was just thinking along the lines of 'what does the C code
actually do?' If it ends up blasting the system, how green is it? Well,
yeah, that is a different point. You are right Juha.

On 11/22/2021 11:10 PM, Juha Nieminen wrote:
> In comp.lang.c++ Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>> Interesting. However, I can write something in C that uses all CPU's
>> 100%.
>
> I don't think that's the point.
>

Side note: Humm... Perhaps we can say that lock-free is "greener" than
using locks. Say a computation using a nice lock-free algo takes 5
minutes. Vs, something using locks that takes 30 minutes to get the same
result. I remember back in the day where I had to terminate the
lock-based tests because they took way too long.

On 24/11/2021 09:50, Bart wrote:
>
> 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!)
>

Well if it generates unoptimised code, it is still not very "green" is
it? Unless you are compiling often and running once...

--
Ian.

On 23/11/2021 20: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.
>

That is correct. There are two aspects to the energy usage of the
switching - there is the charge transfer that depends on the capacitance
of the gates and the voltage, and there is the leakage current during
switching while the gate is half-open. The first is pretty much
independent of frequency of switching, so the same transitions (i.e.,
the same calculations) take the same energy regardless of how fast they
are done. The second is dependent on the switching speed, which goes up
with the voltage (that's why you increase the voltage for higher
frequencies, to get shorter switching times - a higher voltage pulls the
electrons across the gaps faster). The switching time is basically
independent of the switching frequency, except that it has to be shorter
to support higher frequencies. I believe (and this is getting a bit
outside my knowledge) that for CPU internals, it is the charge transfer
that dominates, not the loses during the switching period.

(I have plenty of practical experience with low-power devices, but that
is primarily for microcontrollers. If people really want to go into
depth about the power consumption of "big" processors, it would probably
make more sense to start a thread in comp.arch rather than in C and C++
groups. There are folks over there who have worked on serious cpu
design and know a lot about this stuff.)

> 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.

Yes, mostly. Modern devices have smaller geometries - that means faster
switching times and less capacitance, so smaller charge transfers and
lower dynamic power for the work done. But it also means more leakage
and thus more static power. And in order to get higher clock
frequencies and more instructions per clock, pipelines are longer, paths
are wider, there is more speculative execution, branch prediction,
caching, and all the rest of it. These features don't actually
contribute anything to the work being done. Thus an old Pentium running
a given piece of code will involve perhaps orders of magnitude fewer
transistor switches than you would have in a modern i7. (This is
another reason for the big-little pairings for low-power processors -
the simpler "little" cpu will have fewer switches and less energy than
the "big" cpu for the same real work, regardless of frequency.)

Modern devices also have much smarter power and clock gating that was
simply not used in older devices - otherwise the static leakage power
would be far too high.

> 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 23/11/2021 21:50, Bart wrote:
> On 23/11/2021 19:59, Manfred wrote:

>> 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.
>

Agreed (mostly).

> How about writing efficient applications? And efficient OSes (there
> might be 1000 processes on my PC right now).

Yes - it is the software that takes energy, not the language. It's fair
to say that the software does a lot more now than it used to, but it's
equally fair to question whether that extra work is necessary.

>
> 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.
>

Yes. But that is because I understand the difference between compiling
code and /running/ compiled code. As long as your compilation process
is not so slow that it hinders the development process, it doesn't
matter. If a program is only going to be used on a few systems or by a
few people, then the dominant cost is the programmer (and their energy
needs massively outweighs the compiler's). If it is going to be used a
lot, then the dominant cost is the target systems' runtime (and thus you
want as efficient results as you can get from the source code). At no
point is the effort or energy required by the compiler at all relevant
in the total sum.

On 23/11/2021 22:18, Ian Collins wrote:
> On 24/11/2021 09:50, Bart wrote:
>>
>> 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!)
>>
>
> Well if it generates unoptimised code, it is still not very "green" is
> it?

Well, so was gcc-O0, which was how the comparison was made. Otherwise
the disparity would have been greater.

And aside from the speed, my stuff also tends to be small, so also
economising on storage, loading, storing, downloading, memory...

Here are compilation rates for my tools (build from source), using my
current compiler:

mm 10 Hz (main compiler)
pc 14 Hz (IL project, my version of llvm)
aa 20 Hz (assembler/linker)
qq 10 Hz (interpreter)
bcc 9 Hz (C compiler)

10 Hz means I can build the project 10 times in one second (and using
one core). I'd be interested to see the equivalent figure for gcc or llvm.

If it was only running my stuff, my PC would have very little to do!

> Unless you are compiling often and running once...

During development that's exactly what you do.

For a production program, then yes you can go to town on optimising,
because you don't do it repeatedly.

On Tuesday, 23 November 2021 at 18:05:14 UTC, Bonita Montero wrote:
> > ANYTHING in terms of data-structures that another language can generate,
> > you can generate in C.
> With a lot of effort compared to C++.
> > The big disadvantage is that YOU as the programmer need to deal with a
> > lot of the issues rather than to compiler doing things for you, but that
> > is exactly why you can do things possibly more efficiently then the
> > compiler. You could have always generated the same algorithm that the
> > compiler did.
> Why shoul one use sth. different than std::vector<>, std::string,
> std::unordered_map<> ... ? There are no opportunities to make the
> same more efficient.
>
You don't implement C++ in C. Instead of an std::string, you use a fixed
buffer. That means you'll have problems if the string exceeds buffer length,
but often that's not really a worry - C++ is giving you security it's nice to
have, but you don't actually need.

On Tuesday, 23 November 2021 at 18:53:16 UTC, Bonita Montero wrote:
> Am 23.11.2021 um 19:41 schrieb Richard Damon:
>
> > 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. ...
>
> Then use string_view.
>
Herb Sutter did a video on C++ a while back, where he discussed how to
write "Employee::SetName" in C++. As he said, it's a crime if there is no
easy answer. But in fact there is no easy answer.
In real programming you'd write SetName(std::string const &name), or
maybe SetName(const char *name). But that's not optimal, and it creates
problems with throwable exceptions.
But messing about with string_views, move semantics, and the like adds
complexity to your program. And the program is unlikely to fail because
your string handling isn't fast enough.

On 11/23/2021 1:21 AM, Juha Nieminen wrote:
> In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:
>> Well since one of the goals of the C Language was to enable programmers
>> to write fast code, it can makes sense for C to be 'Green', at least by
>> some measures.
>>
>> Fast code will be more energy efficient as processors basically use
>> power based on the number of instructions executed (and memory accessed).
>
> I think that for as long as programmable computers have existed, there has
> been a direct correlation between the "levelness" ("higher-level" vs.
> "low-level") of a language and disregard towards how much resources the
> language uses. As computers have become faster and faster, and the amount
> of resources (primarily RAM) has increased, this indifference towards
> resource consumption in higher-level languages has only likewise
> increased.
>
> The farther away the design of the language has been from the details of
> the underlying hardware, the more the question of "how efficient is
> the language, and how much RAM does it consume?" has been (implicitly
> or explicitly) answered with, essentially, "it doesn't matter" and
> "who cares?"
>
> Take pretty much any scripting language, or any other interpreted
> language (like the original BASIC and most of its subsequent variants).
> Pretty much nobody cared how fast they are, or how much RAM they
> consume. When someone is, let's say, implementing something in PHP
> they seldom stop to think how much memory it consumes or how fast it is.
> When someone is implementing something in shell script, one most
> definitely does not think about speed or memory consumption.
>
> 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. So what if an object needs
> something like 16 or 32 bytes of bookeeping data? Who cares? That's
> nothing! Trivial and inconsequential! Modern computers have gigabytes
> of RAM! Why should you care if an object takes 32 bytes in addition
> to whatever is inside it? What a silly notion!
>
> Ironically, the programming world has in the last couple of decades awakened
> to the harsh realization that this complete disregard of memory usage
> actually causes inefficiencies in modern CPU architectures (because
> cache misses are very expensive).
>
> Oh well. As long as it works, who cares? Buy a faster computer.

Not in California.
https://nichegamer.com/high-end-gaming-pcs-banned-in-six-us-states-after-california-energy-bill-limits-sales-on-high-performance-pcs/

Lynn

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 Lott
>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>
> Perhaps one contributing factor is that not so much development 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.

Lynn

On 11/23/21 1:53 PM, Bonita Montero wrote:
> Am 23.11.2021 um 19:41 schrieb Richard Damon:
>
>> 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. ...
>
> Then use string_view.
>

Doesn't work.

I have a lot of long lived object that store a string with a 'name' of
the object.

Most are created with a fixed compile time name that I pass as a const
char* string to a read only literal.

A few cases need to dynaically create a name based on specific usages,
so these need that name stored as a dynamic value, but that memory wants
to be reclaimed if/when the long lived object does go away.

string_view doesn't help here, as when I create the few dynamic names,
there is no place to keep that char array that is holding the name.

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 Lott
>>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>> Perhaps one contributing factor is that not so much development
>> 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?
--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

DozingDog@thekennel.co wrote:

> On Tue, 23 Nov 2021 14:17:50 +0200
> om@iki.fi (Otto J. Makela) wrote:
>>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>
>>> "C Is The Greenest Programming Language" by: Chris Lott
>>> https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>
>>Perhaps one contributing factor is that not so much development 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.
>
> Its good to see the attitude of just throw more CPU at something
> instead of optimising it is still around. These days when server
> farms are taking up a siginificant percentage of the planet's
> electrical output its beholder on programmers to make their code
> as efficient as is reasonable.

I keep rereading that first sentence, is the meaning reversed?

--
/* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
/* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
/* Mail: Mechelininkatu 26 B 27, FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

Am 23.11.21 um 00:25 schrieb Richard Damon:
>
> Well since one of the goals of the C Language was to enable programmers
> to write fast code, it can makes sense for C to be 'Green', at least by
> some measures.
>
> Fast code will be more energy efficient as processors basically use
> power based on the number of instructions executed (and memory accessed).

The paper mentions that that is a common assumption, but not true.

Looking at table 4, we see that C is in the top spot both when it comes
to fast code and energy efficient code. And many other languages also
rank similarly in energy consumption as they do in speed. But there are
others. E.g.:

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).

In comp.lang.c++ Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
> On 11/22/2021 11:10 PM, Juha Nieminen wrote:
>> In comp.lang.c++ Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
>>> Interesting. However, I can write something in C that uses all CPU's
>>> 100%.
>>
>> I don't think that's the point.
>>
>
> Humm... I was just thinking along the lines of 'what does the C code
> actually do?' If it ends up blasting the system, how green is it? Well,
> yeah, that is a different point. You are right Juha.

I am assuming that the article considers the cases where the CPU is at
full load in all the cases, with the program having been implemented
with different programming languages. The faster the program is done,
the less overall energy it will require. If a C program does the job
in 1 second and a PHP program does it in 30 seconds, it's obvious that
the C program is going to consume less energy for the same task.

So it's not a question of "how many % of the CPU can I use with this
programming language", but "how long do I need to use the CPU in
order to perform this task".

In comp.lang.c++ Guillaume <message@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?

Am 23.11.21 um 16:03 schrieb Manfred:
> 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.
>

Well, the do state in the paper that the common assumption is that
faster languages are more energy efficient. And their data supports that
this assumption actually hold for many languages.

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).

Am 24.11.21 um 11:54 schrieb Juha Nieminen:
>
> So it's not a question of "how many % of the CPU can I use with this
> programming language", but "how long do I need to use the CPU in
> order to perform this task".
>

On the other hand, the energy consumption of that CPU during that time
also depends on what it is doing (and to some degree an what data it is
processing). People have been doing side-channel attacks on cryptography
by very accurately measuring the energy consumption of the computers
doing the encrypting or decrypting.

Long ago, for fun, I did measure the energy consumption of a Z80 (in a
ColecoVision) with reasonably high time resolution (current probe on
oscilloscope). From the trace of the energy consumption, I could see
which instructions were executed.

On 24/11/2021 12:01, Philipp Klaus Krause wrote:
> Am 24.11.21 um 11:54 schrieb Juha Nieminen:
>>
>> So it's not a question of "how many % of the CPU can I use with this
>> programming language", but "how long do I need to use the CPU in
>> order to perform this task".
>>
>
> On the other hand, the energy consumption of that CPU during that time
> also depends on what it is doing (and to some degree an what data it is
> processing). People have been doing side-channel attacks on cryptography
> by very accurately measuring the energy consumption of the computers
> doing the encrypting or decrypting.
>
> Long ago, for fun, I did measure the energy consumption of a Z80 (in a
> ColecoVision) with reasonably high time resolution (current probe on
> oscilloscope). From the trace of the energy consumption, I could see
> which instructions were executed.
>

I used to debug my assembly code on my ZX Spectrum (with a Z80 cpu) by
the sound of the power supply.

However, with modern cpus there is so much going on that you are
unlikely to get much detail by tracking power consumption. You could
perhaps distinguish when blocks such as SIMD or the FPU are active, but
otherwise there are so many instructions in flight at a time that you
could not identify them. Differential power analysis for cryptoanalysis
is almost entirely a thing of the past. (It could be practical for
simpler processors and dedicated cryptography devices, except that
designers of these things are usually aware of such attacks and they are
easily blocked.)

On 23/11/2021 22:46, David Brown wrote:
> On 23/11/2021 21:50, Bart wrote:

>> 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.
>>
>
> Yes. But that is because I understand the difference between compiling
> code and /running/ compiled code. As long as your compilation process
> is not so slow that it hinders the development process,

I find compilers such as gcc slower enough that they would hinder /me/.
I can build my 3 main language tools, about 120Kloc and 100 files, in
1/4 second, the same time it takes gcc to build hello.c, about 4 lines
in one file.

> it doesn't
> matter. If a program is only going to be used on a few systems or by a
> few people, then the dominant cost is the programmer (and their energy
> needs massively outweighs the compiler's). If it is going to be used a
> lot, then the dominant cost is the target systems' runtime (and thus you
> want as efficient results as you can get from the source code). At no
> point is the effort or energy required by the compiler at all relevant
> in the total sum.

It was a example of the sort of program that I can make run efficiently
by making some extra effort, and also keeping things small, which
actually was not written in C.

It isn't about language, except that everything else being equal, a C
implementation of a computationally intensive application like mine is
going to be faster than an equivalent CPython version, and mostly likely
still faster than PyPy.

So if gcc was implemented in CPython, compiling hello.c might takes 10
seconds instead of 0.25 seconds, but tcc does the job in 0.03 seconds.

Consider that on my machine, even an empty program takes 0.02 seconds to
run...

On 11/23/2021 11:35 PM, David Brown wrote:
> 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.
>
About anecdotes..
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....

>> 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 24/11/2021 14:30, Manfred wrote:
> On 11/23/2021 11:35 PM, David Brown wrote:
>> 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.
>>
> About anecdotes..
> 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....

Well, using the 74LS189 device, which contains 64 bits of RAM, then you
would have more practical problems first, such as needing 130,000 of the
things to make 1MB, plus all the address decoding circuitry.

It might be quite a few kilowatts you'd need.

On Tue, 23 Nov 2021 12:28:12 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
>On 11/23/21 11:55 AM, DozingDog@thekennel.co wrote:
>> On Tue, 23 Nov 2021 14:39:08 +0100
>> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> Developing in C is a magnitude more effort than in C++, and if you've
>>
>> That depends on the problem. If you're writing code that needs to store a
>> lot of structured data then C wouldn't be your first choice of language. But
>> if you're writing something that simply interfaces with system calls then
>> there's probably not much if any extra effort in using C over C++.
>>
>
>I would disagree. With a decent compiler, C code can generate close to
>assembly level optimizations for most problems. (Maybe it doesn't have

So can a C++ compiler and with modern additions such constexpr C++ can optimise
in ways that C simply can't.

>ANYTHING in terms of data-structures that another language can generate,
>you can generate in C.

True, but you have to re-invent the wheel each time because frankly the level
of complex data structure library support in the standard library in C is
woeful. Eg the hsearch() and bsearch() functionality are frankly rubbish (only
1 tree/hash per process!) and Berkeley DB is a PITA to use.

>The big disadvantage is that YOU as the programmer need to deal with a
>lot of the issues rather than to compiler doing things for you, but that
>is exactly why you can do things possibly more efficiently then the
>compiler. You could have always generated the same algorithm that the
>compiler did.

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.

>Now, if you want to talk of the efficiency of WRITING the code, (as
>opposed to executing it) all this power it gives you is a negative,
>which seems to be what you are talking about.

Indeed, but your argument that C always produces more efficient code than C++
probably hasn't been true for 20 years.