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

Julia adoption keeps climbing

hpcwire.com

Post reply on HN
Print view View original

51–60 of 309 posts

Re: Julia adoption keeps climbing

#51

Post by kuter »

Julia uses modern compiler technology to achieve close to native performance. This is not just generating LLVM IR. Julia also has it's own optimization system for language specific optimizations that LLVM struggle to do (due to language specific info getting lost in conversion to LLVM IR).

Google's V8 (js interpreter) also uses modern compiler tech but I think it is not as capable as LLVM optimization vise (I don't think it is designed to be).

Python will either adapt or perish. Even if it is not julia it would be a another language.

Re: Julia adoption keeps climbing

#52

Post by fsh »

sgt101 wrote: post #27
fsh wrote: post #24

Earlier quoted context omitted.

Julia is amazing for numerics, but the JIT is painfully slow for anything that gets looped only a few times or not at all. I don't think it is usable as a general purpose language until this gets improved somehow.

But is that a problem apart from in scripting? If you ain't looping you ain't waiting in my experience.... Can you give an example which isn't time to plot?

I think that a slow JIT is problematic in any application except for non-interactive numerical calculations. For example in a GUI software or in a server application it would be very undesirable to have each function run a million times slower the first time it gets called.

Re: Julia adoption keeps climbing

#53

Post by sradman »

KenoFischer wrote: post #38
sradman wrote: post #25

> It will be important for it to be adopted as a first-class target language by CPU/GPU vendors.” I’m not sure what the Apple M1 SoC with AMX [1] means for Julia within the Apple ecosystem. [1] https://news.ycombinator.com/item?id=25801500

I'm expecting somebody to add them to LLVM soon. I'd talked to folks at Apple about that some time back, but they weren't able to tell me at the time what their plans were for adding it. That said, I am fully expecting them to just add it to LLVM themselves. If not, somebody in the community will do it. Once that's done, Julia will just pick it up.

> add them to LLVM soon

I’m not sure what “them” is. Apple has AMX, a Neural Engine, and a GPU which are abstracted through the Core ML and Accelerate libraries.

AMX is not exposed as an instruction set like NEON. I guess this question applies to all of the numerical analysis tool chains: will they be able to leverage Apple silicon coprocessors/accelerators?

Re: Julia adoption keeps climbing

#54

Post by pansa2 »

kuter wrote: post #51

