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

Making Julia as Fast as C++ (2019)

flow.byu.edu

Post reply on HN
Print view View original

31–40 of 64 posts

Re: Making Julia as Fast as C++ (2019)

#31

Post by arbitrandomuser »

kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

yup the LSP is bad, there is a new lsp being rewritten based on JET.jl a static code analyzer , this should be faster than the old lsp which kind of runs by loading all the modules into a julia instance and queries it for symbols and docs ( im not 100% sure but i think thats how it works)

Re: Making Julia as Fast as C++ (2019)

#32

Post by arbitrandomuser »

celrod wrote: post #30
StilesCrisis wrote: post #5

Punchline: rewrote the code to look almost identical to C++, hand-held the compiler by adding @-marks to disable safety checks, forced SIMD codegen and fastmath on. End result: code that is uglier and still much slower than C++. Kind of a shame.

I was once a bit of a Julia performance expert, but moved toward c++ for hobby projects even while still using Julia professionally. I wrote a blog post at the time with exactly that punchline (not explicitly stated, but just look at the code!): https://spmd.org/posts/multithreadedallocations/ The example was similar to a real production-critical hot path from work. Maybe things changed since I left Julia, but that w…

hey , what happened to LoopModels ?

Re: Making Julia as Fast as C++ (2019)

#33

Post by kelipso »

2ndorderthought wrote: post #21
postflopclarity wrote: post #19

Earlier quoted context omitted.

the parent company is a consumer of Julia, and has no formal role in oversight or governance; they are of course invested in the success and performance of the language, but so are all other users!

Seems kind of contradictory with the other comment which states that they decide what features are prioritized. I guess not because it could be an informal process. It's interesting. I like the more opaque approach rust takes. Rust has its own issues but it seems less corporately motivated. Maybe that's why it has more corporations using it? You aren't going to end up with the core maintainers to the language rug pul…

> I like the more opaque approach rust takes. Rust has its own issues but it seems less corporately motivated. Maybe that's why it has more corporations using it?

I don’t if these are contradictory exactly but it seems to come from a very cluttered space.

Re: Making Julia as Fast as C++ (2019)

#34

Post by celrod »

arbitrandomuser wrote: post #32
celrod wrote: post #30

Earlier quoted context omitted.

I was once a bit of a Julia performance expert, but moved toward c++ for hobby projects even while still using Julia professionally. I wrote a blog post at the time with exactly that punchline (not explicitly stated, but just look at the code!): https://spmd.org/posts/multithreadedallocations/ The example was similar to a real production-critical hot path from work. Maybe things changed since I left Julia, but that w…

hey , what happened to LoopModels ?

I'm still working on it. I'm currently working on a cache tile-size optimization algorithm that should (a) handle trees (a set of loops can be merged at some cache levels and split at others, e.g. in an MLP it may carry an output through the L3 cache, while doing sub-operations in the L2/L1/registers) (b) converge reasonably quickly so compile times are acceptable.

This is the last step before I move to code generation and then generating a ton of test cases/debugging.

My goal is some form of release by the end of the year.

Re: Making Julia as Fast as C++ (2019)

#35

Post by arbitrandomuser »

celrod wrote: post #34
arbitrandomuser wrote: post #32

Earlier quoted context omitted.

hey , what happened to LoopModels ?

I'm still working on it. I'm currently working on a cache tile-size optimization algorithm that should (a) handle trees (a set of loops can be merged at some cache levels and split at others, e.g. in an MLP it may carry an output through the L3 cache, while doing sub-operations in the L2/L1/registers) (b) converge reasonably quickly so compile times are acceptable. This is the last step before I move to code generati…

oh , is it closed source now ? i couldnt find it on github anymore , github.com/LoopModels returns a 404.

Re: Making Julia as Fast as C++ (2019)

#36

Post by kelipso »

ekjhgkejhgk wrote: post #24

Phew. 7-year old post about a 10-year old language. Triggers all the LLMs posting empty generic response "Very interesting, exposes limitations...". Prelude of what's to come in the self-reinforcing cycle of machines talking to machines and drowning everything else.

It's a very predictable pattern I swear. Thought it was a mostly reddit thing but dead internet theory looking more and more real even here.

Re: Making Julia as Fast as C++ (2019)

#37

Post by jakobnissen »

kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

The boring answer is that I don’t use huge dependencies that takes minutes to compile, and I don’t lean on the LSP - I tend to put more effort in reading the code.

In my experience you really gotta work with the tools the language gives you. Julia gives you Revise, so it’s a bit of a handicap not using it. Maybe analogous to writing Rust without an LSP.

I get that leaning on the LSP can become a habit, and also that the Julia LSP is quite poor, but I find it wild that rapid iteration for you is faster in Rust. I write Rust as well and can’t imagine how that would be the case.

Re: Making Julia as Fast as C++ (2019)

#38

Post by tialaramex »

HarHarVeryFunny wrote: post #15
SatvikBeri wrote: post #11

Earlier quoted context omitted.

This is 7 years old. Julia is a totally different language by now. As a quick anecdote, in our take-home interview exercise, we usually receive answers in C++ or Julia, and the two fastest answers have been in Julia.

I'd have to guess that this is because of ease of use. C++ lets you get as close to the metal as you choose to, so there is no reason why a C++ solution shouldn't be at least as fast as one written in any other language, and yet ... Of course it also depends on what additional libaries you are using, especially when it comes to parallel/GPU programming in C++, but easy to believe that Julia out of the box makes it ea…

> C++ lets you get as close to the metal as you choose to

This only ends up being true (for any language, but it's too often cited for C++) in a pretty useless Turing Tarpit sort of sense.

So it's not "no reason" it's just sometimes impractical to solve some problems as well in C++ as in a language that was better suited.

Now people do do impractical things sometimes. It's not very practical to swim across the English channel, but people do it. It's not very practical to climb Mt Everest, but loads of people do that for some reason. Going to the moon wasn't practical but the Americans decided to do it anyway. But the reason even the Americans stopped going for a long time is that actually "that was too hard and I don't want to" is in fact a reason.

Re: Making Julia as Fast as C++ (2019)

#39

Post by thimotedupuch »

arbitrandomuser wrote: post #31
kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

yup the LSP is bad, there is a new lsp being rewritten based on JET.jl a static code analyzer , this should be faster than the old lsp which kind of runs by loading all the modules into a julia instance and queries it for symbols and docs ( im not 100% sure but i think thats how it works)

Exactly ! The new LSP is getting ready https://github.com/aviatesk/JETLS.jl/ with one of the compiler devs working hard on it. I tried it with VSCode, Zed and Helix and it's more than fine already.

I hope julia developper tools will one day match the best of what other programming languages have to offer.

Re: Making Julia as Fast as C++ (2019)

#40

Post by lelanthran »

kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

> Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried)

Good LSPs do the autocompletion, sub par ones don't.

Is it really such a good idea to have every single automated aid turned on when picking up a new language?

How will you learn if you cannot get feedback on what you did wrong?

I mean, until you learn multiplication, maybe don't use the calculator.

Once you learn it then you get a small speed increase, but if you are new to something, LSP autocompletion is going to slow down your learning.

Post reply on HN