Live data from Hacker News

Why I Still Use Python for High Performance Scientific Computing

nbviewer.jupyter.org

121–130 of 158 posts

Re: Why I Still Use Python for High Performance Scientific Computing

#121
post #22

This may be a liiiitle bit off-topic, but I really need to get it off my chest: Python for high-performance scientific computer works beautifully ... it's a dream. Scipy/numpy, matplotlib, pandas, ipython. They're all unbelievably awesome. It all just works. Except , when you're on Windows, and it just doesn't. Just installing things and doing the 'hello world' for aforementioned libraries is laughably impossible. So…

[deleted]

Re: Why I Still Use Python for High Performance Scientific Computing

#122
post #112
post #95

Earlier quoted context omitted.

Could you elaborate a bit on how JVM hinders reaching maximum FLOPS when multiplying sparse matrices? I could think some examples where lacking SSE/AVX support would hinder it, but I don't see the connection with sparse matrices.

What make sparse matrices harder to JIT is proving that the loop bounds will not be exceeded, so all accesses re bound checked. In any case in my experience array bounds checking and escape analysis never gave the boost that theory and JVM fans promise. So even normal matrix multiply will trail behind. That said Hotspot JVM is possibly one of the most optimized VMs we have got. A structural problem of JVM is that its…

For normal dense matrix laid out as a double[] and accessed directly as i* N_ROW + j probably won't get its loop check elided. For double[][] I would _think_ that happens more easily.

But how are sparse matrices then generally laid out? A naive approach would be some hash map, perhaps with some locality, in which I don't see JIT problems.

Re: Why I Still Use Python for High Performance Scientific Computing

#123
post #116

Earlier quoted context omitted.

> Why isn't Haskell, or any other functional language, popular for this sort of thing? Because some of the scientists doing this are bellow average programmers. Look at the author singing praises to Python while benefiting from C, Fortran and Cython. He doesn't understand that what actually matters is what's under the hood, and you want him to learn functional programming and rewrite his algorithms?

That seems very unfair. I have no reason to think the author doesn't understand that Python libraries are built on carefully written C and Fortran, and based on the article they seem to be a perfectly competent programmer.

Have you missed the title? He gives undue credit to one of the most unfit languages for HPC ever. Python is not made to be efficiently implemented, yet the author cheerfully writes "I choose to use Python for performance critical scientific computing code".

That's the unfair part right there: lying to people about the proper uses of Python.

Re: Why I Still Use Python for High Performance Scientific Computing

#124
post #4

