Some Insights from a Julia Developer • Hacker News Board

Re: Some Insights from a Julia Developer

#141

Post by [deleted] » Sat, Oct 14, 2017, 9:36 PM UTC

mkborregaard wrote: post #44

ChrisRackauckas wrote: post #25

Earlier quoted context omitted.

1) No, they are just different dispatches to getindex. 2) No, iteration is through indices(A) or eachindex(A), etc., which are the preferred way of iterating anyways. You shouldn't do 1:length(A) which is a MATLABism that works but I would say isn't good Julia. 3) Defining new dispatches for length and size is a pretty standard use of the language? "Non-standard" arrays with non-standard indexing already work in lots…

The `length(linearindices)` and no `size` etc are for a short transitory period while packages are ported to the indexing-based-non-reliant framework.

[deleted]

Re: Some Insights from a Julia Developer

#142

Post by bjourne » Sat, Oct 14, 2017, 10:08 PM UTC

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…

> 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.

Other languages such as Java have that optimization too. But it is quite limited because it can only be applied to data whose size is known at compile-time. There is also the problem that if some data allocated in a procedure is passed to another procedure, it can't be allocated on the stack because it can escape.

A programmer working in a low-level language can be smart and choose the best locations (stack or heap) for each piece of data. A language that does not allow explicit stack access (like C does), can never make as optimal decisions.

Re: Some Insights from a Julia Developer

#143

Post by ACow_Adonis » Sat, Oct 14, 2017, 10:08 PM UTC

ssivark wrote: post #75

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…

Any time 1-based indexing is mentioned as a shortcoming of Julia reminds me of PG's 'Blub paradox' [1]. > As long as our hypothetical Blub programmer is looking down the power continuum, he knows he's looking down. Languages less powerful than Blub are obviously less powerful, because they're missing some feature he's used to. But when our hypothetical Blub programmer looks in the other direction, up the power contin…

I've seen the claim that Julia has offest-arrays at essentially no additional cost a few times now, and I'm just not buying it.

As in, I don't see how its possible without stretching the meaning of "no additional cost". I'm familiar with displaced arrays and the like in Common Lisp, so i get that you can do offsets and things without using much additional memory, and i feel its a small jump from that to arbitrary indexing.

I mean, sure, if you're programming with constants or common patterns or things like that, a compiler could theoretically figure out and adjust the references itself. Or you can use macrology (I presume, since julia is so close to being lisp in matlab clothing, there's no issues with this in theory). Or you can come up with some kind of functional wrapper to adjust offset indexes back to the base case...

But if you're actually using run-time calculations using returned numbers from a calculation to index N-quadrillion times into various arrays and you're swapping between a standard and arbitrary/offset index measure, which is about the only time I can see you'd actually care about the relative efficiency of repeated arbitrary indexing, then it can't be a pre-compiled thing. The offsets between the actual numbers you're getting back and the actual index into the arrays have to be calculated in an additional step at run time.

Now its true that's likely to be only an addition or multiplication operation for each one, (and if it isn't, the run time application of another transformation just cements my point) but perhaps my notion of "essentially no additional cost" is more strict...

Re: Some Insights from a Julia Developer

#144

Post by bjourne » Sat, Oct 14, 2017, 10:14 PM UTC

3JPLW wrote: post #117

pollitos wrote: post #87

Earlier quoted context omitted.

Just to note, these benchmarks are biased. This is a competition between highly-tuned-to-the-processor Julia with tuned BLAS vs other languages out-of-the-box binaries. Additionally, the benchmarks tests are written inefficiently in the comparison languages. But even then Javascript comes out on top on some benchmark tests.

Yes, these benchmarks do tend to be a lightning-rod for controversy. You have two complaints: 1. Yes, some languages do not make it easy to install and link against a well-tuned BLAS. The benchmarks were very recently updated, and you can see the level of effort required to get everything installed and working properly. This was all done in the open on the discourse message board. 2. Yes, the benchmarks involve testi…

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. :)

