3 ms·

> I find it laughable that any article about de-throning FORTRAN barely even makes a passing reference to Python Python is just glue. It's not possible to do a

by whyenot 12y ago

> I find it laughable that any article about de-throning FORTRAN barely even makes a passing reference to Python 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.

pwang 12y ago
There is work underway to bridge this gap. The fundamental bet by my company is actually basically the same one that Julia makes: higher level languages combined with dynamic compilation are the only route to performance in our modern world of heterogeneous hardware. 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.

by whyenot 12y ago

pwang 12y ago

There is work underway to bridge this gap. The fundamental bet by my company is actually basically the same one that Julia makes: higher level languages combined with dynamic compilation are the only route to performance in our modern world of heterogeneous hardware. 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.