Hacker News Reader

Comment by tjl | Hacker News Reader

It's still faster than the alternatives. Things like Scipy/Numpy are more alternatives to Matlab as is R. Julia isn't fast enough yet. C/C++ doesn't have the built-in matrix/vector support. The latter is what I ran into when I was coding for my Master's thesis, so I just gave up and went with Fortran. For my PhD, I used Matlab as the speed wasn't an issue.

There's also issues with wanting to use the old Fortran code in new projects and if the new alternatives don't have a good interface for Fortran, it's a bit of a pain to integrate.

View on HN

At least for me, Julia's fast enough in most cases. I switched from C/C++ to Julia for all of my scientific work, and it runs fine, even on a supercomputer like Titan (barring something that requires thousands of nodes at once — MPI is not yet integrated into Julia). You just have to be careful in the tight inner loops and check the assembly that it outputs using code_native().

Granted, there's plenty of fast libraries written in C/Fortran that don't have a Julia equivalent yet, and depending on the overhead of ccall(), you may wish to stick with writing the rest of your code in the language of the library.

Good to know. I've been looking at it, but not seriously. It's been more keeping an eye on it. I was hoping that Fortress would go somewhere, but it died.

My other problem is code generation. I can't generate Julia code yet.

> My other problem is code generation. I can't generate Julia code yet.

Perhaps I am misunderstanding your meaning here, but Julia has a range of metaprogramming functionality including both Lisp-like macros, as well as "generated functions" that allow custom code specialization based on input type signatures (https://medium.com/@acidflask/smoothing-data-with-julia-s-ge...). These capabilities have been used for DSLs (e.g. https://github.com/JuliaOpt/JuMP.jl) and parser generation (e.g. https://github.com/abeschneider/PEGParser.jl).

No, I'm talking about generating Julia code from elsewhere. I'll derive some math in another program (e.g., Maple, Mathematica, SymPy) and output code that represents that math. I can't do that with Julia right now.

I see. Indeed, Julia's ecosystem is still quite young. (possibly of interest: a project building a Julia-integrated CAS called Nemo, at http://nemocas.org/)

In C++ - unlike C - you can actually implement quite good matrix/vector support. E.g., Eigen3 http://eigen.tuxfamily.org/index.php?title=Main_Page or Blaze https://bitbucket.org/blaze-lib/blaze or if you have a specific BLAS library tuned to your cluster then maybe FLENS http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/index.html

True, but the problem I had (which I will admit was back in '99) is that there's no standard one. So, if you need to solve a system of ODEs and a linear system, you're invariably needing to convert between the two.

This is still true. This library uses Eigen, that one uses Boost, the other one uses a home grown one. And then you want to use another library, it uses Eigen (yay!), but an old version of Eigen and it won't compile against the current version.

C++ really crippled itself in this regard by never making a standard. I never bought Stroustrup's claims of "but you can write your own" for these reasons.

At least from one report I read sometime ago, scientists in Los Alamos National Lab were looking at alternatives to Fortran for their future generations of climate models. C/C++ is under their radar. One reason for the switch is to better deal with unstructured grids. They are moving away from the traditional rectilinear grids. This is more in line with many FEM applications where C++ dominates.

Do you have an example of Julia not being fast enough?

Last I checked, some things that can be vectorized, but aren't in LAPACK/BLAS weren't particularly fast. There's even one example from a few years ago on Stack Overflow where it was at least an order of magnitude slower than Octave.

Reply on news.ycombinator.com