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

21–30 of 242 posts

Re: Giving up on Julia

#21

Post by KenoFischer »

metrognome wrote: post #17

When the author compares the number of CPU instructions that sprintf compiles to in both C and Julia, he fails to take into account dynamic linking in C: jmp __sprintf_chk I would guess that another few hundred instructions run as a result of this jmp. Thus, the difference in the number of instructions that C's sprintf and Julia's @sprintf compile to are not as drastic as the author makes it seem.

I believe that author's point was the size of the resulting generated code, which is fair. The original intent of making it a macro was to get a faster version of printf. However, as it turns out the major time sink in printf is not the formatting, but converting binary into decimal, so specializing on the format string doesn't actually help.

Re: Giving up on Julia

#22

Post by rch »

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…

I liked how the Template Numerical Toolkit implemented one-based indexing:

    // Construct matrix. Elements are not initialized.
    // To initialize all elements to zero use
    // Matrix a(2, 2, 0.0).
    Matrix a(2, 2);
    
    // Assign elements to first row using
    // Fortran-style one-based indexing.
    a(1,1) = 0.5; a(1,2) = 1.0;
    
    // Assign elements to second row using
    // C-style zero-based indexing.
    a[1][0] = 1.5; a[1][1] = 2.0;
-- http://www.b-a-h.com/software/cpp/scppnt.html

Re: Giving up on Julia

#23

Post by dagw »

acomjean wrote: post #10
dnautics wrote: post #4

Earlier quoted context omitted.

Yeah the poor performance in this blog post is a total misunderstanding of why and how julia is performant. Is printing "hello world" fast really that important? OK. Then don't use Julia. You pay for it by having the compiler JIT the code in a highly optimized fashion. If you have actual numerical calculations that are compile-once, run-many-many-many-times, then you will see a huge performance benefit, amortizing th…

>The goal of Julia is to not have to do that sort of boilerplate/arcane tweaking to get really good performance As someone who is new to python (for bioinformatics), and find python is a fine language... but.. The do it "this way not that way" method of implementation of the same algorithms to get it to run fast makes writing performant python a tedious exercise in research and profiling. The article cited suggests C…

Why not C using GPU acceleration as the time spent coding would probably be the same?

As someone who does that sort of thing I can assure you it isn't. And when I do use C and GPU acceleration, doing so via cython and pyCUDA (and the myriad of libraries that build on cython and pyCUDA) saves massive amounts of time and effort.

That being said I do agree that writing fast python is quite different from writing python, probably more so than in most other languages.

Re: Giving up on Julia

#24

Post by ska »

marmaduke wrote: post #8

Numba package for Python gives you the LLVM JIT for numerical work. I really don't see how Julia is relevant anymore.

Python really doesn't (and cannot) address many of the design goals of Julia. At least as I understand them (and I'm not a Julia user). Whether or not Julia has/will achieve them either is a separate issue.

Python can be a very useful mess for this sort of work (numerical analysis etc.), and is succeeding at that quite well. In fact, that's it's main challenge to something like Julia. Not design, that ship sailed a long time ago. But practicality and availability of packages and bindings. Once you get too far ahead in that, it's hard to justify using any other platform for "real work", rather than because it's fun to hack on.

Re: Giving up on Julia

#25

Post by KenoFischer »

rch wrote: post #22
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…

I liked how the Template Numerical Toolkit implemented one-based indexing: // Construct matrix. Elements are not initialized. // To initialize all elements to zero use // Matrix a(2, 2, 0.0). Matrix a(2, 2); // Assign elements to first row using // Fortran-style one-based indexing. a(1,1) = 0.5; a(1,2) = 1.0; // Assign elements to second row using // C-style zero-based indexing. a[1][0] = 1.5; a[1][1] = 2.0; -- http:…

This syntax is available in julia as well, but I'm not sure it's a great idea to encourage mixing the two indexing behaviors, even if they have different syntax. As I hinted in the original reply, I have seen very few cases where the choice of index offset actually makes a difference. For example, loops over indices generally use `eachindex` which doesn't care about your choice of index base.

Re: Giving up on Julia

#27

Post by 3JPLW »

metrognome wrote: post #17

When the author compares the number of CPU instructions that sprintf compiles to in both C and Julia, he fails to take into account dynamic linking in C: jmp __sprintf_chk I would guess that another few hundred instructions run as a result of this jmp. Thus, the difference in the number of instructions that C's sprintf and Julia's @sprintf compile to are not as drastic as the author makes it seem.

Also note that the author asks for the native code for arguments of type `(AbstractString, Float64)`. The first is an abstract type — which means that this code will never get called in the first place. Julia will resolve the type of the string, and then dispatch to the concrete implementation. Which, for an ASCIIString, is 3x shorter.

Re: Giving up on Julia

#28

Post by armamut »

I love python and I don't like Julia at all.

But, I think judging a language (which claims math and scientific computing is it's strongest point) by print screen performance is not fair.

And, the authors last example is a little bit misleading I think. The C code sets up registers and jumps to the main sprintf routine. I don't know why didn't he tell that routine's instructions count...

Has any one counted?

Re: Giving up on Julia

#29

Post by armamut »

armamut wrote: post #28

I love python and I don't like Julia at all. But, I think judging a language (which claims math and scientific computing is it's strongest point) by print screen performance is not fair. And, the authors last example is a little bit misleading I think. The C code sets up registers and jumps to the main sprintf routine. I don't know why didn't he tell that routine's instructions count... Has any one counted?

Oh. I think metrognome had shown the point. Didn't read it. sorry.

Re: Giving up on Julia

#30

Post by zintinio5 »

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 within 3-4 hours, AND it was easy to parallelize.
Post reply on HN