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

Groups > comp.lang.c > #163577 > 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 Thiago Adams <thiago.adams@gmail.com> - 2021-11-23 04:50 -0800
        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 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 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 Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-23 16:31 -0800
                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 Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-23 16:25 -0800
          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 Thiago Adams <thiago.adams@gmail.com> - 2021-11-26 03:37 -0800
    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 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" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-13 17:59 -0800
                    Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-14 03:18 +0000
                      Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-16 10:57 -0800
                        Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 22:03 +0000
                          Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-20 02:40 -0800
                            Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-20 12:05 +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 Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-06 01:52 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-06 12:19 -0800
            Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-06 12:27 -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 →

#163785

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]

#163667

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]

#163625

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]

#163647

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]

#163648

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]

#163618

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]

#163601

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]

#163642

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]

#163655

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]

#163656

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]

#163659

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]

#163658

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]

#163661

Let's do this again:

When normalizing to the energy use and execution time of C (i.e. C is
1.0 for both energy use and execution time):

Go code takes 3.23 energy, and 2.83 execution time.

Lisp code takes 2.27 energy, and 3.40 execution time.

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

#163662

On 24/11/2021 20:17, Philipp Klaus Krause wrote:
> Let's do this again:
> 
> When normalizing to the energy use and execution time of C (i.e. C is
> 1.0 for both energy use and execution time):
> 
> Go code takes 3.23 energy, and 2.83 execution time.
> 
> Lisp code takes 2.27 energy, and 3.40 execution time.
> 

Do you have direct links/locations to those figures?

The OP's PDF link seems to be making using the Shootout benchmarks, 
which I don't rate that highly.

There can be half a dozen different versions even in the same language, 
using different algorithms.

The actual tasks are dubious too; a benchmark based around one 
bottleneck is a long way from real code.

(Also, how did Lisp manage to be only 3 times as slow as C? It was both 
interpreted /and/ dynamically typed last I looked.)

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

#163665

Am 24.11.21 um 21:42 schrieb Bart:
> On 24/11/2021 20:17, Philipp Klaus Krause wrote:
>> Let's do this again:
>>
>> When normalizing to the energy use and execution time of C (i.e. C is
>> 1.0 for both energy use and execution time):
>>
>> Go code takes 3.23 energy, and 2.83 execution time.
>>
>> Lisp code takes 2.27 energy, and 3.40 execution time.
>>
> 
> Do you have direct links/locations to those figures?

Table 4 in the paper at the link the OP gave
(https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf).

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

#163784

In comp.lang.c Bart <bc@freeuk.com> wrote:
> 
> (Also, how did Lisp manage to be only 3 times as slow as C? It was both 
> interpreted /and/ dynamically typed last I looked.)

Lisp may be compiled to machine code and when speed is important
you will choose implementation with good compiler.  Concerning
"dynamically typed": Lisp has type declarations which are
optional.  Without declarations your types can be anything so
you get true dynamic typing.  With declarations you can declare
that your variable contains machine integers or doubles and
good Lisp compiler will generate directly machine code.

It is debatable how much C features contribute to speed of
resulting machine code.  In Lisp each data structure has
identifying header and you get efficient code only for arrays
of "primitive types", there is no way in Lisp to get something
with memory layout of C array of structs.  So in principle
in C you may have more compact data structures that keep
related items together, which leads to better cache use
and consequently less time spent on memory accesses.
When it comes to computations, it is mostly matter of
effort spent on compiler.  There was enormous effort spent
on C compilers and compilers like gcc are hard to beat.
Still, it depends on specific code: for simple code with
memory accesses that hit cache using Lisp I usually get about
half of speed of gcc-compiled C.  More tricky cases may be
somewhat slower.  For example I noted that Lisp compiler that
I use will use multiplication when sequentlially accessing
row of two dimensional array in a loop.  This lead to machine
code that is 4-5 times slower than code generated by gcc.
When code is memory-intensive (say pointer chaising) speed
is essentially indepenent of language (of course assuming
that language can express reasonanably efficient pattern
of memory accesses).

Looking at generated machine code I would expect that Lisp
will give me better or equal runtime speed compared to
your C compiler.