Why isn't Haskell, or any other functional language, popular for this sort of thing? Turning A into B is what FP excels at, and you shouldn't have to reason about side effects, besides writing the graph images somewhere. From what I've heard from a friend of using other people's code in one particular scientific field (stringly type some of the things, probably accidentally, don't document this), an at-least-passable…

Not enough developer uptake for Haskell early on; quite frankly because it requires a thoughtshift that many developers find too difficult to do.

Re: Why I Still Use Python for High Performance Scientific Computing

#125
post #37
post #8

Earlier quoted context omitted.

All the points the author makes through the post are interesting, and Python is definitely great for protoyping, but I think the initial premise is false: "people don't tend to think of [Python] as a high performance language; for that you would want a compiled language -- ideally C or C++ but Java would do." Java is compiled to bytecode, but it isn't a "compiled language" since that bytecode has to be interpreted by…

"...and so a true implementation in C with the right compiler optimizations would for sure be faster than the python code." True. But this assumes that time is not a constraint. I think you need to think of it this way (as a thought experiment): you start two programmers off, one in C and one in Python, both with a vague understanding of how to solve the problem and approximately the same skill level. Then after X ho…

I've tried to do a test like this and the results surprised me. While the testing conditions weren't perfect, I tracked how much time it took to port Fortran code to C++, and how much time it took to write the C++/CUDA optimized version. I would have expected writing all the optimized CUDA kernels would add significant time to the project, but in reality it was something like 1.3x for a solution 15x faster.

I think as developers we often underestimate the amount of work we need to put into the non coding part of development for larger projects, like testing, debugging, optimization, and design. When these components become important then despite the local productivity gains of using rapid development languages like python or Julia, it would overall be a wash if you're writing the system from scratch in a language like C.

Re: Why I Still Use Python for High Performance Scientific Computing

#126
post #122
post #112

Earlier quoted context omitted.

What make sparse matrices harder to JIT is proving that the loop bounds will not be exceeded, so all accesses re bound checked. In any case in my experience array bounds checking and escape analysis never gave the boost that theory and JVM fans promise. So even normal matrix multiply will trail behind. That said Hotspot JVM is possibly one of the most optimized VMs we have got. A structural problem of JVM is that its…

For normal dense matrix laid out as a double[] and accessed directly as i* N_ROW + j probably won't get its loop check elided. For double[][] I would _think_ that happens more easily. But how are sparse matrices then generally laid out? A naive approach would be some hash map, perhaps with some locality, in which I don't see JIT problems.

There are some defacto standard formats such as CRS, CSC, list of tuples etc. Layout of the third should be obvious and it is not used much for cases where speed matters because one loses locality in this layout. For the other two they are laid out column after column (or row by row), row ids, and offsets to indicate the start and end of columns (rows).

Re: Why I Still Use Python for High Performance Scientific Computing

#127
post #70
post #63

Earlier quoted context omitted.

Let me just add Numba to the list. It compiles numpy-using code to native via llvm and can remove temporary arrays in the process. I tried a very simple toy program the other day and while I had to write some things slightly un-pythonically (it can't deal with syntax like a[:] = b+c yet), it performed practically as good as hand-written C code.

If your code falls within the subset it supports :) I've not yet got it to run our code in nopython mode - I think the latest problem is a function expecting a function as an argument, but the error messages aren't helpful or enlightening, even with DEBUG turned on.

The dev team is pretty responsive and prioritize adding features based on bug reports like this. Can you open an issue?

https://github.com/numba/numba

Re: Why I Still Use Python for High Performance Scientific Computing

#128
post #15
post #4

Why isn't Haskell, or any other functional language, popular for this sort of thing? Turning A into B is what FP excels at, and you shouldn't have to reason about side effects, besides writing the graph images somewhere. From what I've heard from a friend of using other people's code in one particular scientific field (stringly type some of the things, probably accidentally, don't document this), an at-least-passable…

Because the Python ecosystem is huge, with real scientists writing real libraries to get stuff done. The Haskell crowd seems to write monad tutorials that are either cute or unintellegible, and stratosphere-high level stuff where I wouldn't have the slightest clue what I can use them for (Arrows? Zippers?).

Haskell tends to attract people who like programming languages as programming languages. It encourages a style that's completely different from what you're taught in your basic Fortran/C/Java/Matlab course. If, like a lot of scientist, you've done a little imperative programming already, Python isn't much of a step; Haskell, at least as it is presented usually, is another bag entirely.

This means you have a much larger audience, and therefore it's more likely that someone will already have written a tool of your domain in Python.

Re: Why I Still Use Python for High Performance Scientific Computing

#129
post #94
post #57

Earlier quoted context omitted.

Actually, if you squint a lot, R (or S) is a functional language. And it shows, crazily powerful for something, absolutely horrible for something else.

No squinting needed :) "R, at its heart, is a functional programming (FP) language. This means that it provides many tools for the creation and manipulation of functions. In particular, R has what’s known as first class functions. You can do anything with functions that you can do with vectors: you can assign them to variables, store them in lists, pass them as arguments to other functions, create them inside functio…

Yeah, lots of squinting needed, or a terribly shallow understanding of FP to say that. Merely providing first-class functions and map/reduce idioms does not a functional language make. Python has those, so is it also FP really? R is as much a FP language as Haskell or OCaml are imperative "at heart."

Re: Why I Still Use Python for High Performance Scientific Computing

#130
post #22

This may be a liiiitle bit off-topic, but I really need to get it off my chest: Python for high-performance scientific computer works beautifully ... it's a dream. Scipy/numpy, matplotlib, pandas, ipython. They're all unbelievably awesome. It all just works. Except , when you're on Windows, and it just doesn't. Just installing things and doing the 'hello world' for aforementioned libraries is laughably impossible. So…

It's similar on Linux. Every time I'm trying to get some outside-written Python software to work, there are many, many troubles.

Python works fine, in your own virtualenv. Outside of it... not so much.

Post reply on HN