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

Giving up on Julia

zverovich.net

Post reply on HN
Print view View original

51–60 of 242 posts

Re: Giving up on Julia

#51

Post by xyience »

zintinio5 wrote: post #30

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

PyPy doesn't get you that much -- were you not using Numpy to begin with, and if not, why not?

Re: Giving up on Julia

#52

Post by GFK_of_xmaspast »

arcticfox wrote: post #43
zintinio5 wrote: post #30

For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish w…

Just how naively was the Python written? ~1600 hours vs. 4 hours of execution time sounds like some extremely naive starting code. Is it fair to even compare them?

I've gotten 400x speedups going from python to c++.

Re: Giving up on Julia

#53

Post by jordigh »

gaius wrote: post #26
Frompo wrote: post #15

If you want to replace Matlab you should use Octave, julia is for making your next climate model, not for "hello world" ricing

Octave is much slower than MATLAB.

The interpreter is. But if you write vectorised code, we frequently are able to outperform Matlab.

Matlab used to have the same problem, and they even used to have docs on how to vectorise. When I first learned Matlab in 2004, they told me, "don't use loops". Twelve years later, you're supposed to write all the deeply-nested loops you want.

So yes, most Matlab code out there is loopy, so it's slow in Octave. But if you write it for Octave and don't make it loopy, it's quite good.

Re: Giving up on Julia

#54

Post by nickpsecurity »

KenoFischer wrote: post #9

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

Might be as simple as creating a static and dynamic profile for Julia. I suggested this to developers of one language project before. Maybe Julia. A single keyword or declaration near top of the file tells it to compile for fast loading with no need for functions that change things at runtime. Or compiler option.

Re: Giving up on Julia

#55

Post by dagw »

GFK_of_xmaspast wrote: post #52
arcticfox wrote: post #43

Earlier quoted context omitted.

Just how naively was the Python written? ~1600 hours vs. 4 hours of execution time sounds like some extremely naive starting code. Is it fair to even compare them?

I've gotten 400x speedups going from python to c++.

I've gotten 200x speedup going (badly written) Javascript to (better written) pure python, despite python being a nominally slower language according micro-benchmarks. Comparing run time without knowing anything about the code doesn't say much.

Re: Giving up on Julia

#56

Post by KenoFischer »

nickpsecurity wrote: post #54
KenoFischer wrote: post #9

Happy to address these points: - Startup performance/memory usage Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia…

Might be as simple as creating a static and dynamic profile for Julia. I suggested this to developers of one language project before. Maybe Julia. A single keyword or declaration near top of the file tells it to compile for fast loading with no need for functions that change things at runtime. Or compiler option.

We do have various compiler flags, but the problem on startup is the initialization of external libraries and deserialization of the system image, primarily.

Re: Giving up on Julia

#58

Post by xixi77 »

Libraries? Sure. Ease of development, I cannot comment on.

But measuring performance with timing a "hello world" program? Seriously? What scenario does the author have in mind that makes this particular benchmark even remotely relevant?

The rest of the rant pretty much comes down to "it doesn't look like Python" (which is IMO a good thing, and I would certainly not call Python a "de facto standard of numerical computing" -- sure, it's there, but I still see a lot more of R and Matlab -- and note how both have 1-based indexes.)

To be fair, last time I checked, Julia definitely had some catching up to do in a few areas to become a real competitor to those two, but "hello world" benchmarks would not be among these.

It's been a little while though, and I am tempted to check again -- leaving libraries alone for the moment, does vectorization still result in a lot of performance loss compared to loops?

Re: Giving up on Julia

#59

Post by whyenot »

bmh100 wrote: post #41
vitaut wrote: post #19

Earlier quoted context omitted.

Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =). The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd def…

One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan. I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?

Not just FORTRAN, but R and MATLAB also use one-based indexing. It's also, at least historically, the convention for matrix notation. IMO do whatever attracts more users, as that is what Julia needs most. Without a large community moving from MATLAB, R, and other languages, Julia will never take off.

Re: Giving up on Julia

#60

Post by doug1001 »

- One-based indexing

setting aside whether zero- or one-based indexing is 'better'; R and MATLAB have one-based indexing, so the convention is likely familiar to many in the Julia target audience.

still, as the OP says, (relatively) painless interoperability with C and C++ is an advertised Julia feature, both of which use zero-based index (although Fortran is one-based), and that mis-match is a definite obstacle to interoperability.

Post reply on HN