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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#82689

[Please do not mail me a copy of your followup]

Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code
<86v8zl29yr.fsf@linuxsc.com> thusly:

>There was no operating system in the conventional sense of the
>term.  Garbage collection was part of the VM underlying the
>OOP environment.  Multitasking was done in and by the OOP
>environment itself, with "stack frames" being objects, and so
>could be queued for later resumption, switched between, etc.

Smalltalk and LISP Machine environments are really quite different
from what we assume computers are like today.  For small resource
machines, FORTH probably comes close, although AFAIK it never had a
stock GUI, like the Smalltalk and LISPM environments typically did.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

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

#82786

legalize+jeeves@mail.xmission.com (Richard) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code
> <86v8zl29yr.fsf@linuxsc.com> thusly:
>
>> There was no operating system in the conventional sense of the
>> term.  Garbage collection was part of the VM underlying the
>> OOP environment.  Multitasking was done in and by the OOP
>> environment itself, with "stack frames" being objects, and so
>> could be queued for later resumption, switched between, etc.
>
> Smalltalk and LISP Machine environments are really quite different
> from what we assume computers are like today.  [...]

Lisp machines are special purpose hardware.  Smalltalk VMs
run on standard hardware, much like Java bytecode interpreters
do today.  Also the memory mangement code runs inside the VM,
so it is very much line standard code running on conventional
hardware of today (after taking into account the more limited
memory space and 16-bit registers, etc).  The key point is
that the system as a whole is very careful with how it uses
memory, unlike the earlier claim about OOP environments using
memory with wild abandon.

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

#82807

[Please do not mail me a copy of your followup]

Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code
<86lezftoq5.fsf@linuxsc.com> thusly:

>legalize+jeeves@mail.xmission.com (Richard) writes:
>
>> Smalltalk and LISP Machine environments are really quite different
>> from what we assume computers are like today.  [...]
>
>Lisp machines are special purpose hardware.  Smalltalk VMs
>run on standard hardware, much like Java bytecode interpreters
>do today.

I was thinking of the Smalltalk workstations from the 80s like those
made by Tektronix.  I don't think they used a VM, but ran on the bare
metal.
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

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

#82810

legalize+jeeves@mail.xmission.com (Richard) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code
> <86lezftoq5.fsf@linuxsc.com> thusly:
>
>> legalize+jeeves@mail.xmission.com (Richard) writes:
>>
>>> Smalltalk and LISP Machine environments are really quite different
>>> from what we assume computers are like today.  [...]
>>
>> Lisp machines are special purpose hardware.  Smalltalk VMs
>> run on standard hardware, much like Java bytecode interpreters
>> do today.
>
> I was thinking of the Smalltalk workstations from the 80s like those
> made by Tektronix.  I don't think they used a VM, but ran on the bare
> metal.

As I recall Tektronix was one of four companies licensed by Xerox
to port a Smalltalk-80 VM to other systems.  One motivation for
offering these licenses was to help debug the writing in
"Smalltalk-80: The language and its implementation", where most
of the implementation part was about how the VM works and how to
write one.  Given that, it would be strange if the Tektronix
effort did not use a VM but instead ran a standard Smalltalk
image on bare hardware.

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

#82816

[Please do not mail me a copy of your followup]

Tim Rentsch <tr.17687@z991.linuxsc.com> spake the secret code
<861r15sz3r.fsf@linuxsc.com> thusly:

>As I recall Tektronix was one of four companies licensed by Xerox
>to port a Smalltalk-80 VM to other systems.  One motivation for
>offering these licenses was to help debug the writing in
>"Smalltalk-80: The language and its implementation", where most
>of the implementation part was about how the VM works and how to
>write one.  Given that, it would be strange if the Tektronix
>effort did not use a VM but instead ran a standard Smalltalk
>image on bare hardware.

Interesting!  I didn't know that!  I found a PDF of the book on
archive.org, so I'm going to take a look at that!  (If others are
interested: <https://archive.org/details/smalltalk80langu00gold>)
-- 
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
            The Terminals Wiki <http://terminals-wiki.org>
     The Computer Graphics Museum <http://computergraphicsmuseum.org>
  Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

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

#82440

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

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

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

Go is fast (only 183% slower than C), but energy inefficient (323% more
energy consumed than C).

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

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

