Live data from Hacker News

Some Insights from a Julia Developer

stochasticlifestyle.com

211–220 of 241 posts

Re: Some Insights from a Julia Developer

#211

Earlier quoted context omitted.

How come there are no entries for Julia on the Benchmarks Game? http://benchmarksgame.alioth.debian.org/ Given Julia's good performance, it is a little strange. :)

Inclusion is by selection of the admin [1,2]. There are Julia implementations available for most of the benchmarks [3] so perhaps eventually they will be included. [1] https://alioth.debian.org/forum/message.php?msg_id=182495&gr... [2] http://benchmarksgame.alioth.debian.org/play.html#languagex [3] https://github.com/JuliaLang/julia/tree/master/test/perf/sho...

Interesting! Does that mean the Benchmarks Game is not open for new languages? The faq entry is kind of ambiguous.

Re: Some Insights from a Julia Developer

#212

I tried julia last year, and it was a nightmare of version skew. Has it improved in that regard at all?

If you need something stable, wait until a bit after 1.0, like you would with any Windows release. Right now it's expected that things will change and break with language updates, but the next one is the 1.0 which is the "we stop breaking things now"

That's what I was told about 0.4 -> 0.5 last year.

Re: Some Insights from a Julia Developer

#213

Yeah, the language design of julia is brilliant (multiple dispatch, typing, llvm use, zero-cost abstractions, @code_native to see why your code is slow). This allows you to write fast code in julia, which is impossible in python (you can call into very fast C/Fortran libraries with nice bindings, though). On the other hand, I really hate the syntax. One-based array indexing (ok, minor), blocks ending with "end", and…

Just a response for a few comments, since you talk with confidence but could maybe do with a closer look: 1. You end with `end` in julia. 2. You can use indexing with any base, not just 1 - no performance penalty. 3. The julia repl comes with latex completions making it very easy to just type e.g. \sigma and get the sigma sign. 4. The package system is moving both directions - functionality is split into modules for…

Re 2: Yes, but most of the language is geared towards 1-based indexing, e.g. ranges like a:b being inclusive at the right. Hence, using a zero-based variant of array makes only sense if your code really really profits from zero-indexing.

Btw, the question should not be "is zero-based slower"; I know that julia has zero-cost abstractions. The question is whether is is faster, because of the avoided decrement instructions for the underlying pointer arithmetic: say, M=Matrix{Int64}(4,N), then @inbounds x=M[i,j] corresponds to x=unsafe_load(pointer(M), i + (j-1)*4). And the internal C code needs an extra decrement on i, because array data pointers use the C convention of pointing to the first element.

Re 4: This is a problem with discoverability and dependencies. Say, my code needs a heap-queue.

Sure, heaps exist, e.g. in datastructures.jl. But there is no canonical documentation / default choice in the base language, like e.g. heapq in python.

And if you want to figure out how to use custom orderings for your heap you end up reading the source code of all 2-3 heap implementations in datastructures.jl (which use different incompatible APIs), because the documentation fails at providing examples. Older julia versions came with heaps included.

Re 3: The REPL is not everything. By all means, define a global name mangling scheme that (with default options) symbol-names should be latex-displayed in the REPL or ijulia. I mean, when using a mono-spaced font you don't want to see a greek sigma in latex either! You want the code, i.e. \sigma, and you want someone (not yourself) to write a word-processor that inline-displays weird characters for your grandma.

Don't understand me wrong, I like julia; it is just that every single "mostly inconsequential" / matter-of-taste design decision pisses me off, whereas the really important parts are awesome.

Re 1: Maybe I haven't written enough fortran in my life, but both python-significant-whitespace and C/java-style curly braces make a lot of sense and are very easy to parse and highlight (for text editors). But sure, I understand that this is matter of taste, and very cosmetic.

Bonus problem: By default, multidimensional arrays access is such that the first index is fast for iterations. This is different from C layout, and means that A[i,j] corresponds to A[j][i] if you switch out Matrix and Vector{Vector}. I know that fortran did it that way, and I think this was a mistake in fortran already.

Re: Some Insights from a Julia Developer

#214

Yeah, the language design of julia is brilliant (multiple dispatch, typing, llvm use, zero-cost abstractions, @code_native to see why your code is slow). This allows you to write fast code in julia, which is impossible in python (you can call into very fast C/Fortran libraries with nice bindings, though). On the other hand, I really hate the syntax. One-based array indexing (ok, minor), blocks ending with "end", and…

I greatly prefer Julia syntax. `end` makes the code blocks stand out more easily than }. I find it easier to see the indentation at a glance than when just dealing with a single thin character. Also I like that Julia prefers shorts words over special characters. C/C++ use far too many special characters. That might run counter to my delight at unicode support. I think it is quite nice to be able to write mathematical…

Re unicode:

When writing latex, you don't want to encounter unicode greek sigma. You want \sigma, as 6 7bit-ascii chars. Same in julia; sure, define a display mode that translates certain things into unicode for people like you, but keep compatibility with code-editors/people/tools who do not understand unicode. In short: I want to it to be possible to use a dumb text-editor, not an IDE/word-processor. (ok, the text editor will need to understand UTF8, because unicode string literals are really important; but please never go beyond a small white-listed subset of 7bit-ascii for language tokens).

