Hacker News Reader

Comment by adgjlsfhk1 | Hacker News Reader

In my opinion, Julia is much better for numeric performance than C or Fortran. Real macros mean that you don't have to use a janky preprocessor (or a separate programming language) to generate optimal code, and multiple dispatch means you don't need to give your functions awful names (looking at you cgbtrf) and instead can just name them for what they do.

(Also, Julia gives you easy automatic differentiation and gpuification)

View on HN

The awful names are from a six-character limit somewhere.

I'm curious why you would want multiple dispatch. Seems to me like either longer names or single dispatch would be enough. In "cgbtrf", the first three letters just tell you what kind of matrix are the input... "cgb" being a complex-valued band matrix. That leaves you only three letters to say what the function does.

with multiple dispatch, this function would just be lu. Multiple dispatch means that all the functions that add things can just be called +, and all the ones that compute lu factorizations can be lu, and which specific version gets called is all handled by the type system. If I call lu on a complex banded matrix, it will dispatch to the method optimized for that without me having to care about what that is. This makes writing generic code much easier because you don't have to write a separate copy of your function for each new datatype you want to support.

So like Fortran generics.

Not really, Fortran is inching it's way towards generics, but doesn't actually have them in a usable form yet.

Parameterized derived types seem good enough for what Fortran is used for.

They are powerful enough to express functions that only depend on one argument, but how would you use them to encode the types of both arguments for matrix multiplication?

Like this?

https://www.pgroup.com/blogs/posts/f03-oop-part3.htm

That gets you some of the way there, but isn't powerful enough to handle things like orthogonal*banded or really any situation where all the types aren't planned out in advance.

I don't remember if it exists for LAPACK, but there's a generic BLAS interface with ifort/MKL. It's just a pity it was never (quasi-)standardized. (The trivial example is Fortran intrinsics.)

I was happily using CLOS-like systems long before Julia, though. Does Julia actually beat SBCL, for instance, on such things?

Julia has been heavily inspired by Lisp (especially Dylan and scheme). In my experience, Julia is easier to use for numeric computing.

Julia currently has specific weaknesses that make it unsuitable for a large category of problems that a language like Fortran (or C) has handled seamlessly for decades.

Do you have any specific example? I am truly interested. One of the things I don't like so much about Julia is its community, always preaching Julia is a better language than X, Y, and Z all together. It would be nice to have some concrete examples.

The obvious one is any time you need a statically compiled binary. There's work on that, but for now at least, that's a definite shortcoming.

Can you elaborate further, with an example, how this is different from static polymorphism? I don't fully understand your argument where you say "it will dispatch to the method optimized for that" and then "you don't have to write a separate copy of your function for each new datatype". The two do not seem consistent with each other.

That sounds like single dispatch to me. Maybe I'm missing something.

> multiple dispatch means you don't need to give your functions awful names (looking at you cgbtrf) and instead can just name them for what they do.

Fortran has ad-hoc polymorphism, and 63 characters maximum length for names. These should be enough to keep the user happy in this use case.

(The programmer still needs to write separate code for each version of input types.)

Eventually, note that you should compare it against latest ISO Fortran standard per commercial compilers, not what gfortran is capable of.

Reply on news.ycombinator.com