RE: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[3.1415926535897932384626433832795]

The page is fixed BTW
>>>import this

On Sun, Sep 17, 2017 at 6:13 AM, <python-list-requ...@python.org> wrote:

> Send Python-list mailing list submissions to
> python-list@python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.python.org/mailman/listinfo/python-list
> or, via email, send a message with subject or body 'help' to
> python-list-requ...@python.org
>
> You can reach the person managing the list at
> python-list-ow...@python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Python-list digest..."
>
> Today's Topics:
>
>1. Re: Old Man Yells At Cloud (Dennis Lee Bieber)
>2. Re: Old Man Yells At Cloud (Stefan Ram)
>3. Re: Which database system? (Stefan Ram)
>4. CPython has hit 100,000 commits (breamore...@gmail.com)
>5. [RELEASE] Python 2.7.14 (Benjamin Peterson)
>6. Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?"
>   (breamore...@gmail.com)
>7. Re: Old Man Yells At Cloud (Steve D'Aprano)
>8. Re: Old Man Yells At Cloud (John Pote)
>9. Re: Old Man Yells At Cloud (Steve D'Aprano)
>   10. Re: Old Man Yells At Cloud (MRAB)
>   11. Re: Old Man Yells At Cloud (Chris Angelico)
>   12. Re: Old Man Yells At Cloud (Chris Angelico)
>   13. Re: Old Man Yells At Cloud (Dennis Lee Bieber)
>   14. Re: Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?" (Steve
> D'Aprano)
>   15. Re: Old Man Yells At Cloud (Stefan Ram)
>   16. Re: Old Man Yells At Cloud (Paul Rubin)
>   17. Re: Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?" (Ian Kelly)
>   18. Re: Old Man Yells At Cloud (Stefan Ram)
>   19. Re: ttk.Notebook Tabs Question (Abdur-Rahmaan Janhangeer)
>   20. Re: Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?" (Terry Reedy)
>   21. Re: Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?" (Chris
> Angelico)
>   22. Re: Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?" (Terry Reedy)
>   23. Re: Old Man Yells At Cloud (Gregory Ewing)
>   24. Re: Old Man Yells At Cloud (Gregory Ewing)
>   25. Re: Old Man Yells At Cloud (mm0fmf)
>   26. Re: Old Man Yells At Cloud (Steve D'Aprano)
>   27. Re: Research paper "Energy Efficiency across Programming
>   Languages: How does energy, time, and memory relate?" (Steve
> D'Aprano)
>   28. Re: Which database system? (Amirouche Boubekki)
>   29. Typo-squatting PyPi (Alain Ketterlin)
>   30. Re: Old Man Yells At Cloud (Leam Hall)
>   31. Re: Old Man Yells At Cloud (Abdur-Rahmaan Janhangeer)
>   32. speech_to_text python command not working (pizza python)
>   33. Re: Old Man Yells At Cloud (Leam Hall)
>   34. Re: Old Man Yells At Cloud (Chris Angelico)
>   35. Python built-ins versus Javascript [was Re: Old Man Yells At
>   Cloud] (Steve D'Aprano)
>   36. Re: Old Man Yells At Cloud (Steve D'Aprano)
>   37. Unicode (was: Old Man Yells At Cloud) (Leam Hall)
>   38. Re: Unicode (was: Old Man Yells At Cloud) (Paul Moore)
>   39. Re: Unicode (was: Old Man Yells At Cloud) (Chris Angelico)
>   40. Re: Unicode (Leam Hall)
>   41. Re: Old Man Yells At Cloud (Steve D'Aprano)
>   42. Re: Unicode (Peter Otten)
>
>
> -- Forwarded message --
> From: Dennis Lee Bieber <wlfr...@ix.netcom.com>
> To: python-list@python.org
> Cc:
> Bcc:
> Date: Sat, 16 Sep 2017 12:52:59 -0400
> Subject: Re: Old Man Yells At Cloud
> On Sat, 16 Sep 2017 09:59:43 -0500, Tim Daneliuk <i...@tundraware.com>
> declaimed the following:
>
>
>
> >Well, the whole integer floor division thing years ago was the beginning
> >of the end - Python was doomed ...
>
> Yes -- that would give me fits if I were using Python3 currently...
> Since so many of the languages I've learned over the past years use the
> concept integer / integer => integer_result
>
> Come to think of it -- wasn't there a post from someone (seems to
> expired or been filtered from my client) asking for help with some sorting
> program... I'm pretty sure the partitioning logic would croak on Python3
> due to floating point results in the slice indices:
>
> pA = part[:n/2]
> pB = part[n/2:]
>
> --
> Wulfraed Dennis Lee Bieber A

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[alister via Python-list]

On Wed, 20 Sep 2017 14:14:24 +0100, Paul Moore wrote:

> On 20 September 2017 at 13:58, alister via Python-list
>  wrote:
>> On Tue, 19 Sep 2017 14:40:17 -0400, leam hall wrote:
>>
>>> On Tue, Sep 19, 2017 at 2:37 PM, Stephan Houben <
>>> stephan...@gmail.com.invalid> wrote:
>>>
 Op 2017-09-19, Steven D'Aprano schreef :

 > There is a significant chunk of the Python community for whom "just
 > pip install it" is not easy, legal or even possible. For them, if
 > its not in the standard library, it might as well not even exist.

 But numpy *is* in the standard library, provided you download the
 correct version of Python, namely the one from:

 https://python-xy.github.io/

 Stephan


>>> Many of us can't pip install; it's in the OS supplied vendor repo or
>>> it doesn't go on the machines.
>>>
>>> Leam
>>
>> dnf install 
>> or apt_get install 
>>
>> most of the mainstream modules seem to be there (certainly numpy)
> 
> You're missing the point. A significant number of Python users work on
> systems where:
> 
> 1. They have no admin rights 2. Their corporate or other policies
> prohibit installing 3rd party software without approval that is
> typically difficult or impossible to get 3. Quite possibly the system
> has no network access outside of the local intranet 4. The system admins
> may not be able or willing to upgrade or otherwise modify the system
> Python
> 
> Writing code that works only with stdlib modules is basically the only
> option in such environments.
> 
> Having said that, I don't advocate that everything be in the stdlib
> because of this. A lot of things (such as numpy) belong as 3rd party
> packages. But that doesn't mean that "get XYZ off PyPI" (or "install XYZ
> alternative Python distribution/version") is a viable solution to every
> problem.
> 
> Paul

not missing the point you said previously "it's in the OS supplied vendor 
repo or it doesn't go on the machines."

dnf/yum or apt_get install form the "vendor supplied repo"

I fully understand that even this may require various hoops to be jumped 
through before it can happen



-- 
Minnie Mouse is a slow maze learner.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[Paul Moore]

On 20 September 2017 at 13:58, alister via Python-list
 wrote:
> On Tue, 19 Sep 2017 14:40:17 -0400, leam hall wrote:
>
>> On Tue, Sep 19, 2017 at 2:37 PM, Stephan Houben <
>> stephan...@gmail.com.invalid> wrote:
>>
>>> Op 2017-09-19, Steven D'Aprano schreef >> pearwood.info>:
>>>
>>> > There is a significant chunk of the Python community for whom "just
>>> > pip install it" is not easy, legal or even possible. For them, if its
>>> > not in the standard library, it might as well not even exist.
>>>
>>> But numpy *is* in the standard library, provided you download the
>>> correct version of Python, namely the one from:
>>>
>>> https://python-xy.github.io/
>>>
>>> Stephan
>>>
>>>
>> Many of us can't pip install; it's in the OS supplied vendor repo or it
>> doesn't go on the machines.
>>
>> Leam
>
> dnf install 
> or
> apt_get install 
>
> most of the mainstream modules seem to be there (certainly numpy)

You're missing the point. A significant number of Python users work on
systems where:

1. They have no admin rights
2. Their corporate or other policies prohibit installing 3rd party
software without approval that is typically difficult or impossible to
get
3. Quite possibly the system has no network access outside of the local intranet
4. The system admins may not be able or willing to upgrade or
otherwise modify the system Python

Writing code that works only with stdlib modules is basically the only
option in such environments.

Having said that, I don't advocate that everything be in the stdlib
because of this. A lot of things (such as numpy) belong as 3rd party
packages. But that doesn't mean that "get XYZ off PyPI" (or "install
XYZ alternative Python distribution/version") is a viable solution to
every problem.

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[alister via Python-list]

On Tue, 19 Sep 2017 14:40:17 -0400, leam hall wrote:

> On Tue, Sep 19, 2017 at 2:37 PM, Stephan Houben <
> stephan...@gmail.com.invalid> wrote:
> 
>> Op 2017-09-19, Steven D'Aprano schreef > pearwood.info>:
>>
>> > There is a significant chunk of the Python community for whom "just
>> > pip install it" is not easy, legal or even possible. For them, if its
>> > not in the standard library, it might as well not even exist.
>>
>> But numpy *is* in the standard library, provided you download the
>> correct version of Python, namely the one from:
>>
>> https://python-xy.github.io/
>>
>> Stephan
>>
>>
> Many of us can't pip install; it's in the OS supplied vendor repo or it
> doesn't go on the machines.
> 
> Leam

dnf install 
or
apt_get install 

most of the mainstream modules seem to be there (certainly numpy)



-- 
Kliban's First Law of Dining:
Never eat anything bigger than your head.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[leam hall]

On Tue, Sep 19, 2017 at 2:37 PM, Stephan Houben <
stephan...@gmail.com.invalid> wrote:

> Op 2017-09-19, Steven D'Aprano schreef  pearwood.info>:
>
> > There is a significant chunk of the Python community for whom "just pip
> > install it" is not easy, legal or even possible. For them, if its not in
> > the standard library, it might as well not even exist.
>
> But numpy *is* in the standard library, provided you download the
> correct version of Python, namely the one from:
>
> https://python-xy.github.io/
>
> Stephan
>
>
Many of us can't pip install; it's in the OS supplied vendor repo or it
doesn't go on the machines.

Leam
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[Stephan Houben]

Op 2017-09-19, Steven D'Aprano schreef :

> There is a significant chunk of the Python community for whom "just pip 
> install it" is not easy, legal or even possible. For them, if its not in 
> the standard library, it might as well not even exist.

But numpy *is* in the standard library, provided you download the
correct version of Python, namely the one from:

https://python-xy.github.io/

Stephan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[Terry Reedy]

On 9/16/2017 7:04 PM, breamore...@gmail.com wrote:

I thought some might find this 
https://sites.google.com/view/energy-efficiency-languages/ interesting.


By 'energy', they only mean electricity, not food calories. This is the 
email I sent to the authors.

---

As a two-decade user of Python, I was interested to read your paper. 
Unfortunately, it is deeply flawed with respect to Python in the sense 
that your conclusions are inapplicable to real-world usage of Python.


The problem is your use of the Computer Language Benchmark Game.  As the 
name says, it is a *game*.  As a game, it has artificial rules dictated 
by the game masters.  It uses toy problems, and for Python, the rules 
dictate unrealistic toy solutions.  In particular, it appears to 
disallow use of 'import' with 3rd-party modules, whereas real-world 
Python is expected to use them, and nearly always does.


The particular crippler for CLBG problems is the non-use of numpy in 
numerical calculations, such as the n-body problem.  Numerical python 
extensions are over two decades old and give Python code access to 
optimized, compiled BLAS, LinPack, FFTPack, and so on.  The current one, 
numpy, is the third of the series.  It is both a historical accident and 
a continuing administrative convenience that numpy is not part of the 
Python stdlib.  However, it is easily installed from the PSF-maintained 
repository (python -m pip install numpy), and is included with most 
third-party distributions of Python.


The numerical extensions have been quasi-official in the sense that at 
least 3 language enhancements have been make for their use.  Nearly all 
real-world scientific, financial, and neural-network Python programs are 
build on top of numpy.  When a Python program spend 95% of the time in 
the optimized compiled C routines, it is nearly as fast as a 100% C 
solution.  The reason people use Python instead of C for the other 5% is 
to save human time.


Even when it come to executing the pure Python solutions, the CLBG rules 
apparently require the slowest execution possible. Execution would be at 
least 2 to 5 times faster if compilation to machine code were allowed, 
either before or during execution.  But the point of the game is to 
provide a 'level' playing field for competition between Python 
programmers, even if the cost is to cripple comparison with other 
language solution.


Terry Jan Reedy




--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[Ian Kelly]

On Sat, Sep 16, 2017 at 8:01 PM, Steve D'Aprano
 wrote:
> On Sun, 17 Sep 2017 09:04 am, breamore...@gmail.com wrote:
>
>> I thought some might find this
>> https://sites.google.com/view/energy-efficiency-languages/ interesting.
>
> "Made with the new Google Sites, an effortless way to create beautiful sites."
>
> More like an effortless way to create a complete dog's breakfast. Once upon a
> time, web sites would degrade gracefully. If something interrupted the page
> loading, or something wasn't quite right, or you'd still get something usable.
> Now, if the tiniest thing goes wrong, you get a junk.
>
> I've tried to see the results, but I just get a bunch of broken images :-(
>
>
> On the linked page, starting from the top and scrolling down, I see:
>
> - about two screens worth of black white space;
>
> - followed by three giant black horizontal bars, each one about an inch high;
>
> - more white space;
>
> - what looks like something that was intended to be a side-bar, containing:
>
> SLE'17
> Home
> Results
> Setup
> More
>
> - a giant down-pointing arrowhead, about three inches tall, which turns
>   grey when you mouse-over it but doesn't do anything when clicked;
>
> - three more links:
>
> Home
> Results
> Setup
>
>   which disappear when you mouse-over them;
>
> - finally some content!
>
> The tools and graphical data pointed by this page are included in the
> research paper "Energy Efficiency across Programming Languages: How does
> Energy, Time and Memory Relate?", accepted at the International Conference
> on Software Language Engineering (SLE)
>
> [1] Measuring Framework & Benchmarks
> [2] Complete Set of Results
> [3] Setup
> [4] Paper
>
>
>   where the last four bits are links;
>
> - the smug, self-congratulatory comment quoted above about "beautiful sites";
>
> - a button "Create a site"
>
> - What was presumably intended to be a link, but is actually just a piece of
>   plain text: "Report abuse";
>
> - more whitespace;
>
> - and finally a giant blue "i", pointed at the bottom, and slanted at 45
>   degrees. Presumably a logo for somebody or something.
>
>
> And yes, I am allowing scripts from Google and Gstatic to run, and the page is
> still broken.

It looks fine to me.


> Including the hyperlinks, that's about 700 bytes of actual content. Let's 
> double
> it for the overhead of HTML over plain text, so somewhat less than 1.5 KiB of
> content.
>
> The actual page is 27285 bytes or over 26 KiB. That gives us something with a
> useful content to bloat factor of 1:17, and *the page still doesn't work.*
>
> And that's not even counting any additional files the page requires, like CSS,
> external javascript files, images, ads, web-bugs, etc. You want to know why
> browsing the web today on full ADSL or faster speeds is *slower* than using a
> dial up modem in the 1990s? This is why.
>
> www.antipope.org/charlie/blog-static/2008/05/why_your_internet_experience_i.html
>
> Nine years later, and the problem is worse, not better.

If you're using a cell phone over 2G, then I tentatively agree. But on
my laptop over WiFi, this page that you're complaining about loaded in
783 ms when I tried it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Research paper "Energy Efficiency across Programming Languages: How does energy, time, and memory relate?"

[Steve D'Aprano]

On Sun, 17 Sep 2017 09:04 am, breamore...@gmail.com wrote:

> I thought some might find this
> https://sites.google.com/view/energy-efficiency-languages/ interesting.

"Made with the new Google Sites, an effortless way to create beautiful sites."

More like an effortless way to create a complete dog's breakfast. Once upon a
time, web sites would degrade gracefully. If something interrupted the page
loading, or something wasn't quite right, or you'd still get something usable.
Now, if the tiniest thing goes wrong, you get a junk.

I've tried to see the results, but I just get a bunch of broken images :-(


On the linked page, starting from the top and scrolling down, I see:

- about two screens worth of black white space;

- followed by three giant black horizontal bars, each one about an inch high;

- more white space;

- what looks like something that was intended to be a side-bar, containing:

SLE'17
Home
Results
Setup
More

- a giant down-pointing arrowhead, about three inches tall, which turns
  grey when you mouse-over it but doesn't do anything when clicked;

- three more links:

Home
Results
Setup

  which disappear when you mouse-over them;

- finally some content!

The tools and graphical data pointed by this page are included in the
research paper "Energy Efficiency across Programming Languages: How does
Energy, Time and Memory Relate?", accepted at the International Conference
on Software Language Engineering (SLE)

[1] Measuring Framework & Benchmarks
[2] Complete Set of Results
[3] Setup
[4] Paper


  where the last four bits are links;

- the smug, self-congratulatory comment quoted above about "beautiful sites";

- a button "Create a site"

- What was presumably intended to be a link, but is actually just a piece of
  plain text: "Report abuse";

- more whitespace;

- and finally a giant blue "i", pointed at the bottom, and slanted at 45
  degrees. Presumably a logo for somebody or something.


And yes, I am allowing scripts from Google and Gstatic to run, and the page is
still broken.


Including the hyperlinks, that's about 700 bytes of actual content. Let's double
it for the overhead of HTML over plain text, so somewhat less than 1.5 KiB of
content.

The actual page is 27285 bytes or over 26 KiB. That gives us something with a
useful content to bloat factor of 1:17, and *the page still doesn't work.*

And that's not even counting any additional files the page requires, like CSS,
external javascript files, images, ads, web-bugs, etc. You want to know why
browsing the web today on full ADSL or faster speeds is *slower* than using a
dial up modem in the 1990s? This is why.

www.antipope.org/charlie/blog-static/2008/05/why_your_internet_experience_i.html

Nine years later, and the problem is worse, not better.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list