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

Lynn

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

Interesting. However, I can write something in C that uses all CPU's
100%. So, green okay... What is it doing, is another matter, so to speak?

On 11/22/21 5: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."
>
> Lynn

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

What also needs to be considered is the time/energy needed to initially
WRITE the code and get it working, and then factor in how many times the
program will be used compared to the effort to write it.

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.

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.

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

On Tuesday, November 23, 2021 at 4:21:44 AM UTC-3, Juha Nieminen wrote:
....
> Oh well. As long as it works, who cares? Buy a faster computer.
Everything costs money, especially on cloud solutions.

Am 22.11.2021 um 23:19 schrieb Lynn McGuire:
> "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."

Developing in C is a magnitude more effort than in C++, and if you've
the right programming-style you get the same code speed like in C. And
sometimes you're even faster in C++ and in C you'd shoot yourself in
your head instead of implementing the complexity you can handle in C++
in minutes.

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.

An interpreted language (á la Java :O) may require orders of magnitude
more CPU instructions than C to perform the same task. This makes the
former slower and more energy consuming than the latter.

Slower or faster /hardware/ is a totally different thing, of course.

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.

--
https://en.wikipedia.org/wiki/Mansplaining

It describes comp.lang.c to a T!

On 23/11/2021 15:03, Manfred 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.
>
> An interpreted language (á la Java :O) may require orders of magnitude
> more CPU instructions than C to perform the same task.

Java is probably not a good example.

Properly interpreted code may need 1-2 magnitudes more instructions as
it has to perform the task indirectly (this is with dynamic typing).

But this is only relevant if the processor is executing 100% indirect
code versus 100$ direct code.

In practice it will be a mix, which if done properly makes means the
overheads of interpretation are not significant.

More significant is overall design: you can write slow, bloated,
inefficient programs in C too!

Also many interpreted languages are now JIT-accelerated, to close the gap.

This makes the
> former slower and more energy consuming than the latter.
>
> Slower or faster /hardware/ is a totally different thing, of course.

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.

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.

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

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.

On Tue, 23 Nov 2021 17:51:09 +0100
David Brown <david.brown@hesbynett.no> wrote:
>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.

Why do many battery powered systems throttle the CPU to save the battery when
its getting low then and why does undertaking CPU intensive tasks deplete the
battery faster? You seem to be claiming that you can get something for nothing.

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
good support for defining Multiple Datapath Single Instruction
sequences, but a GOOD compiler maybe be able to detect and generate this).

ANYTHING in terms of data-structures that another language can generate,
you can generate in 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.

The one point where the compiler can do better is if there is a piece
like instruction sequencing to optimize performance, but that is where
the C language gives the implementation the freedom to adjust things to
allow for that.

The C language, with the common extensions, give you the power to do as
well as any other language.

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.

If we want to talk 'Greenness', we need to define the development/usage
life cycle of the code.

On 11/23/21 12:00 PM, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 17:51:09 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> 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.
>
> Why do many battery powered systems throttle the CPU to save the battery when
> its getting low then and why does undertaking CPU intensive tasks deplete the
> battery faster? You seem to be claiming that you can get something for nothing.
>

CPUs, at a given operating voltage will consume an approximately fixed
amount of energy per instruction.

One effect of slowing down the processor is that if it was running at
25% utilization, that means that 75% of the instructions executed did no
'useful' work, so slowing down the processor to make instructions take
longer means you do less of these wasteful cycles.

Some processors have the ability that when it get to those 'wasteful'
instructions it automatically 'stops' and drops its power concumption
until something happens that needs running again.

The other affect is that in many cases if you slow down the processor
speed, you can slightly drop the voltage you are running the processor
at, and the power consumed turns out to go largely as the square of the
voltage (as the dynamic power is consumed in charging and discharging
tiny capacitance through the system)

So, through various tricks in the system, you can sometimes save some
power when the processor is 'idle' or running 'slower'. Battery powered
system especially try to implement these sorts of capability.

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

On 23/11/2021 18:00, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 17:51:09 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> 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.
>
> Why do many battery powered systems throttle the CPU to save the battery when
> its getting low then and why does undertaking CPU intensive tasks deplete the
> battery faster? You seem to be claiming that you can get something for nothing.
>

If you have to do a certain calculation or set of calculations, it is
/usually/ more efficient to do them quickly and then let the processor
sleep deeper and longer.

Modern cpus generally do /not/ throttle the cpu speed to save battery
power. It only makes sense to slow down the processor if you have large
leakage currents that you can't turn off, in which case a slow clock can
mean lower energy overall. With modern devices, clock gating lets you
turn off all or parts of the core much more effectively.

On 11/23/21 1:05 PM, 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.
>

Except where there are.

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. This saves me a LOT of memory in embedded systems
where most of my 'string' data is constant, but some spedific cases need
to dynamically compute the string.

