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

Groups > comp.lang.c > #163577 > unrolled thread

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

Back to article view | Back to comp.lang.c

Contents

  "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-22 16:19 -0600
    Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-22 14:58 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-23 07:10 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-23 13:12 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-24 10:54 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 12:01 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-24 13:58 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-23 13:23 -0800
    Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-22 18:25 -0500
      Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-23 07:21 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Thiago Adams <thiago.adams@gmail.com> - 2021-11-23 04:50 -0800
        Re: "C Is The Greenest Programming Language" by: Chris Lott Guillaume <message@bottle.org> - 2021-11-23 17:56 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-24 10:55 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-23 19:00 -0600
          Re: "C Is The Greenest Programming Language" by: Chris Lott scott@slp53.sl.home (Scott Lurndal) - 2021-11-24 16:04 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:43 +0100
    Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-23 14:17 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 16:53 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-24 11:40 +0200
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-24 15:49 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-23 19:01 -0600
        Re: "C Is The Greenest Programming Language" by: Chris Lott om@iki.fi (Otto J. Makela) - 2021-11-24 11:33 +0200
          Re: "C Is The Greenest Programming Language" by: Chris Lott Lynn McGuire <lynnmcguire5@gmail.com> - 2021-11-24 15:28 -0600
    Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 14:39 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 16:55 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 12:28 -0500
          Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 19:05 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 13:41 -0500
              Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-23 19:53 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-23 16:31 -0800
                Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 21:27 -0500
                  Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-24 18:32 +0100
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 12:54 -0500
                      Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-24 20:52 +0100
                        Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 15:13 -0500
                          Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-11-25 19:13 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-11-23 16:25 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-24 15:48 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-24 11:54 -0500
              Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 11:19 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Juha Nieminen <nospam@thanks.invalid> - 2021-11-25 11:46 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 15:57 +0000
                Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-25 07:04 -0500
                  Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-25 15:59 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott Thiago Adams <thiago.adams@gmail.com> - 2021-11-26 03:37 -0800
    Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 16:03 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott gazelle@shell.xmission.com (Kenny McCormack) - 2021-11-23 15:50 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 17:51 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott DozingDog@thekennel.co - 2021-11-23 17:00 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 12:36 -0500
            Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 19:24 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott Richard Damon <Richard@Damon-Family.org> - 2021-11-23 13:50 -0500
                Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 20:02 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 20:59 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 20:50 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Ian Collins <ian-news@hotmail.com> - 2021-11-24 11:18 +1300
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 22:58 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 23:46 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 13:59 +0000
                  Re: "C Is The Greenest Programming Language" by: Chris Lott antispam@math.uni.wroc.pl - 2021-12-11 13:25 +0000
                    Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-12-11 14:54 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-25 12:12 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-23 23:35 +0100
              Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-24 15:30 +0100
                Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 14:43 +0000
        Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-23 20:29 +0100
      Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-23 16:14 +0000
      Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 11:56 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-24 10:14 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott David Brown <david.brown@hesbynett.no> - 2021-11-24 19:55 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:13 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:11 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 21:17 +0100
          Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-11-24 20:42 +0000
            Re: "C Is The Greenest Programming Language" by: Chris Lott Philipp Klaus Krause <pkk@spth.de> - 2021-11-24 23:25 +0100
            Re: "C Is The Greenest Programming Language" by: Chris Lott antispam@math.uni.wroc.pl - 2021-12-11 14:07 +0000
              Re: "C Is The Greenest Programming Language" by: Chris Lott Bart <bc@freeuk.com> - 2021-12-11 18:46 +0000
                [OT] Lisp.  Was: "C Is The Greenest Programming Language" by: Chris Lott Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-11 20:11 +0000
                  Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-13 17:59 -0800
                    Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-14 03:18 +0000
                      Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-16 10:57 -0800
                        Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-16 22:03 +0000
                          Re: "C Is The Greenest Programming Language" Dave Dunfield <dave.dunfield@gmail.com> - 2021-12-20 02:40 -0800
                            Re: "C Is The Greenest Programming Language" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-12-20 12:05 +0000
    Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-11-24 14:12 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-11-25 12:00 +0100
    Re: "C Is The Greenest Programming Language" by: Chris Lott Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-05 22:51 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-05 19:20 -0800
        Re: "C Is The Greenest Programming Language" by: Chris Lott Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-12-06 01:52 -0800
          Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-06 12:19 -0800
            Re: "C Is The Greenest Programming Language" by: Chris Lott "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2021-12-06 12:27 -0800
      Re: "C Is The Greenest Programming Language" by: Chris Lott Manfred <noname@add.invalid> - 2021-12-06 12:28 +0100
        Re: "C Is The Greenest Programming Language" by: Chris Lott Paavo Helde <eesnimi@osa.pri.ee> - 2021-12-06 13:40 +0200
      Re: "C Is The Greenest Programming Language" by: Chris Lott Bonita Montero <Bonita.Montero@gmail.com> - 2021-12-06 16:21 +0100

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

