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

Groups > comp.lang.python > #92921 > unrolled thread

HOPE: A Python just-in-time compiler for astrophysical computations

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

Contents

  HOPE: A Python just-in-time compiler for astrophysical computations Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-21 01:29 +0100
    Re: HOPE: A Python just-in-time compiler for astrophysical computations BartC <bc@freeuk.com> - 2015-06-21 10:29 +0100
      Re: HOPE: A Python just-in-time compiler for astrophysical computations Laura Creighton <lac@openend.se> - 2015-06-21 15:43 +0200
    Re: HOPE: A Python just-in-time compiler for astrophysical computations Laurent Pointal <laurent.pointal@free.fr> - 2015-06-23 18:53 +0200
      Re: HOPE: A Python just-in-time compiler for astrophysical computations Michael Torrie <torriem@gmail.com> - 2015-06-26 11:32 -0600
      Re: HOPE: A Python just-in-time compiler for astrophysical computations Stefan Behnel <stefan_ml@behnel.de> - 2015-06-28 09:31 +0200
        Re: HOPE: A Python just-in-time compiler for astrophysical computations wxjmfauth@gmail.com - 2015-06-29 00:19 -0700

#92921 — HOPE: A Python just-in-time compiler for astrophysical computations

Another beasty I've just stumbled across which you may find interesting 
http://www.sciencedirect.com/science/article/pii/S2213133714000687

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

[toc] | [next] | [standalone]

#92947

On 21/06/2015 01:29, Mark Lawrence wrote:
> Another beasty I've just stumbled across which you may find interesting
> http://www.sciencedirect.com/science/article/pii/S2213133714000687

Blimey, that's a lot of waffle in there, but I suppose that's to be 
expected from a published paper.

I think the gist of it is, that you highlight specific Python functions 
that you need to be fast (add a decorator), then it tries to translate 
those into actual C++ by inferring types. All done transparently at 
runtime (although I imagine it would be hard to hide the huge machinery 
of a C++ compiler in action).

The benchmarks seem to be individual functions which it presumably 
successfully translated fully into C++, so it is effectively comparing 
CPython to C++.

It also puts in a good dig at PyPy by including one benchmark where it 
is 6 times as slow as CPython!

It's not clear why it's particularly useful for astrophysics.

-- 
Bartc

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

#92958

In a message of Sun, 21 Jun 2015 10:29:32 +0100, BartC writes:
>It also puts in a good dig at PyPy by including one benchmark where it 
>is 6 times as slow as CPython!
>
>It's not clear why it's particularly useful for astrophysics.
>
>-- 
>Bartc

It's not that good a dig, as they say that it took less than 1 second
to run most of their benchmarks, which mostly means that the PyPy JIT
won't have started to run anyway.  One can argue that HOPE isn't
actually a method JIT at all -- or if it is one, then so is Cython.

Laura

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

#93042

Mark Lawrence wrote:

> Another beasty I've just stumbled across which you may find interesting
> http://www.sciencedirect.com/science/article/pii/S2213133714000687
 
Why use a JIT complation when you could use some C++ generation then 
compilation as Python module, like with Pythran ?

https://github.com/serge-sans-paille/pythran

For heavy computing, you may loose some time before running computation, to 
have (generate) the right tool, then do the job with real bonus.

…
A+
Laurent.

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

#93199

On 06/23/2015 10:53 AM, Laurent Pointal wrote:
> Mark Lawrence wrote:
> 
>> Another beasty I've just stumbled across which you may find interesting
>> http://www.sciencedirect.com/science/article/pii/S2213133714000687
>  
> Why use a JIT complation when you could use some C++ generation then 
> compilation as Python module, like with Pythran ?
> 
> https://github.com/serge-sans-paille/pythran
> 
> For heavy computing, you may loose some time before running computation, to 
> have (generate) the right tool, then do the job with real bonus.

Not really. I suspect Hope caches the compiled subroutine so only the
very first running of the function on the very first execution of the
pthon program will be slow.  After that, the program will run quickly
each time.  It's a pretty good idea.

I've never heard of pythran; I'll have to check it out and see how it
compares to the ever-growing crop of Python dialect compilers.  Cython
could be used in a similar way as you suggest, and in PyPy we have the
RPython dialect that compiles to C.

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

#93268

Michael Torrie schrieb am 26.06.2015 um 19:32:
> I've never heard of pythran; I'll have to check it out and see how it
> compares to the ever-growing crop of Python dialect compilers.

My feeling is that Python seems such a simple language at the surface that
people who want to write a special purpose "Python subset" compiler prefer
starting from scratch, rather than contributing to the existing tools. It
takes a while until they understand the actual size of that undertaking and
that's the point where most of these projects just die.

I don't mean all of them. If you have enough time and/or money, you can
certainly get a project going that's relevant enough for a critical
(special purpose) user base to provide an actual benefit. But then, why
invest that time into something completely new that requires major
long-term maintenance efforts, when implementing the desired feature in an
existing compiler would be a one-time investment with a much smaller
overall impact on further maintenance costs?

Not Invented Here Syndrome, I guess...

Stefan

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

#93284

Le dimanche 28 juin 2015 09:32:09 UTC+2, Stefan Behnel a écrit :
> Michael Torrie schrieb am 26.06.2015 um 19:32:
> > I've never heard of pythran; I'll have to check it out and see how it
> > compares to the ever-growing crop of Python dialect compilers.
> 
> My feeling is that Python seems such a simple language at the surface that
> people who want to write a special purpose "Python subset" compiler prefer
> starting from scratch, rather than contributing to the existing tools. It
> takes a while until they understand the actual size of that undertaking and
> that's the point where most of these projects just die.
> 
> I don't mean all of them. If you have enough time and/or money, you can
> certainly get a project going that's relevant enough for a critical
> (special purpose) user base to provide an actual benefit. But then, why
> invest that time into something completely new that requires major
> long-term maintenance efforts, when implementing the desired feature in an
> existing compiler would be a one-time investment with a much smaller
> overall impact on further maintenance costs?
> 
> Not Invented Here Syndrome, I guess...
> 
> Stefan

There are even people who naively tried to reinvent
"Unicode", without seeing they failed.

Simply unbelievable.

jmf

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web