#82400

Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> "C Is The Greenest Programming Language" by: Chris Lott
>    https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/

Perhaps one contributing factor is that not so much development is any
longer done using C or C++, and the programs that are run (and still
being developed) were originally created in the era when CPU power was
much lower than these days, so code optimization was more important.
-- 
   /* * * Otto J. Makela <om@iki.fi> * * * * * * * * * */
  /* Phone: +358 40 765 5772, ICBM: N 60 10' E 24 55' */
 /* Mail: Mechelininkatu 26 B 27,  FI-00100 Helsinki */
/* * * Computers Rule 01001111 01001011 * * * * * * */

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

#82409

On Tue, 23 Nov 2021 14:17:50 +0200
om@iki.fi (Otto J. Makela) wrote:
>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>
>> "C Is The Greenest Programming Language" by: Chris Lott
>>    https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>
>Perhaps one contributing factor is that not so much development is any
>longer done using C or C++, and the programs that are run (and still
>being developed) were originally created in the era when CPU power was
>much lower than these days, so code optimization was more important.

Its good to see the attitude of just throw more CPU at something instead of
optimising it is still around. These days when server farms are taking up 
a siginificant percentage of the planet's electrical output its beholder on
programmers to make their code as efficient as is reasonable.

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

#82439

DozingDog@thekennel.co wrote:

> On Tue, 23 Nov 2021 14:17:50 +0200
> om@iki.fi (Otto J. Makela) wrote:
>>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>
>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>    https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>
>>Perhaps one contributing factor is that not so much development is any
>>longer done using C or C++, and the programs that are run (and still
>>being developed) were originally created in the era when CPU power was
>>much lower than these days, so code optimization was more important.
>
> Its good to see the attitude of just throw more CPU at something
> instead of optimising it is still around. These days when server
> farms are taking up a siginificant percentage of the planet's
> electrical output its beholder on programmers to make their code
> as efficient as is reasonable.

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

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

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

#82452

On Wed, 24 Nov 2021 11:40:54 +0200
om@iki.fi (Otto J. Makela) wrote:
>DozingDog@thekennel.co wrote:
>
>> On Tue, 23 Nov 2021 14:17:50 +0200
>> om@iki.fi (Otto J. Makela) wrote:
>>>Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>
>>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>>    https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>>
>>>Perhaps one contributing factor is that not so much development is any
>>>longer done using C or C++, and the programs that are run (and still
>>>being developed) were originally created in the era when CPU power was
>>>much lower than these days, so code optimization was more important.
>>
>> Its good to see the attitude of just throw more CPU at something
>> instead of optimising it is still around. These days when server
>> farms are taking up a siginificant percentage of the planet's
>> electrical output its beholder on programmers to make their code
>> as efficient as is reasonable.
>
>I keep rereading that first sentence, is the meaning reversed?

No. 

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

#82432

On 11/23/2021 6:17 AM, Otto J. Makela wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> "C Is The Greenest Programming Language" by: Chris Lott
>>     https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
> 
> Perhaps one contributing factor is that not so much development is any
> longer done using C or C++, and the programs that are run (and still
> being developed) were originally created in the era when CPU power was
> much lower than these days, so code optimization was more important.

I write C++ and Fortran code just about every day for our software products.

Lynn

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

#82438

Lynn McGuire <lynnmcguire5@gmail.com> wrote:

> On 11/23/2021 6:17 AM, Otto J. Makela wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>     https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>> Perhaps one contributing factor is that not so much development
>> is any longer done using C or C++, and the programs that are run
>> (and still being developed) were originally created in the era
>> when CPU power was much lower than these days, so code
>> optimization was more important.
>
> I write C++ and Fortran code just about every day for our software
> products.

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

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

#82467

On 11/24/2021 3:33 AM, Otto J. Makela wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
> 
>> On 11/23/2021 6:17 AM, Otto J. Makela wrote:
>>> Lynn McGuire <lynnmcguire5@gmail.com> wrote:
>>>> "C Is The Greenest Programming Language" by: Chris Lott
>>>>      https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
>>> Perhaps one contributing factor is that not so much development
>>> is any longer done using C or C++, and the programs that are run
>>> (and still being developed) were originally created in the era
>>> when CPU power was much lower than these days, so code
>>> optimization was more important.
>>
>> I write C++ and Fortran code just about every day for our software
>> products.
> 
> Do you consider this to be a common situation?

