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.

Lynn McGuire <lynnmcguire5@gmail.com> writes:
>On 11/23/2021 1:21 AM, Juha Nieminen wrote:
>> In comp.lang.c++ Richard Damon <Richard@damon-family.org> wrote:

>> Ironically, the programming world has in the last couple of decades awakened
>> to the harsh realization that this complete disregard of memory usage
>> actually causes inefficiencies in modern CPU architectures (because
>> cache misses are very expensive).
>>
>> Oh well. As long as it works, who cares? Buy a faster computer.
>
>Not in California.

And Hawaii, Colorado, Oregon, Vermont and Washington State.

Why did you single out California?

And one can certainly purchase the most powerful computers in all of those
states by assembling them personally - note also that servers aren't covered
by the regulation, only desktop systems.

Did you actually read the article you posted a link to?

Here's an article without the panic, and with actual, you know, facts.

https://www.makeuseof.com/why-the-california-ban-on-power-hogging-pcs-is-a-good-thing/

On 11/24/21 10:48 AM, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 12:28:12 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>> 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
>
> So can a C++ compiler and with modern additions such constexpr C++ can optimise
> in ways that C simply can't.
>
>> ANYTHING in terms of data-structures that another language can generate,
>> you can generate in C.
>
> True, but you have to re-invent the wheel each time because frankly the level
> of complex data structure library support in the standard library in C is
> woeful. Eg the hsearch() and bsearch() functionality are frankly rubbish (only
> 1 tree/hash per process!) and Berkeley DB is a PITA to use.

Right, I never said it was the BEST way, especially if you include
programmer productivity.

If your goal is ABSOLUTELY TOP CPU EFFICIENCY, then 'standard libraries'
become just optional (use only if it IS the best for YOUR job).

Yes, this might mean 3 years of programming to say a millisecond of
execution, but it still puts the hand crafted code ahead of the higher
level langauge in RAW efficiency.

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

And, yes, it also means you need to research (or look at implementations
and 'borrow') the best methods. Lots of programmer effort to get the
greenest code.

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

Am 24.11.2021 um 03:27 schrieb Richard Damon:
> 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.

A class having a variant<string_view, string> member and an interface
to get or modify that string ? F.e. you could add a modify-interface
that does a copy-on-write modification of the string_view state,
chaning it into a string-state ?

On 11/24/21 12:32 PM, Bonita Montero wrote:
> Am 24.11.2021 um 03:27 schrieb Richard Damon:
>> 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.
>
> A class having a variant<string_view, string> member and an interface
> to get or modify that string ? F.e. you could add a modify-interface
> that does a copy-on-write modification of the string_view state,
> chaning it into a string-state ?
>

Your getting very heavy now.

It was much simpler to just implement the version of string I wanted,
which kept a pointer to the data, and an allocation size.

When constructed from a char const* value, it checked if this pointer
was to the read only block of memory, and if so didn't copy that string,
but just kept the original pointer, with an allocated size of 0 (to make
it easy to see if it was a read only string or a writable).

If your use case doesn't fit what the library supports well, you can
make you own.

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

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

>> A class having a variant<string_view, string> member and an interface
>> to get or modify that string ? F.e. you could add a modify-interface
>> that does a copy-on-write modification of the string_view state,
>> chaning it into a string-state ?

> Your getting very heavy now.

Ok, developing a variant-string-class with all constructors,
methods and operators would be complex. But having s simple
variant<string, string_view> is easy.

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

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.

On 11/24/21 2:52 PM, Bonita Montero wrote:
>>> A class having a variant<string_view, string> member and an interface
>>> to get or modify that string ? F.e. you could add a modify-interface
>>> that does a copy-on-write modification of the string_view state,
>>> chaning it into a string-state ?
>
>> Your getting very heavy now.
>
> Ok, developing a variant-string-class with all constructors,
> methods and operators would be complex. But having s simple
> variant<string, string_view> is easy.

Building a variant<string, string_view> may be easy but would be a HOG.

My variant-string class implement all the functionality I needed, and
none of the stuff I wanted, and saved a LOT of memory as the standard
string class include a LOT of virtual functions to do things I don't
need, and my implementation isn't smart enough to do the whole program
recompile to trim out unneeded virtual functions.

For 1 day of work I saves about 25% of my programs size becuase I could
drop all the locale support that I didn't need.

The first cut string version was to fix a program to big error for an
embedded system because std::string pulled in WAY too much code just to
exist.

The second cut added the const char* string optimization to save a lot
of ram.

Situation awareness is key here.

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.

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

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

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

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

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.

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

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.

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.

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.

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.

On Thu, 25 Nov 2021 07:04:54 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
>On 11/25/21 6:19 AM, DozingDog@thekennel.co wrote:
>> 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.

You could manually compute logarithm and trig tables but I imagine you'd
prefer to use log() and sin() instead.

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

Well quite.

> My variant-string class implement all the functionality I needed, and
> none of the stuff I wanted, and saved a LOT of memory as the standard
> string class include a LOT of virtual functions to do things I don't
> need, ...

basic_string<> doesn't include virtual functions and if basic_string<>
would use virtual functions, they would take only one VMT-pointer per
object.

On Thursday, November 25, 2021 at 9:05:17 AM UTC-3, Richard Damon wrote:
> On 11/25/21 6:19 AM, Dozi...@thekennel.co wrote:
> > On Wed, 24 Nov 2021 11:54:50 -0500
> > Richard Damon <Ric...@Damon-Family.org> wrote:
> >> On 11/24/21 10:48 AM, Dozi...@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.

Yes, and the compilation does not need to recalculate this every time.