The C++ standard library is very good code for the general case. There
can be cases where specific application requirements make alternative
better.

As I said, the fundamental issue is the trade off of final execution
efficiency for efficiency in writing the code.

C++ keeps a lot of the efficiencies of C, and adds some significant
'power' to the expresiveness. But sometimes implementing the C++
features directly in C while needing more coding by the programmer can
make some things more efficient.

For example, rather than letting the C++ class system implicitly handle
the 'vtable' for a class, there are tricks you can do to make some
operation more efficient in C with an explicit vtable (at the expense of
it adding all the explicit code). Things like changing the 'type' of a
structure to that of another compatible type with just a change of the
vtable pointer.

On 11/23/21 1:24 PM, David Brown wrote:
> On 23/11/2021 18:00, DozingDog@thekennel.co wrote:
>> On Tue, 23 Nov 2021 17:51:09 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>> 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.
>>
>> Why do many battery powered systems throttle the CPU to save the battery when
>> its getting low then and why does undertaking CPU intensive tasks deplete the
>> battery faster? You seem to be claiming that you can get something for nothing.
>>
>
> If you have to do a certain calculation or set of calculations, it is
> /usually/ more efficient to do them quickly and then let the processor
> sleep deeper and longer.
>
> Modern cpus generally do /not/ throttle the cpu speed to save battery
> power. It only makes sense to slow down the processor if you have large
> leakage currents that you can't turn off, in which case a slow clock can
> mean lower energy overall. With modern devices, clock gating lets you
> turn off all or parts of the core much more effectively.
>

Not sure if this holds for desktop/laptop caliber processors, but in the
embedded world, many processors can have their core voltage dropped down
when running at slower speeds, and since switching energy is
proportional to V^2, slowing the processor and waiting less CAN save power.

I beleive this applies to processors with a 'Turbo' or 'Overclocked'
mode in the desktop/laptop space, to run their fastest, they need to
boost their power supplies at the cost of increase power consumption but
fast speeds become available.

Then there is the fact that the 'simple' idle modes don't stop
everything, so you are still burning the higher frequency power even
when idle in parts of the circuit, and switching to more power savings
mode can take a bit of time and actually cost power (as you power down
then back up sections of the die) means that slower, higher usage, uses
less power.

The problem is that this also limits you PEAK operational speed, so you
need to balence those needs with your power concumption.

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.

On 23/11/2021 19:50, Richard Damon wrote:
> On 11/23/21 1:24 PM, David Brown wrote:
>> On 23/11/2021 18:00, DozingDog@thekennel.co wrote:
>>> On Tue, 23 Nov 2021 17:51:09 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> 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.
>>>
>>> Why do many battery powered systems throttle the CPU to save the
>>> battery when
>>> its getting low then and why does undertaking CPU intensive tasks
>>> deplete the
>>> battery faster? You seem to be claiming that you can get something
>>> for nothing.
>>>
>>
>> If you have to do a certain calculation or set of calculations, it is
>> /usually/ more efficient to do them quickly and then let the processor
>> sleep deeper and longer.
>>
>> Modern cpus generally do /not/ throttle the cpu speed to save battery
>> power.  It only makes sense to slow down the processor if you have large
>> leakage currents that you can't turn off, in which case a slow clock can
>> mean lower energy overall.  With modern devices, clock gating lets you
>> turn off all or parts of the core much more effectively.
>>
>
> Not sure if this holds for desktop/laptop caliber processors, but in the
> embedded world, many processors can have their core voltage dropped down
> when running at slower speeds, and since switching energy is
> proportional to V^2, slowing the processor and waiting less CAN save power.

That depends on the class of embedded system. If you are talking about
large embedded processors - running embedded Linux, for instance - then
that's true. But even there you usually aim for high speed and lots of
sleep if you can. However, as I mentioned, entering and exiting sleep
modes takes some time - if you are doing it too frequently, that
overhead becomes dominant and it is better to run the whole thing at a
low clock rate.

Smaller embedded systems rarely change the voltage to the core.

>
> I beleive this applies to processors with a 'Turbo' or 'Overclocked'
> mode in the desktop/laptop space, to run their fastest, they need to
> boost their power supplies at the cost of increase power consumption but
> fast speeds become available.
>
> Then there is the fact that the 'simple' idle modes don't stop
> everything, so you are still burning the higher frequency power even
> when idle in parts of the circuit, and switching to more power savings
> mode can take a bit of time and actually cost power (as you power down
> then back up sections of the die) means that slower, higher usage, uses
> less power.
>
> The problem is that this also limits you PEAK operational speed, so you
> need to balence those needs with your power concumption.

It is all a complicated balance, and a subject of continuous development
and improvement - no one choice fits everything. (And the ideal power
management decisions need to know what a process is going to do before
it does it.)

On 11/23/2021 4:50 PM, 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.
>

Well, CPU speed is not a property of the language...