Julia uses modern compiler technology to achieve close to native performance. This is not just generating LLVM IR. Julia also has it's own optimization system for language specific optimizations that LLVM struggle to do (due to language specific info getting lost in conversion to LLVM IR). Google's V8 (js interpreter) also uses modern compiler tech but I think it is not as capable as LLVM optimization vise (I don't t…

V8 and the Julia compiler work in quite different ways - because they solve quite different problems. In particular, Julia’s compiler only works well on code that is "type-stable", whereas V8 has no such limitation.

Re: Julia adoption keeps climbing

#55

Post by KenoFischer »

sradman wrote: post #53
KenoFischer wrote: post #38

Earlier quoted context omitted.

I'm expecting somebody to add them to LLVM soon. I'd talked to folks at Apple about that some time back, but they weren't able to tell me at the time what their plans were for adding it. That said, I am fully expecting them to just add it to LLVM themselves. If not, somebody in the community will do it. Once that's done, Julia will just pick it up.

> add them to LLVM soon I’m not sure what “them” is. Apple has AMX, a Neural Engine, and a GPU which are abstracted through the Core ML and Accelerate libraries. AMX is not exposed as an instruction set like NEON. I guess this question applies to all of the numerical analysis tool chains: will they be able to leverage Apple silicon coprocessors/accelerators?

I was talking specifically about the ARM ISA extensions. The accelerators are a different question of course. I understand the folks working on the Linux port are trying to reverse the GPU ISA. Apple could of course also just publish that, but I'd put the odds on that lower than the ISA extensions. That said, Apple has sometimes surprised me on these kinds of things.

Re: Julia adoption keeps climbing

#56

Post by oefrha »

pansa2 wrote: post #49
oefrha wrote: post #40

Earlier quoted context omitted.

I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked…

> prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-lev…

Nim? I know it has Python-like syntax and aims to be performant, but don’t know much beyond that.

Re: Julia adoption keeps climbing

#57

Post by komuher »

cricci16 wrote: post #8

In my modest experience the perfect Julia slogan would be: "fast as C, easy as python, but NEVER the two together" All the sentences: "When you’re writing various algorithms, you don’t necessarily want to think about whether you’re on a GPU, or whether you’re on a distributed computer. You don’t necessarily want to think about how you’ve implemented the specific data structure. What you want to do is talk about what…

This is my favourite comment about julia for like last few years +1 on that.

Ecosystem is extremly poor outside very few niches and most of the Deep Learning stuff isn't even faster than python api (+C ofc.) so swaping is just usless if u dont have time to write your own GPU kernals for every new opertaion.

Re: Julia adoption keeps climbing

#58

Post by mlthoughts2018 »

pansa2 wrote: post #49
oefrha wrote: post #40

Earlier quoted context omitted.

I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked…

> prototyped in Python, then ported to C++ This need to rewrite, of course, is what Julia is trying to avoid. My workflow is exactly the same, and I’d love to be able to write code in a high-level language like Python and then use that directly instead of having to rewrite. However, in my case the reason for rewriting isn’t just performance, but also to be able to build compiled binaries. Julia aims to be as high-lev…

Cython - in fact I think in 2021 if you want to write a pure C or pure C++ program, Cython is the best way to go, and just disable use of CPython.

The “need to rewrite” is actually a sort of advantage with Cython. You only target small pieces of your program to be compiled to C or C++ for optimization, and the rest where runtime is already fast enough or otherwise doesn’t matter, you seamlessly write in plain Python.

Using extension modules is just a time-tested, highly organized, modular, robust design pattern.

Julia and others do themselves a disservice by trying to make “the whole language automatically optimized” which counter-intuitively is worse than make the language overall optimized for flexibility instead of speed, yet with an easy system to patch optimization modules anywhere they are needed.

Re: Julia adoption keeps climbing

#59

Post by bsdubernerd »

oefrha wrote: post #40
bsdubernerd wrote: post #29

Earlier quoted context omitted.

I second this. Python is actually starting to get significant traction in the scientific community. Depending on the field, R, Fortran and Matlab (and even C++) still have a huge lead. It's nice that Julia is getting noticed, but it's a distant blip in the radar. The sci community is really hard to move from existing battle-tested and performant libraries.

I don’t have much insight on the scientific computing landscape in general, but here’s one notable data point: I worked on the CMS experiment of LHC (Large Hadron Collider) for a while, which is one of the highest profile experiments in experimental physics. The majority of CMS code is C++, which you can check for yourself at https://github.com/cms-sw/cmssw (yes, much/most? of the code is open source). What I worked…

Just for reference, my experience is mostly computational genomics. R is king of analysis, and most of the actual "meat" is implemented in C++. But I work with other teams as well, so the experience is a bit more varied if you look across different areas.

Re: Julia adoption keeps climbing

#60

Post by sgt101 »

fsh wrote: post #52
sgt101 wrote: post #27

Earlier quoted context omitted.

But is that a problem apart from in scripting? If you ain't looping you ain't waiting in my experience.... Can you give an example which isn't time to plot?

I think that a slow JIT is problematic in any application except for non-interactive numerical calculations. For example in a GUI software or in a server application it would be very undesirable to have each function run a million times slower the first time it gets called.

For GUI's I don't see this as an issue - JITs run alot faster than humans. All of Javascript is on a JIT - and thats the dominant UI for now! For servers generally you find that users are all calling the same function so it's very rare that you hit a blip - much more commonly users get performance problems from something else in the stack like the network or the client, and while Javascript is the dominant front end the dominant back end for servers is Java and that's got a JIT as well.
Post reply on HN