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).
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.
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.
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.
This precisely what I would a physicist expect to do, Cern has >16 million lines of C++ and you can be sure that the analysis code written by non-programmers barely works and not nescessarily uses sane programming principles.
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
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.
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.
Does anybody know how this compares performance-wise to Numba (http://numba.pydata.org/) which seems like a pretty similar effort? Numba translates to LLVM bytecode rather than C++.
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.
The numerical python ecosystem is definitely improving, but it's getting pretty complicated, particularly when heterogeneous architectures factor into your work flow.
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.
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.
Based on the description in the docs (http://pythonhosted.org/hope/lang.html#loops), my guess is that "for i in range(N)" is directly translated into something like "for (i = 0; i < N; i++)" in the C++.
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?
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.
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.
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).