Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82395 > unrolled thread

"C Is The Greenest Programming Language" by: Chris Lott

Back to article view | Back to comp.lang.c++

Contents

  "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-22 16:19 -0600
    Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-22 14:58 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-23 07:10 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-23 13:12 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-24 10:54 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 12:01 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-24 13:58 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-23 13:23 -0800
    Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-22 18:25 -0500
      Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-23 07:21 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Guillaume <message@bottle.org> - 2021-11-23 17:56 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-24 10:55 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Öö Tiib <ootiib@hot.ee> - 2021-11-24 05:54 -0800
        Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-23 19:00 -0600
          Re: "C Is The Greenest Programming Language" by: Chris Lott scott@slp53.sl.home (Scott Lurndal) - 2021-11-24 16:04 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 07:55 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott legalize+jeeves@mail.xmission.com (Richard) - 2021-12-16 16:24 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-16 19:46 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-12-17 06:30 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Tim Rentsch <tr.17687@z991.linuxsc.com> - 2021-12-18 07:45 -0800
              Re: "C Is The Greenest Programming Language" by: Chris Lott legalize+jeeves@mail.xmission.com (Richard) - 2021-12-30 12:01 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-16 12:22 -0800
                  Re: "C Is The Greenest Programming Language" by: Chris Lott legalize+jeeves@mail.xmission.com (Richard) - 2022-01-17 21:28 +0000
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-01-17 15:48 -0800
                      Re: "C Is The Greenest Programming Language" by: Chris Lott legalize+jeeves@mail.xmission.com (Richard) - 2022-01-18 06:47 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:43 +0100
    Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-23 14:17 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 16:53 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-24 11:40 +0200
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-24 15:49 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-23 19:01 -0600
        Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-24 11:33 +0200
          Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-24 15:28 -0600
    Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 14:39 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 16:55 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 12:28 -0500
          Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 19:05 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 13:41 -0500
              Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 19:53 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 21:27 -0500
                  Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-24 18:32 +0100
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 12:54 -0500
                      Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-24 20:52 +0100
                        Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 15:13 -0500
                          Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-25 19:13 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-24 15:48 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 11:54 -0500
              Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 11:19 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-25 11:46 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 15:57 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-25 07:04 -0500
                  Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 15:59 +0000
    Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 16:03 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott gazelle@shell.xmission.com (Kenny McCormack) - 2021-11-23 15:50 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 17:51 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 17:00 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 12:36 -0500
            Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 19:24 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 13:50 -0500
                Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 20:02 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 20:59 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 20:50 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Ian Collins <ian-news@hotmail.com> - 2021-11-24 11:18 +1300
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 22:58 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 23:46 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 13:59 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott antispam@math.uni.wroc.pl - 2021-12-11 13:25 +0000
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-12-11 14:54 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-25 12:12 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 23:35 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-24 15:30 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 14:43 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 20:29 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 16:14 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:56 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Öö Tiib <ootiib@hot.ee> - 2021-11-24 06:03 -0800
        Re: "C Is The Greenest Programming Language" by: Chris Lott Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-24 10:14 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-24 19:55 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:13 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:11 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:17 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 20:42 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 23:25 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott antispam@math.uni.wroc.pl - 2021-12-11 14:07 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-12-11 18:46 +0000
                [OT] Lisp.  Was: "C Is The Greenest Programming Language" by: Chris Lott Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-11 20:11 +0000
    Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-24 14:12 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-25 12:00 +0100
    Re: "C Is The Greenest Programming Language" by: Chris Lott Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-05 22:51 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-05 19:20 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-12-06 12:28 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-06 13:40 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 16:21 +0100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#82423

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.

[toc] | [prev] | [next] | [standalone]

#82424

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

[toc] | [prev] | [next] | [standalone]

#82427

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.

[toc] | [prev] | [next] | [standalone]

#82430

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.

[toc] | [prev] | [next] | [standalone]

#82429

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.

[toc] | [prev] | [next] | [standalone]

#82447

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

[toc] | [prev] | [next] | [standalone]

#82595

In comp.lang.c Bart <bc@freeuk.com> wrote:
> Consider that on my machine, even an empty program takes 0.02 seconds to 
> run...

Get a better system if you care about such runtimes.  _Statically_
compiled program on Linux needs less than 300 uS to run (of course
this assumes file caching works as intended, if you have spinning
disk first access still needs seek time).
 
-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#82597

On 11/12/2021 13:25, antispam@math.uni.wroc.pl wrote:
> In comp.lang.c Bart <bc@freeuk.com> wrote:
>> Consider that on my machine, even an empty program takes 0.02 seconds to
>> run...
> 
> Get a better system if you care about such runtimes.  _Statically_
> compiled program on Linux needs less than 300 uS to run (of course
> this assumes file caching works as intended, if you have spinning
> disk first access still needs seek time).

