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

#82456

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 ?

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

#82457

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.

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

#82460

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

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

#82463

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.

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

#82487

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

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

#82451

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.

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

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

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

#82454

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.

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

#82479

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.

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

#82480

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.

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

#82484

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.

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

#82481

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.

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

#82485

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.

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

#82403

On 11/22/2021 11:19 PM, Lynn McGuire wrote:
> Our results show interesting find- ings, such as, slower/faster 
> languages consuming less/more energy, and how memory usage influences 
> energy consump- tion

I find the correlation slower/faster language respectively less/more 
energy quite confusing. In fact I believe it is the opposite.

An interpreted language (á la Java :O) may require orders of magnitude 
more CPU instructions than C to perform the same task. This makes the 
former slower and more energy consuming than the latter.

Slower or faster /hardware/ is a totally different thing, of course.

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

#82405

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.

-- 
https://en.wikipedia.org/wiki/Mansplaining

    It describes comp.lang.c to a T!

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

#82408

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.

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

#82412

On Tue, 23 Nov 2021 17:51:09 +0100
David Brown <david.brown@hesbynett.no> wrote:
>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.

Why do many battery powered systems throttle the CPU to save the battery when
its getting low then and why does undertaking CPU intensive tasks deplete the
battery faster? You seem to be claiming that you can get something for nothing.

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

#82414

On 11/23/21 12:00 PM, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 17:51:09 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> 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.
> 
> Why do many battery powered systems throttle the CPU to save the battery when
> its getting low then and why does undertaking CPU intensive tasks deplete the
> battery faster? You seem to be claiming that you can get something for nothing.
> 

CPUs, at a given operating voltage will consume an approximately fixed 
amount of energy per instruction.

One effect of slowing down the processor is that if it was running at 
25% utilization, that means that 75% of the instructions executed did no 
'useful' work, so slowing down the processor to make instructions take 
longer means you do less of these wasteful cycles.

Some processors have the ability that when it get to those 'wasteful' 
instructions it automatically 'stops' and drops its power concumption 
until something happens that needs running again.

The other affect is that in many cases if you slow down the processor 
speed, you can slightly drop the voltage you are running the processor 
at, and the power consumed turns out to go largely as the square of the 
voltage (as the dynamic power is consumed in charging and discharging 
tiny capacitance through the system)


So, through various tricks in the system, you can sometimes save some 
power when the processor is 'idle' or running 'slower'. Battery powered 
system especially try to implement these sorts of capability.

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

#82416

On 23/11/2021 18:00, DozingDog@thekennel.co wrote:
> On Tue, 23 Nov 2021 17:51:09 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>> 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.
> 
> Why do many battery powered systems throttle the CPU to save the battery when
> its getting low then and why does undertaking CPU intensive tasks deplete the
> battery faster? You seem to be claiming that you can get something for nothing.
> 

If you have to do a certain calculation or set of calculations, it is
/usually/ more efficient to do them quickly and then let the processor
sleep deeper and longer.

Modern cpus generally do /not/ throttle the cpu speed to save battery
power.  It only makes sense to slow down the processor if you have large
leakage currents that you can't turn off, in which case a slow clock can
mean lower energy overall.  With modern devices, clock gating lets you
turn off all or parts of the core much more effectively.

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

#82418

On 11/23/21 1:24 PM, David Brown wrote:
> On 23/11/2021 18:00, DozingDog@thekennel.co wrote:
>> On Tue, 23 Nov 2021 17:51:09 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>> 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.
>>
>> Why do many battery powered systems throttle the CPU to save the battery when
>> its getting low then and why does undertaking CPU intensive tasks deplete the
>> battery faster? You seem to be claiming that you can get something for nothing.
>>
> 
> If you have to do a certain calculation or set of calculations, it is
> /usually/ more efficient to do them quickly and then let the processor
> sleep deeper and longer.
> 
> Modern cpus generally do /not/ throttle the cpu speed to save battery
> power.  It only makes sense to slow down the processor if you have large
> leakage currents that you can't turn off, in which case a slow clock can
> mean lower energy overall.  With modern devices, clock gating lets you
> turn off all or parts of the core much more effectively.
> 

Not sure if this holds for desktop/laptop caliber processors, but in the 
embedded world, many processors can have their core voltage dropped down 
when running at slower speeds, and since switching energy is 
proportional to V^2, slowing the processor and waiting less CAN save power.

I beleive this applies to processors with a 'Turbo' or 'Overclocked' 
mode in the desktop/laptop space, to run their fastest, they need to 
boost their power supplies at the cost of increase power consumption but 
fast speeds become available.

Then there is the fact that the 'simple' idle modes don't stop 
everything, so you are still burning the higher frequency power even 
when idle in parts of the circuit, and switching to more power savings 
mode can take a bit of time and actually cost power (as you power down 
then back up sections of the die) means that slower, higher usage, uses 
less power.

The problem is that this also limits you PEAK operational speed, so you 
need to balence those needs with your power concumption.

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

#82421

On 23/11/2021 19:50, Richard Damon wrote:
> On 11/23/21 1:24 PM, David Brown wrote:
>> On 23/11/2021 18:00, DozingDog@thekennel.co wrote:
>>> On Tue, 23 Nov 2021 17:51:09 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>> 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.
>>>
>>> Why do many battery powered systems throttle the CPU to save the
>>> battery when
>>> its getting low then and why does undertaking CPU intensive tasks
>>> deplete the
>>> battery faster? You seem to be claiming that you can get something
>>> for nothing.
>>>
>>
>> If you have to do a certain calculation or set of calculations, it is
>> /usually/ more efficient to do them quickly and then let the processor
>> sleep deeper and longer.
>>
>> Modern cpus generally do /not/ throttle the cpu speed to save battery
>> power.  It only makes sense to slow down the processor if you have large
>> leakage currents that you can't turn off, in which case a slow clock can
>> mean lower energy overall.  With modern devices, clock gating lets you
>> turn off all or parts of the core much more effectively.
>>
> 
> Not sure if this holds for desktop/laptop caliber processors, but in the
> embedded world, many processors can have their core voltage dropped down
> when running at slower speeds, and since switching energy is
> proportional to V^2, slowing the processor and waiting less CAN save power.

That depends on the class of embedded system.  If you are talking about
large embedded processors - running embedded Linux, for instance - then
that's true.  But even there you usually aim for high speed and lots of
sleep if you can.  However, as I mentioned, entering and exiting sleep
modes takes some time - if you are doing it too frequently, that
overhead becomes dominant and it is better to run the whole thing at a
low clock rate.

Smaller embedded systems rarely change the voltage to the core.

> 
> I beleive this applies to processors with a 'Turbo' or 'Overclocked'
> mode in the desktop/laptop space, to run their fastest, they need to
> boost their power supplies at the cost of increase power consumption but
> fast speeds become available.
> 
> Then there is the fact that the 'simple' idle modes don't stop
> everything, so you are still burning the higher frequency power even
> when idle in parts of the circuit, and switching to more power savings
> mode can take a bit of time and actually cost power (as you power down
> then back up sections of the die) means that slower, higher usage, uses
> less power.
> 
> The problem is that this also limits you PEAK operational speed, so you
> need to balence those needs with your power concumption.

It is all a complicated balance, and a subject of continuous development
and improvement - no one choice fits everything.  (And the ideal power
management decisions need to know what a process is going to do before
it does it.)

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

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

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

csiph-web