I really have no idea.

Lynn

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

#82401

Am 22.11.2021 um 23:19 schrieb Lynn McGuire:
> "C Is The Greenest Programming Language" by: Chris Lott
>     https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/
> 
> "Have you ever wondered if there is a correlation between a computer’s 
> energy consumption and the choice of programming languages? Well, a 
> group Portuguese university researchers did and set out to quantify it. 
> Their 2017 research paper entitled Energy Efficiency across Programming 
> Languages / How Do Energy, Time, and Memory Relate?  may have escaped 
> your attention, as it did ours."
>     https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf
> 
> "Abstract: This paper presents a study of the runtime, memory usage and 
> energy consumption of twenty seven well-known soft- ware languages. We 
> monitor the performance of such lan- guages using ten different 
> programming problems, expressed in each of the languages. Our results 
> show interesting find- ings, such as, slower/faster languages consuming 
> less/more energy, and how memory usage influences energy consump- tion. 
> We show how to use our results to provide software engineers support to 
> decide which language to use when energy efficiency is a concern."

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

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

#82410

On Tue, 23 Nov 2021 14:39:08 +0100
Bonita Montero <Bonita.Montero@gmail.com> wrote:
>Developing in C is a magnitude more effort than in C++, and if you've

That depends on the problem. If you're writing code that needs to store a
lot of structured data then C wouldn't be your first choice of language. But
if you're writing something that simply interfaces with system calls then 
there's probably not much if any extra effort in using C over C++.

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

#82413

On 11/23/21 11:55 AM, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 14:39:08 +0100
> Bonita Montero <Bonita.Montero@gmail.com> wrote:
>> Developing in C is a magnitude more effort than in C++, and if you've
> 
> That depends on the problem. If you're writing code that needs to store a
> lot of structured data then C wouldn't be your first choice of language. But
> if you're writing something that simply interfaces with system calls then
> there's probably not much if any extra effort in using C over C++.
> 

I would disagree. With a decent compiler, C code can generate close to 
assembly level optimizations for most problems. (Maybe it doesn't have 
good support for defining Multiple Datapath Single Instruction 
sequences, but a GOOD compiler maybe be able to detect and generate this).

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

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

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

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

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

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

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

#82415

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

With a lot of effort compared to C++.

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

Why shoul one use sth. different than std::vector<>, std::string,
std::unordered_map<> ... ? There are no opportunities to make the
same more efficient.

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

#82417

On 11/23/21 1:05 PM, Bonita Montero wrote:
>> ANYTHING in terms of data-structures that another language can 
>> generate, you can generate in C.
> 
> With a lot of effort compared to C++.
> 
>> The big disadvantage is that YOU as the programmer need to deal with a 
>> lot of the issues rather than to compiler doing things for you, but 
>> that is exactly why you can do things possibly more efficiently then 
>> the compiler. You could have always generated the same algorithm that 
>> the compiler did.
> 
> Why shoul one use sth. different than std::vector<>, std::string,
> std::unordered_map<> ... ? There are no opportunities to make the
> same more efficient.
> 

Except where there are.

For instance, I regularly use a variant of std:string that the char 
const* constructor checks if the input is from 'read only' memory, and 
if it is reuses that data instead of making a copy, at least until in 
wants to change it. This saves me a LOT of memory in embedded systems 
where most of my 'string' data is constant, but some spedific cases need 
to dynamically compute the string.

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

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

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

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

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

#82419

Am 23.11.2021 um 19:41 schrieb Richard Damon:

> For instance, I regularly use a variant of std:string that the char 
> const* constructor checks if the input is from 'read only' memory, and 
> if it is reuses that data instead of making a copy, at least until in 
> wants to change it. ...

Then use string_view.

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

#82435

On 11/23/21 1:53 PM, Bonita Montero wrote:
> Am 23.11.2021 um 19:41 schrieb Richard Damon:
> 
>> For instance, I regularly use a variant of std:string that the char 
>> const* constructor checks if the input is from 'read only' memory, and 
>> if it is reuses that data instead of making a copy, at least until in 
>> wants to change it. ...
> 
> Then use string_view.
> 

Doesn't work.

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

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

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

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

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

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

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

csiph-web