You wouldn't normally care about 20ms overhead to start and terminate a 
process, but when a program takes 60ms anyway for example, then it can 
be significant if you want to know or compare actual performance.

Actually that 20ms isn't accurate. Measuring a block of 100 empty 
programs (in both cases from a BAT or Bash script, both with SSD), takes 
7ms per invocation on Windows, and 3ms [real time] on WSL.

3ms is 3000 us; not far off your 300 us figure, considering your machine 
is likely faster and running true Linux.

Allowing for that 7ms on Windows, then 'tcc hello.c' takes 0.11ms; bcc 
takes 18ms, and gcc takes 280ms.

[toc] | [prev] | [next] | [standalone]

#82478

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

Not really, this study does show a significant difference between 
language choices for the same task.

> 
> How about writing efficient applications?
Yes, and that includes choosing the right language.

  And efficient OSes (there
> might be 1000 processes on my PC right now).
That's a different matter than applications. It still affects overall 
energy consumption of course. The choice of the language still matters 
for OS processes, but general OS design has a major impact as well.
My critics is addressed to components that are shipped with many OS's, 
yet are not technically part of the core OS infrastructure. Think e.g. 
the Windows Update infrastructure - it's probably one of the most 
bloated features I've ever seen.

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

As others have pointed out, this does not matter, since compilers are 
not part of a typical runtime environment.

> 
> (For a couple of years one of my compilers was run as interpreted, 
> dynamic bytecode. It was still double the speed of gcc!)

[toc] | [prev] | [next] | [standalone]

#82428

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.

[toc] | [prev] | [next] | [standalone]

#82449

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

[toc] | [prev] | [next] | [standalone]

#82450

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.

[toc] | [prev] | [next] | [standalone]

#82422

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

[toc] | [prev] | [next] | [standalone]

#82407

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.

[toc] | [prev] | [next] | [standalone]

#82443

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

[toc] | [prev] | [next] | [standalone]

#82448

On Wednesday, 24 November 2021 at 12:56:28 UTC+2, Philipp Klaus Krause wrote:
> 
> 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).

That is probably because of different concurrency support. Dozen years old 
language (like Go) is anticipated to be better designed to support concurrency
than 5 dozens years old language (like Lisp).

[toc] | [prev] | [next] | [standalone]

#82458

Philipp Klaus Krause <pkk@spth.de> writes:
> 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).

What does "183% slower" mean?  I presume it doesn't run backwards at 83%
of C's speed.

For that matter, does "323% more energy consumed" mean 3.23 times as
much energy or 4.23 times as much energy?  (Consider that "10%" more
means "1.1 times as much.)

> Lisp is slow (240% slower than C) but energy efficient (127% more energy
> consumed than C).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#82459

On 24/11/2021 19:14, Keith Thompson wrote:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> 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).
> 
> What does "183% slower" mean?  I presume it doesn't run backwards at 83%
> of C's speed.
> 

I would guess it means it takes 1.83 times as long to handle the same
basic task.  I can't really see any logical alternative explanation.
But "183% slower" is not exactly a good way to express that!

> For that matter, does "323% more energy consumed" mean 3.23 times as
> much energy or 4.23 times as much energy?  (Consider that "10%" more
> means "1.1 times as much.)
> 

I would guess 3.32 times as much energy, based on similarity to my
interpretation of "183% slower".  Again, I agree that it's a poor way to
express it.

>> Lisp is slow (240% slower than C) but energy efficient (127% more energy
>> consumed than C).
> 

[toc] | [prev] | [next] | [standalone]

#82462

Am 24.11.21 um 19:55 schrieb David Brown:
> Again, I agree that it's a poor way to
> express it.

Yes. I should have written that differently.

[toc] | [prev] | [next] | [standalone]

#82461

Am 24.11.21 um 19:14 schrieb Keith Thompson:
> Philipp Klaus Krause <pkk@spth.de> writes:
>> 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).
> 
> What does "183% slower" mean?  I presume it doesn't run backwards at 83%
> of C's speed.

By "183% slower", I meant "takes 183% more time to execute", i.e. 2.83
times the execution time.

> 
> For that matter, does "323% more energy consumed" mean 3.23 times as
> much energy or 4.23 times as much energy?  (Consider that "10%" more
> means "1.1 times as much.)

That was a mistake, that should have been "223% more energy consumed",
i.e. 3.23 times the energy of the C program.

Philipp

[toc] | [prev] | [next] | [standalone]

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

Back to top | Article view | comp.lang.c++

csiph-web