Scientific computing’s future: Can any coding language top a 1950s behemoth?
arstechnica.com
arstechnica.com
We won't solve tomorrow's problems with yesterday's perspective. Efficiency of compute is only one portion of the problem, and so much of the article fixates on things close to the machine, instead of recognizing that the real barrier to innovation in scientific computing is computational literacy among scientists.
IMHO, Haskell and Clojure are DOA in this regard. They may be great for software developers, but not so much for geneticists and astrophysicists and nuclear chemists. Python's language, libraries, and community ethos are a very compelling mix, and have already crossed the chasm into the "mainstream" of scientific computing, even if it's still early days.
"So was this just a commissioned piece on Julia?"
No.
"Julia is a very interesting new development"
I agree, and that's why I wanted to write about it.
On Python: I've used it, with Numpy, etc., plenty for analysis of simulation results. But you don't run a slow interpreted language on massive supercomputers to simulate the atmosphere. I hope you understand the different kinds of things referred to by the term "scientific computing".
The term "scientific computing" is evolving very rapidly and I thought a recent HN post
https://news.ycombinator.com/item?id=7692200
did a nice job of describing the differences between two major camps that are starting to take shape. To paraphrase and stereotype: one is steeped in MPI and Fortran/C/C++; the other prefers MapReduce.
Julia isn't going to trounce expert MPI implementations designed to squeeze every last flop from their computations, but we do hope that Julia will be a tool that can both interoperate nicely with existing HPC codes and yet be useful to write new code in.
Plug: I'm organizing an upcoming workshop at SC'14 designed to address scalability issues in high level dynamic languages, including (but not limited to) Julia, Python and R, and hope that anyone who's interested in this emerging area of nontraditional HPC to participate.
Python is just glue. It's not possible to do any numerical heavy lifting in python. Numpy and Scipy are not written in python, all the important stuff is written in C and/or Fortran. Same goes for R. It's a great language for exploratory programming, thanks to the REPL, but all the heavy lifting is not done in R, it's done in another language. Python will never displace Fortran or C for numerical code. It may replace another language (R, Matlab, ...) for the user interface. The power of Julia and to a lesser extent Clojure and Haskell is that they have got both the wonderfully interactive REPL and can do the heavy work that is traditionally done in Fortran / C. Common Lisp is another possibility, but it already had its day in the sun.
My company sells a Python-to-GPU and Python-to-x86 compiler. It matches or beats hand-rolled C and C++ for some cases, and is loads easier to deal with when it comes to CUDA work. It's still in its infancy, but the approach (in my mind) is definitely validated.
If you think about it, why should C be the speed king? Most programmers cannot reason about cache coherency to save their lives and that's the dominant performance cost for real performance. Many of the big numerical codes follow some high level patterns of data movement; if a compiler has greater visibility into the structure of both the data and the algorithm, it has an easier time parallelizing and optimizing, than if it has to rely on the programmer to "lower" the algorithm to a layer that's just a hair above RTL. "C is just portable assembly" and all that.
Additionally, FWIW, if you really want to pick nits, a lot of NumPy is actually not written in C, but rather a custom macro template system which then creates C code for each of the core types (int8, uint8, int16, etc. etc.). So even for the low-level guts, code generation (albeit a very simple mechanism) is the current approach.