Julia 1.6 addresses latency issues • Hacker News Board

Re: Julia 1.6 addresses latency issues

#141

Post by adgjlsfhk1 » Fri, May 28, 2021, 6:10 AM UTC

lmm wrote: post #107

oscardssmith wrote: post #106

Earlier quoted context omitted.

If you want a harder guarantee, well written numerical code will be as fast as any other language. If you find a counter example, let us know (it's probably something that should be fixed). For string processing and other gc heavy code, Julia has further to go. Julia's gc is pretty basic, and needs a lot of love. That said, for dataframes like workloads, Julia usually manages to hand with the best (data.table), and i…

My assumption is that there's nothing outstanding or remarkable about Julia's performance. Comparing to Python/Perl/Ruby/TCL is a good way to make any language seem fast, and comparing to C++ is a good way to make any language seem expressive. I'd be far more interested to hear about comparisons with alternatives that might actually be competitive - non-scripting languages with a reputation for being expressive, such…

For a non-numerical benchmark where Julia does really well, you should also check out https://h2oai.github.io/db-benchmark/. There's a bunch of work to be done to improve DataFrames.jl more, but it's already one of the fastest tools for what it does (despite having only reached version 1.0 a few weeks ago).

Re: Julia 1.6 addresses latency issues

#142

Post by lmm » Fri, May 28, 2021, 6:38 AM UTC

adgjlsfhk1 wrote: post #141

lmm wrote: post #107

Earlier quoted context omitted.

My assumption is that there's nothing outstanding or remarkable about Julia's performance. Comparing to Python/Perl/Ruby/TCL is a good way to make any language seem fast, and comparing to C++ is a good way to make any language seem expressive. I'd be far more interested to hear about comparisons with alternatives that might actually be competitive - non-scripting languages with a reputation for being expressive, such…

For a non-numerical benchmark where Julia does really well, you should also check out https://h2oai.github.io/db-benchmark/ . There's a bunch of work to be done to improve DataFrames.jl more, but it's already one of the fastest tools for what it does (despite having only reached version 1.0 a few weeks ago).

Ok, that's a little more interesting - a "neutral" benchmark of several tools, though still very much in a niche use case.

Is there any effort to include Julia in the TechEmpower Benchmarks? If it's trying to be a general-purpose language, that's the first place I'd look.

Re: Julia 1.6 addresses latency issues

#143

Post by lmm » Fri, May 28, 2021, 6:43 AM UTC

adgjlsfhk1 wrote: post #140

lmm wrote: post #107

Earlier quoted context omitted.

My assumption is that there's nothing outstanding or remarkable about Julia's performance. Comparing to Python/Perl/Ruby/TCL is a good way to make any language seem fast, and comparing to C++ is a good way to make any language seem expressive. I'd be far more interested to hear about comparisons with alternatives that might actually be competitive - non-scripting languages with a reputation for being expressive, such…

If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written. Furthermore, Julia has…

> If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written.

That seems to be very Julia-specific comparisons, which I'm sure will be oriented towards the use cases Julia has been designed for. I'm more interested in "neutral" benchmarks and more general-purpose computing areas.

> Furthermore, Julia has been used on some of the world's fastest super-computers (in the performance critical bits), which as far as I know isn't true of Swift/Kotlin/C#.

That's more a reflection of culture than performance though. Back when I worked with a bunch of data scientists they would happily run Python or R on our Spark cluster, consuming oodles of resources to do not very much, but balked at writing Scala, even though their code would have run much faster.

Re: Julia 1.6 addresses latency issues

#144

Post by adgjlsfhk1 » Fri, May 28, 2021, 7:18 AM UTC

lmm wrote: post #142

adgjlsfhk1 wrote: post #141

Earlier quoted context omitted.

For a non-numerical benchmark where Julia does really well, you should also check out https://h2oai.github.io/db-benchmark/ . There's a bunch of work to be done to improve DataFrames.jl more, but it's already one of the fastest tools for what it does (despite having only reached version 1.0 a few weeks ago).

Ok, that's a little more interesting - a "neutral" benchmark of several tools, though still very much in a niche use case. Is there any effort to include Julia in the TechEmpower Benchmarks? If it's trying to be a general-purpose language, that's the first place I'd look.

It's already on there for some of the benchmarks at least. It generally is roughly between 30th and 60th place depending on the benchmark (with outliers in both directions). That said, HTTP.jl is not a library that has had a ton of work in Julia, and it's probably not what you want to write a high performance webserver in at the moment. I don't think this is a fundamental limitation, but just a domain that needs a couple thousand dev hours to make competitive with some of the more mature frameworks. Another part of the problem is that Julia has some fairly well known garbage collection performance problems. GC performance hasn't been a major dev priority as of yet, since the language is much better than most high level languages at eliding allocations or stack allocating variables (so it doesn't make as much garbage for many workflows). That said, for GC heavy tasks (string stuff often is), it is a major problem that is starting to get a bunch of effort put into it. Hopefully in a year or 2, these issues will be solved. It's nothing too fundamental, just that the current GC only has 2 generations, and the heuristics for moving objects between generations are not tuned especially well.

Re: Julia 1.6 addresses latency issues

#145

Post by adgjlsfhk1 » Fri, May 28, 2021, 7:28 AM UTC

lmm wrote: post #143

adgjlsfhk1 wrote: post #140

Earlier quoted context omitted.

If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written. Furthermore, Julia has…

> If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa ... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written. That seems to be ver…

That's fair. That said, the fact that writing a BLAS implementation in a high level language seems like a favorable benchmark does kind of show my point that for numerical computing, Julia is really fast (especially for a high level language).

As a general purpose language, I'd probably categorize Julia as fast, but not crazy fast. Numerical computing is definitely where most of the man hours have gone into development. As a general purpose language, Julia probably ends up at around the same place as C# (not as fast as C++, but still pretty respectable). That said, this is an area where the main thing Julia needs here is more optimization on some of the libraries that already exist, and some new libraries to extend the language's reach further. I don't think there's anything fundamental holding it back from getting closer to C++ performance in general computing. It uses the same compiler (LLVM), and it's pretty clear that you can get Julia to output the same assembly code. It's just a matter of having enough devs pushing ecosystem forward.

Re: Julia 1.6 addresses latency issues

#146

Post by ChrisRackauckas » Fri, May 28, 2021, 10:00 AM UTC

jampekka wrote: post #135

mbauman wrote: post #134

Earlier quoted context omitted.

And this is precisely why this dynamic exists — because there are workflows with far less friction than what you've experienced. I and others successfully use them every day for things far more complicated than one-off analyses. I think your view of Julia as a "fancy calculator" may be part and parcel to the difficulty. I do use it as a fancy calculator, but I also use local packages all the time — and that's where y…

Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow se…

>Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to being just stupid or something. But this is how it comes off to me, I think you mean something else, but I don't know what that is.

No, you're not stupid. You've correctly identified current flaws in the tools, and the community tries to lead you to the tools that are known to work well in spite of the issues. We need to work a little bit more on the other tools to make them as good, but large parts of the community are just not the right people to work on that problem. It's not a design problem, it's fixable, but you just have more people who know how to make new differential equation solvers than you have people who can compile a binary, so the tooling ecosystem moves at a different pace from the scientific packages. This is changing with the help of some commercialization aspects though, but it is something we have to be cognizant of.

Re: Julia 1.6 addresses latency issues

#147

Post by dklend122 » Fri, May 28, 2021, 2:18 PM UTC

acmj wrote: post #139

jampekka wrote: post #135

Earlier quoted context omitted.

Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow se…

Couldn't agree more. What you said is a design flaw that the Julia community keeps denying. The Julia community also behaves defensively when it comes to performance. They refuse to accept that Julia doesn't compete with C/Rust on many non-numeric tasks in the real world. In addition, the Julia community has its own circle, its own style to write code. They will trash your code even if it is efficient and logically c…

Can you please post a pointer to the thread in question?

Re: Julia 1.6 addresses latency issues

#148

Post by acmj » Fri, May 28, 2021, 2:46 PM UTC

dklend122 wrote: post #147

acmj wrote: post #139

Earlier quoted context omitted.

Couldn't agree more. What you said is a design flaw that the Julia community keeps denying. The Julia community also behaves defensively when it comes to performance. They refuse to accept that Julia doesn't compete with C/Rust on many non-numeric tasks in the real world. In addition, the Julia community has its own circle, its own style to write code. They will trash your code even if it is efficient and logically c…

Can you please post a pointer to the thread in question?

Sorry, I would like to keep my online anonymity.

Re: Julia 1.6 addresses latency issues

#149

Post by acmj » Fri, May 28, 2021, 3:07 PM UTC

ChrisRackauckas wrote: post #146

jampekka wrote: post #135

Earlier quoted context omitted.

Friction in general, or friction specific to Julia? My view is that Julia (and R and Matlab etc) ecosystem's view is a "fancy calculator". It's hard to integrate to anything else, it almost actively tries to make e.g. unix-type workflow difficult (not much CLI, everything done in REPL, e.g. package management). Not as bad as e.g. R where its almost impossible to just run a file of code instead of doing a "workflow se…

>Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to bei…

IMO, if Julia lacks the necessary tooling, don't over-advertise it. When I say the lack of static compilation is a design problem, I mean such a critical feature should be in v1.0. Without it, many common tasks in other languages become difficult in Julia. For language adoption, you often only have one chance. If you push someone away, it is much harder to win them back.

Re: Julia 1.6 addresses latency issues

#150

Post by eigenspace » Fri, May 28, 2021, 7:39 PM UTC

acmj wrote: post #149

ChrisRackauckas wrote: post #146

Earlier quoted context omitted.

>Perhaps there is some disconnect in how different parties of the discussion see the whole thing. For me this sounds a lot like "you're holding it wrong". What background are you coming from and what languages/programming environments you are familiar with? I get the impression that you don't have much general purpose programming background and somehow tend to assume that people are using "wrong workflows" due to bei…

IMO, if Julia lacks the necessary tooling, don't over-advertise it. When I say the lack of static compilation is a design problem, I mean such a critical feature should be in v1.0. Without it, many common tasks in other languages become difficult in Julia. For language adoption, you often only have one chance. If you push someone away, it is much harder to win them back.

IMO, you are overestimating how big a deal static compilation is. Yes, there are usecases where it's important, but acting like a language shouldn't tag version 1.0 without static compilation just sounds ignorant and self centred.

The world is bigger than you.