Re: Green Compiler ?

anton@mips.complang.tuwien.ac.at (Anton Ertl)
Fri, 28 Dec 2012 16:57:06 GMT

          From comp.compilers

Related articles
[6 earlier articles]
Re: Green Compiler ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-12-28)
Re: Green Compiler ? Pidgeot18@verizon.invalid (Joshua Cranmer) (2012-12-27)
Re: Green Compiler ? nmh@t3x.org (Nils M Holm) (2012-12-28)
Re: Green Compiler ? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-12-28)
Re: Green Compiler ? walter@bytecraft.com (Walter Banks) (2012-12-28)
Re: Green Compiler ? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2012-12-28)
Re: Green Compiler ? anton@mips.complang.tuwien.ac.at (2012-12-28)
Re: Green Compiler ? gneuner2@comcast.net (George Neuner) (2012-12-28)
Re: Green Compiler ? z80eu@arcor.de (Peter Dassow) (2012-12-29)
Re: Green Compiler ? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2012-12-30)
Re: Green Compiler ? mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2012-12-30)
Re: Green Compiler ? gneuner2@comcast.net (George Neuner) (2012-12-31)
Re: Green Compiler ? jthorn@astro.indiana.edu (Jonathan Thornburg) (2013-01-02)
[5 later articles]
| List of all articles for this month |

From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.compilers
Date: Fri, 28 Dec 2012 16:57:06 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 12-12-010 12-12-013 12-12-023 12-12-027
Keywords: performance, architecture
Posted-Date: 29 Dec 2012 16:51:47 EST

"Nils M Holm" <nmh@t3x.org> writes:
>Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>> "Nils M Holm" <nmh@t3x.org> writes:
>> >In principle, I would say that higher execution speed equals more
>> >green-ness. Less time spent dissipating heat means less energy
>> >consumed.
...
>So you are basically arguing that people always try to get the maximum
>out of their resources and therefore faster code is worse.


Not worse, but the claims you made above are a bit too simple-minded.
Fast code still has the advantage of being fast; but it does not
necessarily save energy.


>Your first example was games. Why does a game *have to* use the
>maximum number of frames per second? When a given number of frames per
>second is sufficient, in the sense that additional frames will not
>make the video output any smoother, why increase the frame rate
>further? Let the program sleep between frames. In this case fast code
>can sleep between frames, slow code can't.


But do game designers work that way? If the game engine is so fast
that it can sleep between frames, they put in more features in the
game that make use of the CPU; or the reverse, they don't take as many
features out in the slimming phase when they try to make the game run
smooth enough. So the faster code buys a more featureful game, but it
does not save energy.


Or at the level of the end user (player), they tune the graphics
details such that they get the maximum details at an acceptable frame
rate on their machine. So a faster program means more details, not
less energy consumption.


>Same for virus scanner: why run them more often?


More often? AFAIK, these days the virus scanners are running
constantly in the background and consume one or two cores. I don't
know if that has a technical reason or is just done to give the users
a feeling of better protection, but that does not matter for the
energy consumption.


>So I would argue that the issue you raise is a psychological one rather
>than a technical one. When people always want to get the maximum out
>of their resources, then there is no way to reduce power consumption,
>except, maybe, by creating *slower* processors.


Or at least processors and machines with lower power consumption under
load (yes, they tend to be slower, the converse is not necessarily
true). Yes, you can see it as a psychological issue, but that does
not make it less real. Idle power consumption is also an issue, for
some workloads.


- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.