
Hope – A Python JIT for astrophysical computations - catkin
https://github.com/cosmo-ethz/hope
======
shoyer
Here's the doc page that lists the supported language features:
[http://pythonhosted.org/hope/lang.html](http://pythonhosted.org/hope/lang.html)

Compared to numba, it looks like hope adds: (1) support for recursion, (2)
automatic simplification of expressions using SymPy and (3) support for
arithmetic with array broadcasting (e.g., as used in their Point Spread
Function benchmark).

~~~
travisoliphant
Interesting post. It seems that everyone wants to write their own jit rather
than cooperate with the on-going open source efforts. 1) Support for recursion
is in a PR for Numba that has just not yet been merged. 2) optional
simplification of expressions using SymPy has been contemplated and is easy to
add, though it's not clear if it's the interface people will want as it slows
down compilation. 3) Numba has support for some array broadcasting via
vectorize and is getting more in the coming 6 months.

A C++ target for Numba would also be of interest if anyone wants to
participate in the development. Numba 0.15.1 was just released this week:
[https://github.com/numba/numba/tree/0.15.1](https://github.com/numba/numba/tree/0.15.1)
[http://numba.pydata.org](http://numba.pydata.org)

conda install numba

~~~
shoyer
Totally agreed, I am much more excited about Numba right now. Numba has some
really nice tricks up its sleeve -- I especially like the ability to easily
write (g)ufuncs.

There are a lot of edge cases to nail down for these JIT compilers. Everyone
writing their own is likely to end up with none of them being useful for end
users.

------
mlubin
This is an impressive job. I'm curious why the arxiv paper uses Julia's
benchmark suite but doesn't make any other mention of Julia in the discussion,
given that it's quite relevant to this work.

------
bouk
This is crazy! It actually generates C++ code on the fly by translating AST
nodes one to one [https://github.com/cosmo-
ethz/hope/blob/master/hope/_generat...](https://github.com/cosmo-
ethz/hope/blob/master/hope/_generator.py)

~~~
rurban
It's basically the same strategy rperl uses, compiling a restricted and typed
subset of perl5 to C++11 on the fly, via Inline::CPP
[http://rperl.org](http://rperl.org)

I wouldn't call that JIT, because the term JIT is normally used for direct
compilation to machine code, and all those other compile-to-c|c++-on-the-fly
languages don't call it JIT neither.

~~~
acqq
I'm sure clicked the upvote, but your comment is gray now. :( Please, other
readers, try to correct, upvoting the parent comment! It's a good comment, and
it deserves to be upvoted. I can't do anything more. Thanks.

Edit: I've found the culprit: believe or not, the older Opera browser can have
the "down" linked area in the middle of the up arrow! On the same hight (same
Y) just changing the X position of the mouse will change between the UP and
DOWN vote! The down vote area extends from the down arrow up to the top of the
up arrow(!) and is of the same width (a few pixels at most). Weird. I must
avoid that browser for HN.

[http://s4.postimg.org/nyec1bmvh/badlink.jpg](http://s4.postimg.org/nyec1bmvh/badlink.jpg)

Anybody knows how this is possible?

------
pbrook
Does anybody know how this compares performance-wise to Numba
([http://numba.pydata.org/](http://numba.pydata.org/)) which seems like a
pretty similar effort? Numba translates to LLVM bytecode rather than C++.

~~~
travisoliphant
The performance numbers they show are fairly cherry-picked and are not really
showing a broad-based comparison of Numba's capability. In addition, Numba is
still under active development and the version they used is a few versions
older than released. Still it's good to have use-cases and examples which
drive Numba improvements.

------
radikalus
Looks quite ambitious. (And cool)

The numerical python ecosystem is definitely improving, but it's getting
pretty complicated, particularly when heterogeneous architectures factor into
your work flow.

------
mborch
Assuming this is Python 2.x (doesn't seem to be specified in the benchmark
results), then the use of "range" is problematic (should be "xrange").

~~~
MrMeker
Not really. "range" returns a list, "xrange" returns an iterator. I assume
that the list is much easier to reason about in a JIT. In python3, range is a
type of its own and certainly more useful for in a JIT.

[https://docs.python.org/3/library/stdtypes.html#typesseq-
ran...](https://docs.python.org/3/library/stdtypes.html#typesseq-range)

[https://docs.python.org/2/library/functions.html#range](https://docs.python.org/2/library/functions.html#range)

~~~
mborch
How is allocating and populating a Python list order to do a simple for loop
in a tight inner loop not problematic? Neither CPython nor PyPy can optimize
that out.

As I said, this is assuming we're on Python 2.x.

~~~
rguillebert
PyPy optimizes that out, you have a thing that looks exactly like a list, but
is implemented differently under the hood

------
fsloth
Looks really nice! Is there any simple recipe built in to parallellize array
operations over n threads or does the user need to provide ones own
parallellization scheme?

------
srean
I found it interesting to note that one of their use case is numerical
integration. As of now Hope does method by method JIT. Numerical integration
is one of those things where just "method by method" JIT leaves substantial
room for improvement. It is the poster child used to showcase the strength of
Stalin, the lisp compiler that substantially outperforms numerical integrator
written in C. The main feature that Stalin uses to achieve that impressive
performance is inlining of the function that needs to be integrated, right
into the integration code. Such inlining is hard to do when code reside in
separate compilation unit, separate functions and loaded dynamically,
especially when the caller is only aware of a function pointer and not much
else. The later the integration routine is compiled, more chance would there
be for the compiler to know more about the function pointer, and JIT could
potentially help a lot here.

It is indeed possible to do these inlining in C++ using its template machinery
but it seems Hope does not to this yet. I am really curious about what Hope
does and what plans do they have for the future. Inlining does give huge
speedup for this application, more so if one is performing multidimensional
numeric integration.

Another thing that I was curious about was how does Hope optimize away the
dynamic semantics of Python. If one where to isolate one aspect of Python that
makes it ridiculously hard to speed it up, it is its dynamic nature. It seems
that Hope removes the dynamic aspect by analyzing the AST of the Python code.
Since Python was never intended to be type inferred, it surely poses a
substantial obstacle. I wonder whether Hope devs intend to add the Cython
functionality of selectively removing dynamic nature of specific functions via
annotations. Given the difficulty of automatic static typing of a piece of
Python code, any little help afforded to the compiler should go a long way.

The other thing that I am really curious about is what does Hope do about
Numpy vector expressions. Cython for example calls back into Numpy, so there
is not much speed benefit to be had. In fact if this is being done in a loop,
this hurts performance because of the overhead of the call. So if one really
wants performance one needs to write the low level indexing code in the Cython
syntax. I think it is a matter of personal taste, but if I were to write low-
level C,C++; I would rather write it in C,C++ itself. The latter has the
additional benefit of mature toolchains that target C, C++.

Finally, a number of tools aimed at similar use cases have been mentioned in
the post and in the comments. I will add a shout out for copperhead. It
isolates a subset of Python over which one can define a ML like semantics
which is then used to aid compilation and parallelization, all hiding behind
the familiar python syntax.

~~~
yummyfajitas
Just a note - if this use case is important, I've observed that Julia will
often properly inline numerical integrals - even some fairly tricky ones. But
you do generally have to make sure your loops are striding the quadrature in
the memory correct order - Julia doesn't seem to reorder them.

 _I wonder whether Hope devs intend to add the Cython functionality of
selectively removing dynamic nature of specific functions via annotations._

You should definitely look at Julia.