Re: Some Insights from a Julia Developer

#145

Post by ACow_Adonis » Sat, Oct 14, 2017, 10:16 PM UTC

SolarNet wrote: post #108

Bromskloss wrote: post #98

Earlier quoted context omitted.

It's not just something particular I need it for; it's everything.

If you read the OP again carefully, you'll see that you can use offset arrays for every array you make and suffer no performance penalty, because the offset is compiled away. And the development overhead is a single library import call; I replace core language data-structures all the time in any language for features I want, this is no different.

See my other comment in the thread for the thing I've always wondered: How can you compile away an arbitrary calculation that might need to be made at run time?

(assuming we're not just arguing over arbitrary-array indexing to input predefined constants at the REPL/code level).

Re: Some Insights from a Julia Developer

#146

Post by attractivechaos » Sat, Oct 14, 2017, 10:25 PM UTC

attractivechaos wrote: post #21

pjmlp wrote: post #15

Earlier quoted context omitted.

Why ugly? It looks similar to what I know in the Pascal family, where indexes can be ranges or enumerations.

It is ugly because 1) 1-based indexing and x-based indexing are treated differently; 2) x-based indexing has to use more complex syntax, which in effect discourages the use of non-1 indexing; 3) this strategy sets potential pitfalls (e.g. implementing length and size for non-1 indexing arrays). A cleaner design, I guess, would be to specify index range on declaration like pascal static arrays and use low(A):high(A) f…

Hmm... I wanted to learn more about 0-indexed arrays, but after looking around, I still have not figured out how to declare 0-indexed arrays without extending the AbstractArray interface or using another package.

Re: Some Insights from a Julia Developer

#147

Post by ACow_Adonis » Sat, Oct 14, 2017, 10:36 PM UTC

Sometimes, in my darker moments, I have the terrifying thought that one of the reasons that many users like R and made it popular (apart from the historical context of its now many libraries and being the main free version of statistical software), is specifically that it isn't robust and sensibly designed from a programming/analytical perspective.

You can download a package, type in a preset command on a preset thing, and 95% of the time (its R, so its only ever 95% of the time), you get back an answer/number.

And if an answer is what you're after, that's where the considerations stop.

Was there an edge case? Is R's answer really correct? Did it wallop something in your search path? Do you have your profile set up differently to the author? Do all the dependent packages clash and silently depend on how you load them and in what version you did so? Has R coerced something in the background, or pattern matched your typo'd variable to something it shouldn't? Somewhere in your code did you hit on one of the thousands of gotchas?

Who cares? It gave me an answer. I can give it to my boss or put it in a paper.

I personally am all for faster, safer, stricter (while still being dynamic) languages. And i've tried to explain to many users that languages that produce errors when you do something you shouldn't are not your enemies, they're your friends. But I see many people every day aren't living that philosophy, they'd rather an answer than the right answer or a robust answer, despite what they'll tell you in plain english.

With respect to Julia, someone like me might like it (well, if they got rid of the matlab syntax and just went back to the Lisp they copied and relabeled as 'Julia' :P).

But perhaps many users don't want a faster, more robust language. Perhaps, many of them are comfortable with a simple but wrong answer. And for that purpose, I can't see where Julia wins out relative to R.

As I said though, these are thoughts i have in my darker moments...

Re: Some Insights from a Julia Developer

#148

Post by ACow_Adonis » Sat, Oct 14, 2017, 10:52 PM UTC

icebraining wrote: post #78

sin7 wrote: post #56

Earlier quoted context omitted.

I use a lot of R. The thing that drives me insane is when you create a function such as multxy <- function (x){x * y}, then you call multxy(6) R will not return an error as long as y is in the parent environment. That's pretty insane.

I don't use R, so I thought you were referring to dynamic scoping, which I do think it's horrifying. But it seems R uses lexical scoping - that is, the y is captured at function definition time. That's extremely common and quite useful, in my opinion.