Re: Some Insights from a Julia Developer

#215

Earlier quoted context omitted.

The distinction in Julia isn't between value versus reference types (which have fundamentally incompatible semantics), it's immutable types (declared using `struct`) versus mutable types (declared using `mutable struct`). Immutable types are generally stack allocated and need not even be fully materialized, whereas mutable types are typically heap allocated and fully materialized. The built-in array-type is mutable a…

Uf, I really don't like intermixing mutability with allocation location. Those seem like two completely separate concerns. One thing that was really common for us to do was to instance a weighted graph(something like this[1]) per-actor. This means that you might have 10-300 floating point values in a block indexed by the node they interact with. It was really common to see one, maybe two values change on a per-frame…

I had the same problem; my problem was not the giant number of reads, but rather that a naive replacement needs a read and has a dependency on the write-back; hence, a scatter where you modify immutable structures by replacing certain fields induces a stall on cache-miss.

In my case, julia/llvm was smart enough to figure out that the read and write can be eliminated. Hence, the julia code that replaces an immutable with a copy where only few fields are changed generates the same @code_native as the obvious evil construction (figure out where the field is stored; unsafe_store! to the pointer).

But I guess this optimization is unreliable, or at least it is not well documented when this optimization is guaranteed to happen. So the situation is not optimal, but also not as catastrophic as you would have guessed without reading the generated native code.

Re: Some Insights from a Julia Developer

#216

Earlier quoted context omitted.

> Sure, but why would zero be the proper number to start counting at outside of zero-based programming languages? I don't take programming languages as a reference point. It's the other way around. I try to figure out what the most natural, principled, and elegant way would be, and I would base my programming language on that, if I were to design one. > Zero means an absence of objects to count or list. I count that…

> The relationship between the two would be that the number of cars is the number that is next in line when you have called out the indices (0, 1, 2, 3, 4, 5, 6) of all the cars. But who thinks that way? I just see 7 cars, not an indexed listing. And anyway, the 0 indexed car doesn't exist.

He who finds zero-based indexing to be the proper way and wants to shape his thinking thereafter!

Re: Some Insights from a Julia Developer

#217

Earlier quoted context omitted.

Could it be that the offset calculation to find the start of the array is needed in any case?

My thinking is this: To access an array via index, you basically have to take the reference to the array, the index (i), and generally multiply (i) by the space set aside for each element (e). i * e If you've offset the array, you have to take the offset index (o), and call a mapping function (m) that maps (o) to (i), so the result can be multiplied by (e). Though it should be said there is another theoretical altern…

Instead of storing the start address of the array, store a suitably offset address, right? That amounts to an addition that has to be performed when memory is allocated to the data structure, which may be at compile-time or at run-time.

Re: Some Insights from a Julia Developer

#218
post #195

Earlier quoted context omitted.

Why don't you think you can control those things? Make an array, loop through linearly, just like C. Avoid allocations in inner loops, just like C.

I agree, a lot of the performance problems have to with allocation in any language, gc'd or not. I still can't believe people making the same argument against gc'd languages even when highly performant jvm exists.

It's not an issue of allocation, it's an issue of allocation location to get better cache locality.

Take the JVM, a good majority of ORM databases uses Sun.misc.unsafe to do manual native memory allocation. Not because it's faster(because it isn't faster than bumping the nursery pointer).

They do it so they can control where disparate datatypes live in memory so that as a cache line is read in the prefetcher is already pulling in the next cache line.

Things like this will get you a 10-50x performance increase, which in some cases you absolutely need it.

Re: Some Insights from a Julia Developer

#219

Earlier quoted context omitted.

The improvements are not minor they are massive. Citing rust shows that the advantage of Julia has not been explained well enough. Julia allows you to write as performant code as Rust with a much smaller investment in learning. You cite your concern for spending time learning something new. That makes no sense considering the high learning curve and complexity of Rust compared to Julia. Julia is quite fast to learn a…

I've been using Julia for a year or two now, and over that time my enthusiasm for the language has waned, not grown. Here's the standard pitch for Julia: C-like performance with R/Python/MATLAB-like expressivity. This is undeniably true. For someone coming from R/Python/MATLAB, you will be able to program as easily in Julia, if not more easily and more cleanly, and get much better speed. However, what I've come to re…

What problems are you solving with Julia? The way I see it, Kotlin, Nim, and Crystal are completely different languages aimed at a different space.

e.g. Kotlin is being used for Android apps, which is worlds away from what MATLAB and R users do.

Re: Some Insights from a Julia Developer

#220

Earlier quoted context omitted.

If you need something stable, wait until a bit after 1.0, like you would with any Windows release. Right now it's expected that things will change and break with language updates, but the next one is the 1.0 which is the "we stop breaking things now"

That's what I was told about 0.4 -> 0.5 last year.

By who? Someone who isn't part of the development team? There was an issue set for v0.5 called "Arraypocolypse" that was meant to change a ton of things related to arrays, and that was known months (a year?) before v0.5 was out. Semvar is used for a reason: pre-1.0 is all breaking.
Post reply on HN