Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pythran: Crossing the Python Frontier [pdf]

computer.org

Post reply on HN
Print view View original

61–70 of 70 posts

Re: Pythran: Crossing the Python Frontier [pdf]

#61

Post by gnufx »

ianamartin wrote: post #27
cbcoutinho wrote: post #15

Earlier quoted context omitted.

Scientific work should strive to be functional by definition (identical input == identical output), so I could see why a programing language should reflect that.

That's a pretty broad statement. And it's a goal that a lot of scientific work simply doesn't allow for. Any stochastic process will have variability for a given set of inputs. I think there are more fields within the umbrella of Science where purely functional programming isn't an achievable ideal--let alone a desirable one--than there are where this is a good fit. You can make the argument that all programming shou…

What are these fields in which you can't use functional programming and it isn't desirable? (It's true there should be more engineering done on implementations of scientific stuff.) I've seen how unnatural imperative programming was to physicists who hadn't been exposed to it.

Re: Pythran: Crossing the Python Frontier [pdf]

#62

Post by gnufx »

zb wrote: post #42
AnimalMuppet wrote: post #38

Off topic, but this seems like as good a place as any to ask: It's my impression that numpy is really good. Is it as good as Fortran? That is, if I have a large, sparse, complex matrix, Fortran will have an efficient solver for it that will also be numerically stable, and will have four decades of use to find any weaknesses. Is numpy equivalent (except for the four decades part)? Is it close? Or does it just cover th…

NumPy is designed to work with SciPy, which is a wrapper for literally the same 4 decade old Fortran libraries (LAPACK &c.) that you're referring to here.

Note that LAPACK isn't four decades old (and probably should be superseded anyway). You perhaps won't want to use large-scale numerical libraries that are that old unless they've had a lot of development and been well parallelized.

One issue with mixed language programming that we learned decades ago is the issue of debugging that there typically is across the interface. Also general tool support. I recently asked the local Python expert about HPC-style profiling of Python calling C(++) libraries, for instance. (I couldn't make TAU work.)

Re: Pythran: Crossing the Python Frontier [pdf]

#63

Post by targafarian »

Claims about Numba by the author seem a little unkind if not wrong to me.

Numba can handle vectorized (numpy behavior) directly in addition to explicit loops. The former is accelerated less in comparison to plain python calling numpy (since if you can use numpy operations directly, it's already really fast) but the numpy bits in Numba can also be automatically parallelized by Numba. Explicit loops in numba are accelerated hundreds of times over Python loops (and you can use e.g. prange to write parallel loops, too). Point is, the two paradigms can be mixed and matched at will within Numba.

It seems like every example is of cython, but then the author generalizes the conclusions to Numba as well. It would be much more "honest" to show side-by-side comparison of Numba, Cython, and Pythran, since these all have different syntaxes and are fairly different tools.

Another example is that you don't have to rewrite functions for different argument types in Numba, but you do in Cython (see "convolve_laplacian" example, which can work with a simple decorator as a numba function). There again, the impression is given that Numba suffers from the same issue as Cython (and as mentioned elsewhere in the comments here, it's possible that Cython has a way around this, but I don't know the details).

Re: Pythran: Crossing the Python Frontier [pdf]

#64

Post by targafarian »

geoalchimista wrote: post #56

> "As a matter of comparison, Cython does not support principles 1, 2, or 3 and has optional support for 4." For 2 Type agnosticism , this can be emulated with a "fused type" in Cython. See this example: http://cython.readthedocs.io/en/latest/src/userguide/numpy_t... But I think the major inconvenience with Cython vectorization is really not about `float32` and `float64`. You get `float64` NumPy array by default from…

Note that the alternative in Numba is incredibly convenient, where you can trivially create a function where the body of the function operates on a scalar, but then using the @vectorize decorator which makes it into a numpy ufunc automatically. This generalizes the function to operate equally well on scalars or numpy arrays of any dimensionality (just like "built-in" numpy functions do).

Oh, and if you use set target='gpu', your function also works on GPUs, too. Or you can use target='parallel' to make it parallelize automatically across CPU cores.

Re: Pythran: Crossing the Python Frontier [pdf]

#65

Post by targafarian »

kwertzzz wrote: post #55
evrydayhustling wrote: post #47

Earlier quoted context omitted.

In research programming, you often spend as much or more time in data acquisition and munging than implementing core algorithms. Plus, more than in production code, the requirements change as you explore different applications and approach. And, because it's not production code, you have more opportunity to explore outputs at different stages to review function. It's effectively continual prototyping. All of these th…

I am giving a class on numerical methods and one student choose to use python (while my example code was in Julia). It was a pain to see how this student was constantly shooting himself in the foot due some particular behaviors of python and numpy. For instance the student did not expect that a list comprehension iterating over a numpy vector returns just a python vector. Also the fact that the index ranges the last…

This comment just sounds like "I know tool X well, somebody else doesn't know tool Y well, and therefore tool X is better."

To do matrix multiplication on many matrices "stacked" together in one step, use numpy.matmul: https://docs.scipy.org/doc/numpy/reference/generated/numpy.m... (and so there's no need to slice up the array, convert to matrix, etc.)

Note that the Numpy devs are trying to (if they haven't already) get rid of the "matrix" class and just use arrays, but of course dealing with legacy code is always an issue. Once that's out of the way, people won't be distracted by "matrices" to do matrix operations, and hopefully they'll see you can do matrix operations on arrays directly. (And yes, in Python 3 you can use the @ syntax to the same effect.)

Re: Pythran: Crossing the Python Frontier [pdf]

#66

Post by kwertzzz »

targafarian wrote: post #65
kwertzzz wrote: post #55

Earlier quoted context omitted.

I am giving a class on numerical methods and one student choose to use python (while my example code was in Julia). It was a pain to see how this student was constantly shooting himself in the foot due some particular behaviors of python and numpy. For instance the student did not expect that a list comprehension iterating over a numpy vector returns just a python vector. Also the fact that the index ranges the last…

This comment just sounds like "I know tool X well, somebody else doesn't know tool Y well, and therefore tool X is better." To do matrix multiplication on many matrices "stacked" together in one step, use numpy.matmul: https://docs.scipy.org/doc/numpy/reference/generated/numpy.m... (and so there's no need to slice up the array, convert to matrix, etc.) Note that the Numpy devs are trying to (if they haven't already)…

Thank you for the info about numpy.matmul. However this feels quite clumsy to use a function call for a matrix operator, especially when you have several chained. I think that this is an good move to get rid of matrix class (I just didn't find any depreciation info in the documentation, maybe this still needs some time).

I think the python language is very elegant and the principle that there should be only one obvious way to do something has served them quite well. Unfortunately, in numpy you have quite often multiple ways to do things (often in addition to python own mechanism, e.g sum, numpy.sum and the sum method). I deal with students who have little programming experience and this can be confusing. One of the reasons I choose Julia for my lectures was that these issues do not exist in Julia. Julia is quite clean and simple in this regard.

However I completely see that for an experienced programmer (or a scientist with good programming experience), this is not a problem.

But for somebody learning to solve numerical problems, it is quite helpful that Julia code tends to be closer to the mathematical formulation. In addition, for the test I made, Julia code tends to be faster than vectorized numpy code (I can share the code if there is interest). The only major argument against Julia, in my opinion, is that it is still a young language and with a small ecosystem (much smaller in fact than python or R)

Re: Pythran: Crossing the Python Frontier [pdf]

#67

Post by targafarian »

kwertzzz wrote: post #66
targafarian wrote: post #65

Earlier quoted context omitted.

This comment just sounds like "I know tool X well, somebody else doesn't know tool Y well, and therefore tool X is better." To do matrix multiplication on many matrices "stacked" together in one step, use numpy.matmul: https://docs.scipy.org/doc/numpy/reference/generated/numpy.m... (and so there's no need to slice up the array, convert to matrix, etc.) Note that the Numpy devs are trying to (if they haven't already)…

Thank you for the info about numpy.matmul. However this feels quite clumsy to use a function call for a matrix operator, especially when you have several chained. I think that this is an good move to get rid of matrix class (I just didn't find any depreciation info in the documentation, maybe this still needs some time). I think the python language is very elegant and the principle that there should be only one obvio…

I would be curious about the code you use. Numpy was natural for me after going through engineering school, where Matlab was taught from year 2 on. Again, that was a language much more focused on the numerics. But as soon as I had to do something that wasn't numerical (first job out of school, and for everything since), I learned to hate Matlab and love Python.

Anyhow, that experience surely doesn't map onto Julia, a completely different language. So I'd be curious to see what your use case is; it might give me a different perspective on Julia (which I have only played with a couple of times back when it was even younger).

Re: Pythran: Crossing the Python Frontier [pdf]

#68

Post by kwertzzz »

targafarian wrote: post #67
kwertzzz wrote: post #66

Earlier quoted context omitted.

Thank you for the info about numpy.matmul. However this feels quite clumsy to use a function call for a matrix operator, especially when you have several chained. I think that this is an good move to get rid of matrix class (I just didn't find any depreciation info in the documentation, maybe this still needs some time). I think the python language is very elegant and the principle that there should be only one obvio…

I would be curious about the code you use. Numpy was natural for me after going through engineering school, where Matlab was taught from year 2 on. Again, that was a language much more focused on the numerics. But as soon as I had to do something that wasn't numerical (first job out of school, and for everything since), I learned to hate Matlab and love Python. Anyhow, that experience surely doesn't map onto Julia, a…

Sorry for the delay, but here is an example code:

https://gist.github.com/Alexander-Barth/c8eb764f400cdb7a1eb5...

Do not hesitate to tell me if I missed something to optimize the python code. If somebody has numba, pythan,... installed, I would be interested to see the speed-up compared to the vanilla python version on your machine.

So in short, for my cases: the fastest Julia test case (with loops and avoiding unnecessary allocation) was about 10x faster than fastest python 3 test case (with vectorization).

The runtime with vectorization are relatively similar (julia is only about 25% faster than python). Explicit loop and careful memory management are clearly beneficial in Julia.

Re: Pythran: Crossing the Python Frontier [pdf]

#69

Post by ChrisRackauckas »

knlji wrote: post #24
joshsyn wrote: post #7

Isn't this solved by julia? I think scientific community should use a more functional language rather than language like python tbh

Maybe. It's currently just a safer bet to learn and use Python. Easier to get a job after you fail getting your next grant. I have so far seen zero Julia job ads. Hell, I see more e.g. Haskell and Fortran job ads than Julia.

Julia gives you such a competitive advantage that you can easily position yourself into a great career. It worked out really well for me. Of course YMMV, but having a much greater productivity and software quality never hurts.

Re: Pythran: Crossing the Python Frontier [pdf]

#70

Post by ChrisRackauckas »

kwertzzz wrote: post #68
targafarian wrote: post #67

Earlier quoted context omitted.

I would be curious about the code you use. Numpy was natural for me after going through engineering school, where Matlab was taught from year 2 on. Again, that was a language much more focused on the numerics. But as soon as I had to do something that wasn't numerical (first job out of school, and for everything since), I learned to hate Matlab and love Python. Anyhow, that experience surely doesn't map onto Julia, a…

Sorry for the delay, but here is an example code: https://gist.github.com/Alexander-Barth/c8eb764f400cdb7a1eb5... Do not hesitate to tell me if I missed something to optimize the python code. If somebody has numba, pythan,... installed, I would be interested to see the speed-up compared to the vanilla python version on your machine. So in short, for my cases: the fastest Julia test case (with loops and avoiding unnec…

The speed difference compounds as code grows in complexity. Julia compiles things together, using interprocedural optimizations and automatic type specialization. Lots of allocation saving utilities, fancy performance macros, etc. let you get very fast code. Recent testing in large applications showed that using a Numba function in a Julia code or a Python code was about 10x slower than a Julia code (here's a quick writeup: http://juliadiffeq.org/2018/04/30/Jupyter.html). We had a crew that was more experienced in Python keep trying to make it better (and lots of Julia programmers come from Python and have more experience (many more years!) with Python). 10x seemed to be the amount that Pythran, Cython, Numba was behind defining a Julia-function using pyjulia (Numba was great and easiest in comparison, so our docs kept that and dumped the others).

Moral of the story is, these Python tools are built for microbenchmarks and can do okay there, but without the full stack optimized together and without a type system that's exploitable for all of the performance tricks, it falls apart in real-world code.

Post reply on HN