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

Why Julia

ucidatascienceinitiative.github.io

Post reply on HN
Print view View original

11–20 of 257 posts

Re: Why Julia

#11

Post by rotorblade »

enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

I agree. I meta-programmed (enormous) expressions from analytical expressions exported from Mathematica to Julia, because I found Julia to be ~3000 times faster than Mathematica when it comes to calculating eigenvalues. Using BigFloat for higher precision, my matrix function in Julia took ~20 minutes to compile on the first run and ~20 GB of RAM. Smooth once compiled, but I was the only one of my collaborators that had the capacity to run it.

Re: Why Julia

#13

Post by FabHK »

I like Julia a lot, and thought I understood some of it, but this article puzzles me:

> This output is saying that a floating point multiplication operation is performed and the answer is returned.

But "this output" is:

  %2 = mul i64 %1, %0
  ret i64 %2
which looks very much like an int64 operation and return.

Similarly:

> Here we get an error. In order to guarantee to the compiler that ^ will give an Int64 back, it has to throw an error. If you do this in MATLAB, Python, or R, it will not throw an error.

while the quoted input and output is

  In [6]: 2^-5
  Out[6]: 0.03125
(ie, no error, but the correct (floating point) result.)

Re: Why Julia

#14

Post by agumonkey »

enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

I didn't find it slow, but:

    $ time julia -e 'print(1)'
    1
    real    0m0.438s
    user    0m0.300s
    sys     0m0.118s
    $ time python -c 'print(1)'
    1

    real    0m0.040s
    user    0m0.036s
    sys     0m0.003s
it is slower..

That said, instanciating julia every step of a bash loop.. I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

Re: Why Julia

#15

Post by FabHK »

alanfranzoni wrote: post #9

So... The answer is fundamentally "statically typed", right?

Not really. Values have types, unsurprisingly, but variables don't.

However, if the compiler can deduce the type at compile time, it will dispatch to the accordingly optimised function. (And type stable code helps doing that).

Re: Why Julia

#16

Post by agumonkey »

Datenstrom wrote: post #8

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

out of curiosity, could you give more details about modules problems ?

Re: Why Julia

#17

Post by ChrisRackauckas »

FabHK wrote: post #13

I like Julia a lot, and thought I understood some of it, but this article puzzles me: > This output is saying that a floating point multiplication operation is performed and the answer is returned. But "this output" is: %2 = mul i64 %1, %0 ret i64 %2 which looks very much like an int64 operation and return. Similarly: > Here we get an error. In order to guarantee to the compiler that ^ will give an Int64 back, it has…

This was written back in Julia v0.5, and the compiler got smarter so I need to update my examples :). Here, Julia specializes now on the fact that `-5` is a literal, and then inlines the literal and corrects the output type using that value. If you define it as a variable and stop constant propogation, it'll error. Stuff like this are making it harder to write tutorials to show what's actually going on, because literals and constants are all getting optimized on now!

Another confounding fact is that Julia optimizes on small unions, so the generated code isn't that bad anymore. Now it just creates a branch. It used to have to do all of inference and dynamic dispatching on the fly, which is what it has to do in fully uninferrable code of course, but a union of two things just does a type check and splits. So now... that example is not as bad as it used to be...

Re: Why Julia

#18

Post by celrod »

Datenstrom wrote: post #8

I recently began learning Julia and initially everything was amazing, except for 1 based indexing but with everything else I could overlook that. Then I attempted building something medium sized and it all fell apart. I feel like it needs some serious work on tooling, the module system, packages, etc. Has anyone built something medium-large sized in Julia? Maybe I'm missing something. When I was trying to use modules…

> When I was trying to use modules to organize my code the response I got was that modules are more trouble than they are worth so just don't use them.

Really? I normally break up my code across modules, but also across libraries. I'd say a few of my projects are at least medium sized. I discuss an example here, where much of the code is split across many separate modules: https://bayeswatch.org/2019/01/29/optimizing-a-gibbs-sampler... I achieve roughly 1700x better performance in an example than a JAGS model. A C++ version does a bit better at 2000x when compiled with Clang.

Having all these dependencies checked out for development is not best practice, so I wouldn't recommend strictly following my example.

Re: Why Julia

#19

Post by enriquto »

agumonkey wrote: post #14
enriquto wrote: post #6

> it's faster than other scripting languages That certainly depends on your use case. For instance, the launch time is ridiculously slow, so that you cannot realistically run a small matrix computation in julia from within a shell loop. It is better to use octave for that, where the startup time is almost negligible (just a bit slower than starting a subshell).

I didn't find it slow, but: $ time julia -e 'print(1)' 1 real 0m0.438s user 0m0.300s sys 0m0.118s $ time python -c 'print(1)' 1 real 0m0.040s user 0m0.036s sys 0m0.003s it is slower.. That said, instanciating julia every step of a bash loop.. I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

> I think it requires a jvm mindset, warmup once and iterate inside rather than outside.

I do not have this mindset then. I prefer tools who are mindset oblivious. They are really useful!

For example, imagine I have a collection of a few hundred images with their projection matrices (in text files). I want to crop them and apply a simple imagemagick operation (which is not available from inside julia). The elementary solution is to run a shell loop to apply the crop, and call julia to perform a simple adaptation of each projection matrix. This is impossible today: most of the running time of such loop is spent on julia initialization. Half a second to do nothing is simply unacceptable in a serious scripting language.

Re: Why Julia

#20

Post by FabHK »

ChrisRackauckas wrote: post #17
FabHK wrote: post #13

I like Julia a lot, and thought I understood some of it, but this article puzzles me: > This output is saying that a floating point multiplication operation is performed and the answer is returned. But "this output" is: %2 = mul i64 %1, %0 ret i64 %2 which looks very much like an int64 operation and return. Similarly: > Here we get an error. In order to guarantee to the compiler that ^ will give an Int64 back, it has…

This was written back in Julia v0.5, and the compiler got smarter so I need to update my examples :). Here, Julia specializes now on the fact that `-5` is a literal, and then inlines the literal and corrects the output type using that value. If you define it as a variable and stop constant propogation, it'll error. Stuff like this are making it harder to write tutorials to show what's actually going on, because liter…

Ah, well, I guess that's good news then!
Post reply on HN