Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Some Insights from a Julia Developer

stochasticlifestyle.com

Post reply on HN
Print view View original

121–130 of 241 posts

Re: Some Insights from a Julia Developer

#121

Post by iamed2 »

ssivark wrote: post #96
88e282102ae2e5b wrote: post #94

Earlier quoted context omitted.

I didn't mean to seem petty, it's just that going back and forth between zero-based and one-based languages just added extra mental overhead (admittedly this was with Fortran, so there may have been other issues).

The way I think of it is that different indexing schemes suit different problems. I want to think carefully about the problem domain and use the most convenient convention. For example, when my array stores a time series, I would like the index to correspond to timestamps (and still be performant, so long as my timestamps can be efficiently mapped to memory locations, which is true for affine transformations, for exa…

Sounds like https://github.com/JuliaArrays/AxisArrays.jl/ ;)

Re: Some Insights from a Julia Developer

#122

Post by mkborregaard »

anon_342njlkesr wrote: post #112

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 interoperability, but are gathered in batteries-included metapackages again. Like typing `using DifferentialEquations` will load all 60 small DifferentialEquations packages (centrally documented), but you can easily plugin alternatives if you like.

Re: Some Insights from a Julia Developer

#123

Post by mkborregaard »

skybrian wrote: post #110

I'm wondering about this part: "using this strategy Julia actually can produce static binaries like compiled C or Fortran code." Is this something that works now, something planned, or just speculation?

The blog posts highlights this as something planned. It does sort of work already, but not completely.

Re: Some Insights from a Julia Developer

#124

Post by vvanders »

StefanKarpinski wrote: post #119
vvanders wrote: post #114

Earlier quoted context omitted.

From what I can find[1] it looks like while Julia has compact values it doesn't have what I'd traditionally call value types. Specifically value types that live on the stack unless they are a member of a reference type(which is what C# does). Looking at the performance docs[2] this is pretty clear in that array types(which looks like how Julia does Matrices) get allocated on the heap. You can clearly see the performa…

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 basis. With the constraint above I'm now copying 300 floating point values every time any node changes which would be brutal for performance. Or I'd take a potential cache miss each time I touched the array which could be even worse if it was a reference type.

To be clear, I'm not saying Julia isn't really good at what it does. My complaint stems from the fact that you can't claim performance good as/better than C without having all these tools at your disposal.

We haven't even gotten into things like restrict[2] where things like Rust's ownership model let you get it for free[3].

[1] https://docs.unrealengine.com/latest/INT/Engine/Rendering/Ma...

[2] https://en.wikipedia.org/wiki/Restrict

[3] https://doc.rust-lang.org/nomicon/aliasing.html

Re: Some Insights from a Julia Developer

#125

Post by flavio81 »

parenthephobia wrote: post #81
mhd wrote: post #16

Is there a good use case for Julia outside the "math" community, when your alternatives wouldn't be R or Numpy, but Ruby or C#?

Perhaps it's a borderline case, but I've used Julia to make a "big data" database server, backed by a mmap'ed column store. Because the compiler's available at run-time, queries can be compiled into efficient kernels that can run in parallel over multi-gigabyte arrays orders of magnitude faster than MySQL or Postgres on the same hardware. Without Julia, I would have had to find some other way to compile queries into…

Excellent use case.

>Without Julia, I would have had to find some other way to compile queries into machine code at run-time

Note that you could also do it in Common Lisp.

But I agree, Julia is very powerful, perhaps one of the most powerful recent languages.

Re: Some Insights from a Julia Developer

#126

Post by StefanKarpinski »

throwaway7645 wrote: post #84
ViralBShah wrote: post #65

Earlier quoted context omitted.

In my opinion, this is not about abandoning, but supplementing. Python is good at many things, as is Rust, as is Julia. Stuff like the ODE library that Chris has, or JuMP (for mathematical programming) that Miles Lubin, Iain Dunning and Joey Huechette wrote, or a number of other packages are simply not available elsewhere. The Celeste project, for example, achieved 1.6 PetaFlop/sec of compute rate on half a million c…

Python's PULP & Pyomo are pretty similar to JUMP.

The JuMP paper [1] compares JuMP with all the major commercial and open source options in this area, including Pyomo. Pyomo is orders of magnitude slower than JuMP and doesn't scale as well so the comparison gets worse as problems get larger. (Pyomo had the worst performance of all the systems compared.) JuMP is the only open source option that has performance like commercial systems. Throw in JuMP's improved expressiveness and usability over Pyomo and JuMP's incredibly broad solver support [2] and there's really no contest. These days, your best option in Python is probably to call JuMP via pyjulia.

[1] https://arxiv.org/pdf/1508.01982.pdf

[2] http://jump.readthedocs.io/en/latest/installation.html#getti...

Re: Some Insights from a Julia Developer

#127

Post by vvanders »

KenoFischer wrote: post #118
vvanders wrote: post #114

Earlier quoted context omitted.

From what I can find[1] it looks like while Julia has compact values it doesn't have what I'd traditionally call value types. Specifically value types that live on the stack unless they are a member of a reference type(which is what C# does). Looking at the performance docs[2] this is pretty clear in that array types(which looks like how Julia does Matrices) get allocated on the heap. You can clearly see the performa…

For values with compiler-visible scoped lifetime, the compiler will automatically promote them to stack variables. There is currently no way to enforce this happening, but it would be perfectly possible to add such an annotation. Regarding preallocation, you tend to want to avoid dynamic memory allocation in high performance applications anyway, so whether you do that in C++ or in Julia, doesn't really make too much…

> Regarding preallocation, you tend to want to avoid dynamic memory allocation in high performance applications anyway, so whether you do that in C++ or in Julia, doesn't really make too much of a difference.

Yes! Which is why it shouldn't take me digging through 3 different documents and still getting it partly wrong!

C/C++/Rust make this easy by annotating the type modifiers(&/*/Box/etc) with how the object lives in my runtime system. Rust even gets bonus points for giving me aliasing information as well(&mut vs &).

Re: Some Insights from a Julia Developer

#128

Post by strictfp »

88e282102ae2e5b wrote: post #17

It's great and all, but I can't justify switching languages for minor improvements over Python + numpy/scipy. I'd be abandoning: * My deep knowledge and experience with Python * My entire codebase * The ability to work on projects with colleagues who don't also switch * The certainty that when I leave my current job, someone will be able to pick up after me * Zero-based indexing I've started to do some work in Rust w…

I also found this effect super annoying when I switched to using a car - having to sell my carriage, get rid of my stable, sell or rent all my horses. All my connections in remote stables were suddenly useless. And I had to sell of all that hay! And oil, I had to get lots of oil! And it's nowhere to be found! Outrageous, I say.

Re: Some Insights from a Julia Developer

#129

Post by StefanKarpinski »

vvanders wrote: post #124
StefanKarpinski wrote: post #119

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 really don't like intermixing mutability with allocation location. Those seem like two completely separate concerns.

They're not. The semantics of value types and reference types are different in the presence of mutation. So if you want uniform object semantics in a language, then objects that can be implemented as values must be immutable. There are many languages that have kept these independent and bifurcated their type system instead (Java, C#), but it's been a source a great deal of pain and frustration (e.g. Java's `int` versus `Integer` awkwardness).

Fortunately, there's nothing you can do with mutation that you can't do just as well by modifying and replacing an immutable value in a mutable cell – the compiler implements them the same way. Wrap an immutable in a mutable `Ref` and voila, you've got something equivalent to a mutable value type without exposing completely incompatible semantics in the language.

Re: Some Insights from a Julia Developer

#130

Post by throwaway7645 »

StefanKarpinski wrote: post #126
throwaway7645 wrote: post #84

Earlier quoted context omitted.

Python's PULP & Pyomo are pretty similar to JUMP.

The JuMP paper [1] compares JuMP with all the major commercial and open source options in this area, including Pyomo. Pyomo is orders of magnitude slower than JuMP and doesn't scale as well so the comparison gets worse as problems get larger. (Pyomo had the worst performance of all the systems compared.) JuMP is the only open source option that has performance like commercial systems. Throw in JuMP's improved express…

Not sure how much performance matters here. You're just farming it off to CPLEX or Gurobi anyway. If performance really matters, you'll do this part in C++ anyway.
Post reply on HN