R documentation and users SAY that R has lexical scoping, which can be really confusing for people reading about the topic.

But if you're coming from something like Common Lisp (which is my point of reference), you soon discover that "Lexical Scoping" as implemented there and "Lexical Scoping" as implemented in R are two different things.

In R (paraphrasing) you generally have a search path of environments, and at run-time, R will find a variable by going from the inner-most to the outer-most environment looking for variables of that name. When it finds one, that's the variable R uses. What R does do is capture the path of environments that were in effect at the time of a function's creation. R has to do many of these variable lookups at runtime, which is also a factor that makes is so slow.

So what you get is a scoping scheme that, if i were being short, i'd call "actually more like dynamic scoping with environment search paths", and if i were being flippant "pretty much dynamic scoping dressed up to look like lexical scoping without any of the benefits/distinctions of either. If someone changes the applicable environments or variable later, R will just keep on humming along, pointing at new variable references that align with whatever variable name the original author of the code used, as long as that variable exists somewhere on the applicable search path"

Re: Some Insights from a Julia Developer

#149

Post by baldfat » Sat, Oct 14, 2017, 10:54 PM UTC

baldfat wrote: post #77

Bromskloss wrote: post #42

Earlier quoted context omitted.

> 0 based is due to programming iteration. I think it makes sense for enumeration in general to begin at 0. It's a mapping from the natural numbers after all, and zero is the most natural number! What makes you think of programming iteration as a motivation for zero-based indexing?

> To quote wikipedia on Zero-based "Zero-based numbering or index origin = 0[1][2] is a way of numbering in which the initial element of a sequence is assigned the index 0, rather than the index 1 as is typical in everyday non-mathematical/non-programming circumstances." 1 Based 0 = 1 1 = 2 Zero based 0 = nothing 1 = 1 Seem important for mathematics.

Also head and tail in Pandas is 1 based! That drove me crazy.

print(users[users.age > 25].head(3))

Returns 3 elements and not 4!

Re: Some Insights from a Julia Developer

#150

Post by andyferris » Sat, Oct 14, 2017, 10:56 PM UTC

vvanders wrote: post #79

ViralBShah wrote: post #71

Earlier quoted context omitted.

The point around Julia's performance is often in the context of mathematical computing. The two languages are designed for very different use cases. Julia is designed to make it extremely easy to write high performance mathematical programs with ease. Rust is designed to make it easy to do systems programming. Both are high performance for the things they are designed to do. Just like I wouldn't do systems programmin…

Sure but mathematical problems don't exist in isolation. I used to do a ton of 3D graphics work with matrices, vectors, etc. We definitely couldn't use something that didn't have the right support for data layout and good runtime semantics. C/Rust/C++ fit that very well so I wanted to understand how similar claims were made for a GC'd language. C# for instance can work with value types and was wondering is Julia has…

Just thought I'd chime in that there is a StaticArrays.jl package that lets you make arrays which are stack allocated like value types in other languages, and you can make arrays of static arrays that layout exactly like arrays of structs in C/C++, and can be memory mapped from disk and so-on. (Such arrays of static arrays do eventually get GC'd, but that is not necessarily very frequent). They also support the same set of abstractions as other arrays including performant (SIMD) math/linear algebra that in my (biased) opinion is perfect for 3D graphics.

(As an aside, we also take this further with abstractions of 3x3 rotation matrices using a variety of internal representations such as quaternions in Rotations.jl, and allow composing coordinate transformations in CoordianteTransformations.jl, etc, etc).

Touching on the original authors post about the package ecosystem, I feel it can't be understated enough how easily different packages can compose and be used together in Julia. I like to say there is a product rule here where functionality/productivity grows as the square of the number of packages/features you can use together naturally (regardless of programming language). We can use static arrays, rotations, coordinate transformations, etc in combination with differential equation packages to simulate a system or with an optimization package to optimize a coordinate transformation for SLAM given certain measurements, and so-on, at full run-time speed but comparatively little user effort.