#163669

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]

#163673

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]

#163670

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]

#163674

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]

#163684

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.

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

#163597

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]

#163598

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]

#163603

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]

#163607

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]

#163609

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]

#163612

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]

#163615

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]

#163617

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]

#163620

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.

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

#163621

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.

How about writing efficient applications? And efficient OSes (there 
might be 1000 processes on my PC right now).

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.

(For a couple of years one of my compilers was run as interpreted, 
dynamic bytecode. It was still double the speed of gcc!)

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

#163624

On 24/11/2021 09:50, Bart wrote:
> 
> 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.
> 
> (For a couple of years one of my compilers was run as interpreted,
> dynamic bytecode. It was still double the speed of gcc!)
> 

Well if it generates unoptimised code, it is still not very "green" is 
it?  Unless you are compiling often and running once...

-- 
Ian.

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

#163627

On 23/11/2021 22:18, Ian Collins wrote:
> On 24/11/2021 09:50, Bart wrote:
>>
>> 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.
>>
>> (For a couple of years one of my compilers was run as interpreted,
>> dynamic bytecode. It was still double the speed of gcc!)
>>
> 
> Well if it generates unoptimised code, it is still not very "green" is 
> it?

Well, so was gcc-O0, which was how the comparison was made. Otherwise 
the disparity would have been greater.

And aside from the speed, my stuff also tends to be small, so also 
economising on storage, loading, storing, downloading, memory...

Here are compilation rates for my tools (build from source), using my 
current compiler:

   mm   10 Hz    (main compiler)
   pc   14 Hz    (IL project, my version of llvm)
   aa   20 Hz    (assembler/linker)
   qq   10 Hz    (interpreter)
   bcc   9 Hz    (C compiler)

10 Hz means I can build the project 10 times in one second (and using 
one core). I'd be interested to see the equivalent figure for gcc or llvm.

If it was only running my stuff, my PC would have very little to do!

> Unless you are compiling often and running once...

During development that's exactly what you do.

For a production program, then yes you can go to town on optimising, 
because you don't do it repeatedly.

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

#163626

On 23/11/2021 21:50, Bart wrote:
> On 23/11/2021 19:59, Manfred wrote:

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

Agreed (mostly).

> How about writing efficient applications? And efficient OSes (there
> might be 1000 processes on my PC right now).

Yes - it is the software that takes energy, not the language.  It's fair
to say that the software does a lot more now than it used to, but it's
equally fair to question whether that extra work is necessary.

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

Yes.  But that is because I understand the difference between compiling
code and /running/ compiled code.  As long as your compilation process
is not so slow that it hinders the development process, it doesn't
matter.  If a program is only going to be used on a few systems or by a
few people, then the dominant cost is the programmer (and their energy
needs massively outweighs the compiler's).  If it is going to be used a
lot, then the dominant cost is the target systems' runtime (and thus you
want as efficient results as you can get from the source code).  At no
point is the effort or energy required by the compiler at all relevant
in the total sum.

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

#163645

On 23/11/2021 22:46, David Brown wrote:
> On 23/11/2021 21:50, Bart wrote:

>> 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.
>>
> 
> Yes.  But that is because I understand the difference between compiling
> code and /running/ compiled code.  As long as your compilation process
> is not so slow that it hinders the development process,

I find compilers such as gcc slower enough that they would hinder /me/. 
I can build my 3 main language tools, about 120Kloc and 100 files, in 
1/4 second, the same time it takes gcc to build hello.c, about 4 lines 
in one file.

> it doesn't
> matter.  If a program is only going to be used on a few systems or by a
> few people, then the dominant cost is the programmer (and their energy
> needs massively outweighs the compiler's).  If it is going to be used a
> lot, then the dominant cost is the target systems' runtime (and thus you
> want as efficient results as you can get from the source code).  At no
> point is the effort or energy required by the compiler at all relevant
> in the total sum.

It was a example of the sort of program that I can make run efficiently 
by making some extra effort, and also keeping things small, which 
actually was not written in C.

It isn't about language, except that everything else being equal, a C 
implementation of a computationally intensive application like mine is 
going to be faster than an equivalent CPython version, and mostly likely 
still faster than PyPy.

So if gcc was implemented in CPython, compiling hello.c might takes 10 
seconds instead of 0.25 seconds, but tcc does the job in 0.03 seconds.

Consider that on my machine, even an empty program takes 0.02 seconds to 
run...

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

#163783

In comp.lang.c Bart <bc@freeuk.com> wrote:
> Consider that on my machine, even an empty program takes 0.02 seconds to 
> run...

Get a better system if you care about such runtimes.  _Statically_
compiled program on Linux needs less than 300 uS to run (of course
this assumes file caching works as intended, if you have spinning
disk first access still needs seek time).
 
-- 
                              Waldek Hebisch

[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