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

    From Lynn McGuire@21:1/5 to All on Mon Nov 22 16:19:27 2021
    XPost: comp.lang.c

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

    "Have you ever wondered if there is a correlation between a computer’s
    energy consumption and the choice of programming languages? Well, a
    group Portuguese university researchers did and set out to quantify it.
    Their 2017 research paper entitled Energy Efficiency across Programming Languages / How Do Energy, Time, and Memory Relate? may have escaped
    your attention, as it did ours."
    https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

    "Abstract: This paper presents a study of the runtime, memory usage and
    energy consumption of twenty seven well-known soft- ware languages. We
    monitor the performance of such lan- guages using ten different
    programming problems, expressed in each of the languages. Our results
    show interesting find- ings, such as, slower/faster languages consuming less/more energy, and how memory usage influences energy consump- tion.
    We show how to use our results to provide software engineers support to
    decide which language to use when energy efficiency is a concern."

    Lynn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to chris.m.thomasson.1@gmail.com on Tue Nov 23 07:10:07 2021
    XPost: comp.lang.c

    In comp.lang.c++ Chris M. Thomasson <chris.m.thomasson.1@gmail.com> wrote:
    Interesting. However, I can write something in C that uses all CPU's
    100%.

    I don't think that's the point.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Otto J. Makela@21:1/5 to Lynn McGuire on Tue Nov 23 14:17:50 2021
    XPost: comp.lang.c

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From DozingDog@thekennel.co@21:1/5 to Bonita Montero on Tue Nov 23 16:55:29 2021
    XPost: comp.lang.c

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Guillaume@21:1/5 to All on Tue Nov 23 17:56:56 2021
    XPost: comp.lang.c

    Le 23/11/2021 à 08:21, Juha Nieminen a écrit :
    Oh well. As long as it works, who cares? Buy a faster computer.

    This sentence shows that you quite obviously got what "green" means.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Tue Nov 23 19:53:04 2021
    XPost: comp.lang.c

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to message@bottle.org on Wed Nov 24 10:55:01 2021
    XPost: comp.lang.c

    In comp.lang.c++ Guillaume <message@bottle.org> wrote:
    Le 23/11/2021 08:21, Juha Nieminen a crit:
    Oh well. As long as it works, who cares? Buy a faster computer.

    This sentence shows that you quite obviously got what "green" means.

    I have no idea what you are talking about.

    Maybe you missed the fact that that sentence you quoted is sarcastic?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?w5bDtiBUaWli?=@21:1/5 to Juha Nieminen on Wed Nov 24 05:54:29 2021
    On Wednesday, 24 November 2021 at 12:55:19 UTC+2, Juha Nieminen wrote:
    In comp.lang.c++ Guillaume <mes...@bottle.org> wrote:
    Le 23/11/2021 à 08:21, Juha Nieminen a écrit :
    Oh well. As long as it works, who cares? Buy a faster computer.

    This sentence shows that you quite obviously got what "green" means.

    I have no idea what you are talking about.

    Maybe you missed the fact that that sentence you quoted is sarcastic?

    He didn't, he just wanted to troll, not worth to reply.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?w5bDtiBUaWli?=@21:1/5 to Philipp Klaus Krause on Wed Nov 24 06:03:58 2021
    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).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to David Brown on Wed Nov 24 15:30:46 2021
    XPost: comp.lang.c

    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.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bart@21:1/5 to Manfred on Wed Nov 24 14:43:21 2021
    XPost: comp.lang.c

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Klaus Krause@21:1/5 to All on Wed Nov 24 21:13:11 2021
    XPost: comp.lang.c

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Philipp Klaus Krause@21:1/5 to All on Wed Nov 24 21:17:43 2021
    XPost: comp.lang.c

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lynn McGuire@21:1/5 to Otto J. Makela on Wed Nov 24 15:28:36 2021
    XPost: comp.lang.c

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Chris M. Thomasson@21:1/5 to Lynn McGuire on Wed Nov 24 14:12:04 2021
    XPost: comp.lang.c

    On 11/22/2021 2:19 PM, Lynn McGuire wrote:
    "C Is The Greenest Programming Language" by: Chris Lott
       https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/

    "Have you ever wondered if there is a correlation between a computer’s energy consumption and the choice of programming languages? Well, a
    group Portuguese university researchers did and set out to quantify it.
    Their 2017 research paper entitled Energy Efficiency across Programming Languages / How Do Energy, Time, and Memory Relate?  may have escaped
    your attention, as it did ours."
       https://greenlab.di.uminho.pt/wp-content/uploads/2017/10/sleFinal.pdf

    "Abstract: This paper presents a study of the runtime, memory usage and energy consumption of twenty seven well-known soft- ware languages. We monitor the performance of such lan- guages using ten different
    programming problems, expressed in each of the languages. Our results
    show interesting find- ings, such as, slower/faster languages consuming less/more energy, and how memory usage influences energy consump- tion.
    We show how to use our results to provide software engineers support to decide which language to use when energy efficiency is a concern."


    Humm... Perhaps, a main question can be, is there such a thing as a
    "green" programmer? One can write crappy and bloated code in C, that
    goes much slower than, say Python. However, one can write really
    efficient code in C... Therefore, the quality of a programmer seems to
    just want to come into play, so to speak...

    Using undefined behavior wrt the standard can be a key aspect to writing faster, more efficient code. Possible scenario: This os has built-in
    User-space Read-Copy-Update (URCU). However, if I use it then my program
    is no longer portable...

    Can things be greener with a talented programmer and a low-level
    language... Yes!

    Can things be greener with a crappy programmer and a low-level
    language... Humm, No? By chance? Unknown...?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Chris M. Thomasson on Thu Nov 25 12:00:07 2021
    XPost: comp.lang.c

    On 11/24/2021 11:12 PM, Chris M. Thomasson wrote:
    On 11/22/2021 2:19 PM, Lynn McGuire wrote:
    "C Is The Greenest Programming Language" by: Chris Lott

    https://hackaday.com/2021/11/18/c-is-the-greenest-programming-language/

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


    Humm... Perhaps, a main question can be, is there such a thing as a
    "green" programmer? One can write crappy and bloated code in C, that
    goes much slower than, say Python.

    Everything is possible, but achieving that requires some specialized skillset(!)

    However, one can write really
    efficient code in C... Therefore, the quality of a programmer seems to
    just want to come into play, so to speak...

    Using undefined behavior wrt the standard can be a key aspect to writing faster, more efficient code. Possible scenario: This os has built-in User-space Read-Copy-Update (URCU). However, if I use it then my program
    is no longer portable...

    Can things be greener with a talented programmer and a low-level
    language... Yes!

    Can things be greener with a crappy programmer and a low-level
    language... Humm, No? By chance? Unknown...?


    The issue is about idiomatic constructs, i.e. the mass of code running
    out there. I think that special circumstances and perverse cases do not
    really matter.
    Even more considering that C code that is so bad as to manage to perform
    worse than some interpreted language is most likely pretty much
    unmaintainable too, so doomed to fast extinction in the digital ecosystem.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Bart on Thu Nov 25 12:12:05 2021
    XPost: comp.lang.c

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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard Damon@21:1/5 to DozingDog@thekennel.co on Thu Nov 25 07:04:54 2021
    XPost: comp.lang.c

    On 11/25/21 6:19 AM, DozingDog@thekennel.co wrote:
    On Wed, 24 Nov 2021 11:54:50 -0500
    Richard Damon <Richard@Damon-Family.org> wrote:
    On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
    I doubt I could for example write a RB tree system better than that
    implemented
    in the C++ STL. It has 30 years of refining behind it.

    So you can directly implement that algorithm in C. yes, it gets messier,
    but you CAN do it.

    But there's no guarantee that it would be any faster.

    Indeed, but your argument that C always produces more efficient code than C++

    probably hasn't been true for 20 years.


    FLAW: Not ALWAYS, but CAN, big difference.

    Yes, C++ idioms can generate complex code faster than C, and allows
    things to be put into libraries that C can't readily do, and thus an
    expert can right the library and 'lend' that expertise to an ordinary
    code by them using the library. A custom coded C version can do just as
    well, because you can express the same instruction sequences in C as
    were generated in C++, you just need to be or explicit about it.

    Not always. eg:

    #include <iostream>

    constexpr int func(int cnt)
    {
    int val = 1;
    while(--cnt) val *= 2;
    return val;
    }


    int main()
    {
    constexpr int val = func(10);
    std::cout << val << std::endl;
    return 0;
    }


    In C++14 and onwards func() will literally be run by the compiler at compile time and the result hard coded into the binary. No C compiler can do that not because the language couldn't do it in theory, but because its never been specified in the standard.


    But you as the C programmer can do that too.

    Rather than write the expression func(10), since for this to work in
    C++, that 10 MUST be a known constant, I can manually compute the value.

    Again, the claim is that you can write the optimal code in C, but it may
    be a lot of work. It can be optimal for the use of CPU, but may well not
    be optimal for the use of Programmer.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From DozingDog@thekennel.co@21:1/5 to Richard Damon on Thu Nov 25 11:19:19 2021
    XPost: comp.lang.c

    On Wed, 24 Nov 2021 11:54:50 -0500
    Richard Damon <Richard@Damon-Family.org> wrote:
    On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
    I doubt I could for example write a RB tree system better than that >implemented
    in the C++ STL. It has 30 years of refining behind it.

    So you can directly implement that algorithm in C. yes, it gets messier,
    but you CAN do it.

    But there's no guarantee that it would be any faster.

    Indeed, but your argument that C always produces more efficient code than C++

    probably hasn't been true for 20 years.


    FLAW: Not ALWAYS, but CAN, big difference.

    Yes, C++ idioms can generate complex code faster than C, and allows
    things to be put into libraries that C can't readily do, and thus an
    expert can right the library and 'lend' that expertise to an ordinary
    code by them using the library. A custom coded C version can do just as
    well, because you can express the same instruction sequences in C as
    were generated in C++, you just need to be or explicit about it.

    Not always. eg:

    #include <iostream>

    constexpr int func(int cnt)
    {
    int val = 1;
    while(--cnt) val *= 2;
    return val;
    }


    int main()
    {
    constexpr int val = func(10);
    std::cout << val << std::endl;
    return 0;
    }


    In C++14 and onwards func() will literally be run by the compiler at compile time and the result hard coded into the binary. No C compiler can do that not because the language couldn't do it in theory, but because its never been specified in the standard.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From DozingDog@thekennel.co@21:1/5 to Juha Nieminen on Thu Nov 25 15:57:53 2021
    XPost: comp.lang.c

    On Thu, 25 Nov 2021 11:46:56 -0000 (UTC)
    Juha Nieminen <nospam@thanks.invalid> wrote:
    In comp.lang.c++ DozingDog@thekennel.co wrote:
    constexpr int func(int cnt)
    {
    int val = 1;
    while(--cnt) val *= 2;
    return val;
    }


    int main()
    {
    constexpr int val = func(10);
    std::cout << val << std::endl;
    return 0;
    }


    In C++14 and onwards func() will literally be run by the compiler at compile >> time and the result hard coded into the binary. No C compiler can do that not

    because the language couldn't do it in theory, but because its never been
    specified in the standard.

    Actually gcc (and probably clang) will inline that function and calculate it >at compile time in C. You'll need a much more complicated constexpr function >for it to not be calculated at compile time by the compiler in C.

    Possibly if you set optimisation quite high (and remove the constexpr keyword), but you can't rely on it, whereas you can in C++ because its in the standard.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paavo Helde@21:1/5 to All on Sun Dec 5 22:51:47 2021
    XPost: comp.lang.c

    23.11.2021 00:19 Lynn McGuire kirjutas:
    "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

    In my experience, any efforts towards more efficient software are easily defeated by users throwing more data to the program.

    Wow, so you can fully analyze a 1024x1024 microscope image in less than
    a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
    in the next version!

    So, you managed to speed up the calculation time of morphological
    features by 50%. Fine, now we want to calculate 1000 features instead of
    the former 20!

    Thus I'm afraid any hopes for a "green" programming language are at best naïve.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Manfred@21:1/5 to Paavo Helde on Mon Dec 6 12:28:17 2021
    XPost: comp.lang.c

    On 12/5/2021 9:51 PM, Paavo Helde wrote:
    23.11.2021 00:19 Lynn McGuire kirjutas:
    "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

    In my experience, any efforts towards more efficient software are easily defeated by users throwing more data to the program.

    Wow, so you can fully analyze a 1024x1024 microscope image in less than
    a second! Wonderful, let's upgrade our hardware to take 2160x2160 images
    in the next version!

    So, you managed to speed up the calculation time of morphological
    features by 50%. Fine, now we want to calculate 1000 features instead of
    the former 20!

    Thus I'm afraid any hopes for a "green" programming language are at best naïve.


    True, but this doesn't make inefficient languages any better, does it?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Bonita Montero@21:1/5 to All on Mon Dec 6 16:21:44 2021
    XPost: comp.lang.c

    Am 05.12.2021 um 21:51 schrieb Paavo Helde:

    In my experience, any efforts towards more efficient software
    are easily defeated by users throwing more data to the program.

    And that should determine the absolute possible efficiency of a
    programming language? I think not.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Juha Nieminen on Thu Dec 16 07:55:43 2021
    Juha Nieminen <nospam@thanks.invalid> writes:

    [...] Most object-oriented languages don't really care about,
    especially, memory consumption. Especially garbage-collected OO
    languages don't give a flying F about memory consumption. [...]

    A humorous statement, considering that there were OOP systems,
    including garbage collection, running years before even the
    predecessor to C++, "C with Classes", existed. And these systems
    ran on hardware platforms that don't have enough memory to run
    probably any C++ compiler of the last 20+ years.

    Note by the way that using garbage collection very likely reduced
    the overall memory footprint, because all the places where there
    would have been code to free memory no code is needed, replaced
    by a single piece of code in the memory manager.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard@21:1/5 to All on Thu Dec 16 16:24:21 2021
    [Please do not mail me a copy of your followup]

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

    A humorous statement, considering that there were OOP systems,
    including garbage collection, running years before even the
    predecessor to C++, "C with Classes", existed.

    Are you thinking of Smalltalk or LISP?

    Note by the way that using garbage collection very likely reduced
    the overall memory footprint, because all the places where there
    would have been code to free memory no code is needed, replaced
    by a single piece of code in the memory manager.

    An interesting hypothesis, but I'm not convinced without data.
    --
    "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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Richard on Thu Dec 16 19:46:10 2021
    legalize+jeeves@mail.xmission.com (Richard) writes:

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

    A humorous statement, considering that there were OOP systems,
    including garbage collection, running years before even the
    predecessor to C++, "C with Classes", existed.

    Are you thinking of Smalltalk or LISP?

    Smalltalk.

    Note by the way that using garbage collection very likely reduced
    the overall memory footprint, because all the places where there
    would have been code to free memory no code is needed, replaced
    by a single piece of code in the memory manager.

    An interesting hypothesis, but I'm not convinced without data.

    Probably it depends on what applications are being programmed, given
    that Smalltalk is an interactive programming and development system.
    But surely it becomes true at some point as more code is written,
    since the amount of non-automatic memory management code would grow
    as additional applications are written, but code (and so the amount
    of code) in the garbage collector stays fixed regardless of how much application code is added.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Juha Nieminen@21:1/5 to Tim Rentsch on Fri Dec 17 06:30:07 2021
    Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
    A humorous statement, considering that there were OOP systems,
    including garbage collection, running years before even the
    predecessor to C++, "C with Classes", existed. And these systems
    ran on hardware platforms that don't have enough memory to run
    probably any C++ compiler of the last 20+ years.

    Note by the way that using garbage collection very likely reduced
    the overall memory footprint, because all the places where there
    would have been code to free memory no code is needed, replaced
    by a single piece of code in the memory manager.

    What systems had so little memory that they couldn't even run a C++
    compiler, yet had an operating system that offered a memory manager
    with GC? And, ostensibly, was a multitasking OS (given that you are
    arguing the programs had an overall smaller memory footprint).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Juha Nieminen on Sat Dec 18 07:45:16 2021
    Juha Nieminen <nospam@thanks.invalid> writes:

    Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

    A humorous statement, considering that there were OOP systems,
    including garbage collection, running years before even the
    predecessor to C++, "C with Classes", existed. And these systems
    ran on hardware platforms that don't have enough memory to run
    probably any C++ compiler of the last 20+ years.

    Note by the way that using garbage collection very likely reduced
    the overall memory footprint, because all the places where there
    would have been code to free memory no code is needed, replaced
    by a single piece of code in the memory manager.

    What systems had so little memory that they couldn't even run a C++
    compiler, yet had an operating system that offered a memory manager
    with GC? And, ostensibly, was a multitasking OS (given that you are
    arguing the programs had an overall smaller memory footprint).

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard@21:1/5 to All on Thu Dec 30 12:01:58 2021
    [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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Richard on Sun Jan 16 12:22:42 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard@21:1/5 to All on Mon Jan 17 21:28:17 2022
    [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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tim Rentsch@21:1/5 to Richard on Mon Jan 17 15:48:24 2022
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Richard@21:1/5 to All on Tue Jan 18 06:47:51 2022
    [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>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)