As little anecdote, I wrote code compiled via Lisp compiler
that was intended to be speed competivive with code in
interpreted language calling to optimized C libraries to
do main work.  AFAIK my code was faster, mainly because
I was able to create combined operation which saved essentally
half work compared to separate library calls.  That was
enough to compensate better code generator from C compiler.
Of course, coding my routine in C I would have both gain
form combined operation and gain from better compiler
optimization.  OTOH affected routines were about 60 lines
of code, while the whole thing was about 6000 lines.
Writing all in C would take _much_ more effort and the
result would be less useful as my routines were integrated
into existing program (which would be harder to do with
C code).

-- 
                              Waldek Hebisch

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

#163791

On 11/12/2021 14:07, antispam@math.uni.wroc.pl wrote:
> In comp.lang.c Bart <bc@freeuk.com> wrote:
>>
>> (Also, how did Lisp manage to be only 3 times as slow as C? It was both
>> interpreted /and/ dynamically typed last I looked.)
> 
> Lisp may be compiled to machine code and when speed is important
> you will choose implementation with good compiler.  Concerning
> "dynamically typed": Lisp has type declarations which are
> optional.  Without declarations your types can be anything so
> you get true dynamic typing.  With declarations you can declare
> that your variable contains machine integers or doubles and
> good Lisp compiler will generate directly machine code.
> 
> It is debatable how much C features contribute to speed of
> resulting machine code.  In Lisp each data structure has
> identifying header and you get efficient code only for arrays
> of "primitive types", there is no way in Lisp to get something
> with memory layout of C array of structs.  So in principle
> in C you may have more compact data structures that keep
> related items together, which leads to better cache use
> and consequently less time spent on memory accesses.
> When it comes to computations, it is mostly matter of
> effort spent on compiler.  There was enormous effort spent
> on C compilers and compilers like gcc are hard to beat.
> Still, it depends on specific code: for simple code with
> memory accesses that hit cache using Lisp I usually get about
> half of speed of gcc-compiled C.  More tricky cases may be
> somewhat slower.  For example I noted that Lisp compiler that
> I use will use multiplication when sequentlially accessing
> row of two dimensional array in a loop.  This lead to machine
> code that is 4-5 times slower than code generated by gcc.
> When code is memory-intensive (say pointer chaising) speed
> is essentially indepenent of language (of course assuming
> that language can express reasonanably efficient pattern
> of memory accesses).
> 
> Looking at generated machine code I would expect that Lisp
> will give me better or equal runtime speed compared to
> your C compiler.

To me the most apt description of Lisp seems to be 'shape-shifting'.

The language is dynamically typed when it suits, but can switch to 
static typed when someone complains of the speed (but it needs someone 
to revise the program).

It also can be run-from-source, or it can compile to some interpreted 
internal form, or to native code (or, I guess, use some sort of JIT).

It also seems to be capable of anything; don't like how it does 
assignment; there several other ways it can pull out of the hat. That 
loop not powerful enough, there are half a dozen other forms with any 
number of parameters.

You just can't pin it down. And therefore it seems immune to any 
criticism; there is always a way to change it.

> As little anecdote, I wrote code compiled via Lisp compiler
> that was intended to be speed competivive with code in
> interpreted language calling to optimized C libraries to
> do main work.  AFAIK my code was faster, mainly because
> I was able to create combined operation which saved essentally
> half work compared to separate library calls.  That was
> enough to compensate better code generator from C compiler.
> Of course, coding my routine in C I would have both gain
> form combined operation and gain from better compiler
> optimization.  OTOH affected routines were about 60 lines
> of code, while the whole thing was about 6000 lines.
> Writing all in C would take _much_ more effort and the
> result would be less useful as my routines were integrated
> into existing program (which would be harder to do with
> C code).

I always reckoned that the right balance of dynamic code plus static 
code, should not be more than 1-2 times as slow as 100% static (save for 
programs with short runtimes)

And, sometimes, as you found, it can be a bit faster!

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

#163793 — [OT] Lisp. Was: "C Is The Greenest Programming Language" by: Chris Lott

Bart <bc@freeuk.com> writes:

> To me the most apt description of Lisp seems to be 'shape-shifting'.
>
> The language is dynamically typed when it suits, but can switch to
> static typed when someone complains of the speed (but it needs someone
> to revise the program).

Handy that.  Rapid prototyping and robust production code.  It's the
same language though, you just use more if it as and when needed.

> It also can be run-from-source, or it can compile to some interpreted
> internal form, or to native code (or, I guess, use some sort of JIT).

Yes, there are a wide variety of implementations to suit different
needs.

> It also seems to be capable of anything;

It is.  That is obviously literally correct (Turing completeness and all
that) but modern Common Lisp is extraordinarily capable.

