Hacker News Reader

Comment by jakobnissen | Hacker News Reader

Underrated comment. Yeah, if you want C-like performance, you have to do some low-level considerations, that is unavoidable at some point. So the "speed of C, convenience of Python" is misleading.

However, for many, many small tasks, today's compilers are smart enough that you can express your idea in a high-level language and the generated code will be maximally efficient. The real killer feature of Julia is that, where ever you can gain maximal performance with high-level syntax, you can just choose to do that. A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen.

View on HN

"A more correct but less sexy slogan for Julia is that it has the best performance/expressiveness tradeoff you have ever seen."

This I almost fully agree

That's still a massive selling point. In python, getting speed can be weird and counterintuitive. In C, a straightforward algorithm can be blazing fast. For example, finding the length of the longest word in a string, you can just iterate through the string keeping track of a few indices. In cases like that, where the obvious simple C function is incredibly faster than the same python, where does Julia fit in? Would that kind of naively written function be closer to C or Python?

In general, if you code like Python (highly dynamic code with no consideration to performance) it will be closer to Python in speed, and if you code like C/Fortran (completely static, overspecified types) it should be closer to C in performance, the variance in performance in terms of naive implementations is pretty high. That means it's easy to get into Julia and start programming no matter your background, but idiomatic Julia (which it's not something you'll learn in a day) should be concise and high level like Python (and frequently more concise) and close to C in speed.

For example, what other dynamic languages do like verbosely typing everything doesn't really work in Julia (the compiler already knows pretty much every type even without hints), what works is treating the variable as a polymorphic container instead of a dynamic container: you don't know yet what type the variable has (only the behaviour), but whatever it is you should avoid changing it if possible (what they call type stability). Which is kinda why it might not be obvious reading proper high performance Julia code, as it is not something you do to make it fast, but what you don't do (change a variable type, forcing the compiler to create a low performance dynamic box, plus other stuff like global variables).

In that case, it's closer to C in speed, and usually more generic and "easy on the eyes". I don't know much about C, but seem to recall that it doesn't play well with unicode, usually treating text as bytes. Here's an equivalent Julia example:

    function longest_word(st::Union{String, SubString{String}})
        len = 0
        start = 1
        @inbounds for i in 1:ncodeunits(st)
            if codeunit(st, i) == UInt8(' ')
                len = max(len, i - start)
                start = i + 1
            end
        end
        max(len, ncodeunits(st) + 1 - start)
    end

This takes about 8.2 µs for a 8.5 Kb piece of text on my laptop, but that only works on ASCII text and only treats ' ' as whitespace, not e.g. '\n'. For a more generic one, you can do:

    function longest_word(st::Union{String, SubString{String}})
        len = i = 0
        start = 1
        for char in st
            i += 1
            if isspace(char)
                len = max(len, i - start)
                start = i + 1
            end
        end
        max(len, i + 1 - start)
    end

This is 20 µs for the same text, so still only 3 ns per char. The underlying functionality, namely String iteration and the `isspace` function, is also implemented in pure Julia.

Reply on news.ycombinator.com