It doesn't make a whole lot of sense to talk about the energy efficiency

of a programming language.  For example, I've seen the run time of a

C benchmark go from 50 seconds to 1 microsecond when the optimisation

level was changed.  It doesn't even make much sense to talk about the

energy efficiency of the code generated by a specific compiler with

specific options: the underlying hardware counts too.   A colleague of

mine, looking at text compression algorithms for an information retrieval

engine, found that the fastest algorithm depended on just which x86-64

chip, even what motherboard, was in use.  It's obviously going to be

the same for energy efficiency.

So let's specify a particular physical machine, a particular compiler,

and a particular set of compiler options.  NOW does it make sense to

talk about energy efficiency?  Nope.  It's going to depend on the

problem as well.  And the thing is that people tend to do different

things in different programming languages, and different communities

attract different support.  There is no portable Smalltalk equivalent

of NumPy, able to automatically take advantage of GPUs, for example.

You can get some real surprises.

For example, just now while writing this message, I fired up

powerstat(8).  I had the browser open and power consumption was

about 12.8 W.  I then launched Squeak and ran some benchmarks.

Power consumption went DOWN to 11.4 W.

That is, Squeak was "costing" me -1.4 W.

If you understand the kind of things modern CPUs get up to, that

is not as surprising as it seems.  All it demonstrates is that

getting MEANINGFUL answers is hard enough; getting GENERALISBLE

answers is going to be, well, if anyone succeeded, I think they

would have earned at least a Masters.

On Tue, 13 Oct 2020 at 23:38, Jonathan van Alteren <[hidden email]> wrote:

Hi Stéphane,

Thanks for your feedback. I agree that the usefulness of these results is limited. However, if we (Object Guild) want to make a case for energy efficiency, it can help if the language itself can be shown to be efficient as well. 

For now, I think the efficiency will need to come from a good object design.

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

On 11 Oct 2020, 16:49 +0200, Stéphane Ducasse <[hidden email]>, wrote:

The problem is that what do you measure. 

When you move computation from the CPU to a GPU for example does it consume less or more. 

I think that such analyses are totally stupid. 

Is a fast execution consume less? I have serious doubts about it.

Now if we measure how fast we drain a battery because of polling vs event based then this is different. 

S. 

On 1 Oct 2020, at 13:47, Jonathan van Alteren <[hidden email]> wrote:

Hi all,

I am interested in energy efficiency metrics for Pharo (version >=8). Just now, I came across this research and related GitHub project:

• https://sites.google.com/view/energy-efficiency-languages
• https://github.com/greensoftwarelab/Energy-Languages

Unfortunately, the paper mentions that Smalltalk was excluded from the results because the (VW) compiler was proprietary :-S However, the GitHub repository does contain Smalltalk code and results, but I haven't been able to evaluate those.

[1] Does anyone here have more information on this topic?


The benchmarks seem to be low-level algorithms. Although that is useful, I think that a better argument for Pharo/Smalltalk efficiency is that a good OO design (e.g. created using responsibility-driven design with behaviorally complete objects) will be a better fit, can be much simpler and will thus be more efficient during development, as well as easier to maintain and evolve.

[2] Has anyone done any research in this area that can quantify this aspect?

Kind regards,

Jonathan van Alteren

Founding Member | Object Guild B.V.
Sustainable Software for Purpose-Driven Organizations

[hidden email]

--------------------------------------------

Stéphane Ducasse

http://stephane.ducasse.free.fr / http://www.pharo.org 

03 59 35 87 52

Assistant: Aurore Dalle 

FAX 03 59 57 78 50

TEL 03 59 35 86 16

S. Ducasse - Inria

40, avenue Halley, 

Parc Scientifique de la Haute Borne, Bât.A, Park Plaza

Villeneuve d'Ascq 59650

France