> don't like how it does assignment; there several other ways it can
> pull out of the hat. That loop not powerful enough, there are half a
> dozen other forms with any number of parameters.

There /is/ a lot to learn.  That's the perennial language design
dilemma.  You can have small and a bit rigid, or large and very
flexible.

> You just can't pin it down. And therefore it seems immune to any
> criticism; there is always a way to change it.

Actually it is pretty well pinned down.  There is a stable standard for
Common Lisp which is widely implemented and does not change half as much
as, say, the C standard.

-- 
Ben.

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

#163830 — Re: "C Is The Greenest Programming Language"

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

Assuming by "Green", he means which programming language allows a programmer
to "accomplish the most goals" with the least amount of cycles (energy use)...

I'd first say It's not going to be "cut and dried" because "schlock" can be
written in pretty much any language... so for any sort of valid comparison
you'd have to be using very (and equally) competent programmers, equally
skilled in the languages being used :-)

That being said, I'd first think of "Assembly language" as having the highest
possibility of achieving such a goal because it gives you instruction level
control of exactly what gets done, and makes if at least "possible" to make an
optimal solution to a given goal.

This would have to be tempered by the fact that the number truly competent
assembly programmers is more limited (I'd say that over the years I've seen
more "schlock" written in assembly then most others). Add to this portability
(and other) issues which make it not truly suitable for many goals, and I have
to admit: It's probably not a good one to consider.

IMHO, C comes pretty close, because it allows one to do much of the lower
level "stuff" you might not be able to efficiently accomplish on other higher
level languages, and in a good implementation these kinds of operations can
product code not all that much different from what a good assembly programmers
would have done...

And it "solves" or at least improves many of the main issues that can crop
up in assembly:

- Portability, C code can be generic enough that it needs little to no changes
 when moving to another system. And C is (IMHO) one of the most common higher
 level languages available on different systems (and has been for some time).

- It makes it "easy" to control the use of memory. Just "declare" things and
 the compiler will take care of allocating space for them in applicable areas
 of memory. No worrying about "what would best go here...".

 It also handles stack frames and automatic allocation/free of local "things"
 when entering/exiting a "function" (applicable to below)

- It makes it much easier to break up your program into logical blocks or
 subroutines. Sure: Assembly almost always has the ability to CALL/JSR
 (I've worked on some minimal CPUs which don't!) but you have to worry
 about passing information to and getting information from such blocks,
 and how to make memory available to them "as they run" (if you need to),
 but C does all of this in some very straight forward/efficient ways (at
 least most systems do :-)

- Commonly used more complex operations can be maintained in a (hopefully
 very efficient) "library" and made available "as you need them" without
 having to do such things "again and again".

There are of course some potential downsides:

- You don't control the code being generated at the instruction level (but
 with some Cs you come pretty close). Hopefully the designers of the compiler
 did a good job, but you may see some non-optimal output from time to time.

- "Libraries" although mentioned above can be a "good thing", but in my
 experience they can also be "not so good". Supplied libraries are made such
 that they will appeal to many programmers, and may therefore not do exactly
 what (and only what) you would like. There is often a sometimes large amount
 of "extra stuff" brought in because it's used somewhere in the library code.
 And being so readily available, there's a lot of temptation to "just use" them.

In most cases these aren't much of a problem, but when you are looking at
"fastest and smallest" it can surprise you. In "modern times" of multi Ghz
processing and multi Gb memory systems, it's really not an issue many
programmers even think about.

I could go on ... but I hope I've made at least a bit of a point.

All of this is or course my own "opinion" and comes from many years working
on very small/slowish and often quite memory limited targets. A lot of this
was done in assembly language at first because I didn't find a higher level
language that came "close enough". As time progressed I did switch a lot of
my development to C because in many cases it did (come close enough). I still
use dribbles of assembly "as needed" (the main reason my compiler has fairly
capable "inline assembly" capabilities! :-)

Regards,
Dave

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

#163831 — Re: "C Is The Greenest Programming Language"

Dave Dunfield <dave.dunfield@gmail.com> writes:

>>"C Is The Greenest Programming Language" by: Chris Lott
>
> Assuming by "Green", he means which programming language allows a programmer
> to "accomplish the most goals" with the least amount of cycles (energy
> use)...

Why are you replying to me?  Why do you include a quoted line that was
not in the post you are replying to?  Maybe something is wrong with your
news client.

-- 
Ben.

[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