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

21–30 of 64 posts

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

#21

Post by 2ndorderthought »

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

Earlier quoted context omitted.

I don't get the appeal. It's like a. OSS Matlab but all contributions are used directly so the language developers can make money for a parent company? Most OSS languages aren't run that way. Seems kind of scammy

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 pulling packages or language features to slow down competition who are also using the tool. I say competition because it looks like they are making money through consultancies and very broad applications of the niche language.

Weird stuff to have to think about. I just want to write code

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

#22

Post by cmrdporcupine »

2ndorderthought wrote: post #12
cmrdporcupine wrote: post #10

Earlier quoted context omitted.

There's simply no way it'd ever have similar performance to those. It's not possible. I have always seen it as a potential alternative to Java, and definitely better than Python. My experience working in it professionally was that it was... fine. But the GC in it was not good under load and not competitive with Java's.

How hard was it to maintain a large Julia code base rather then say an OOP or Rust one? It has an interesting paradigm. I feel like it could get really messy

I personally think it requires discipline, I saw it go both ways.

I was never an expert in the language, but worked along people who were and they generally made nice code.

But there were a few places where I saw intensely confusing patterns from overloading with multimethods. Code that became hard to follow, and had poor encapsulation.

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

#23

Post by csvance »

2ndorderthought wrote: post #9
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 don't get the appeal. It's like a. OSS Matlab but all contributions are used directly so the language developers can make money for a parent company? Most OSS languages aren't run that way. Seems kind of scammy

Your baseline for comparison is a company that doesn't give anything away for free?

Also, contributing in open source is a choice, not a mandate. I greatly benefit from Julia and its ecosystem so I chose to contribute back some of my work, no one forced me. I chose the MIT license because I want other people to be able to make money with it, just like I make money with other peoples MIT licensed stuff.

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

#24

Post by ekjhgkejhgk »

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.

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

#25

Post by KenoFischer »

2ndorderthought wrote: post #9
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 don't get the appeal. It's like a. OSS Matlab but all contributions are used directly so the language developers can make money for a parent company? Most OSS languages aren't run that way. Seems kind of scammy

It always amuses me when people assume that the nefarious scheme is taking open source contributions and selling them. That's not the nefarious scheme. The nefarious scheme is going to partners, funding agencies and investors and saying "look at this unique capability / important research / profitable business opportunity that we can do together, but oops, all of our code is written in Julia, so I guess we better pay some people to maintain it so it'll all come crashing down, wouldn't want that to happen".

Also, I'm of course using nefarious in jest here in both cases. While we don't directly try to monetize our open source work, I respect that sometimes people need to do that. As long as people are transparent about it, I don't have a problem. Doing the thing we're doing seems to work, but it's a lot harder, because you have to build a successful pice of software and a (or multiple) successful something elses that has a critical dependency on it. It's like hitting the lottery twice.

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

#26

Post by orthogonal_cube »

Dang, haven’t read much on Julia as of late. I remember using it for a CS 300-level course around 2016 when learning about tokenizing and parsing as part of language fundamentals. Julia has undoubtedly made some significant performance improvements since then. Would love to see a follow-up that explores what, if anything, from this still holds true and what improvements can be made.

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

#27

Post by 2ndorderthought »

KenoFischer wrote: post #25
2ndorderthought wrote: post #9

Earlier quoted context omitted.

I don't get the appeal. It's like a. OSS Matlab but all contributions are used directly so the language developers can make money for a parent company? Most OSS languages aren't run that way. Seems kind of scammy

It always amuses me when people assume that the nefarious scheme is taking open source contributions and selling them. That's not the nefarious scheme. The nefarious scheme is going to partners, funding agencies and investors and saying "look at this unique capability / important research / profitable business opportunity that we can do together, but oops, all of our code is written in Julia, so I guess we better pay…

I wouldn't say nefarious, but I don't know how I feel about the power structure. I could see it being very much a one way venture for most participants. I'd have to think about it before actually using the language.

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

#28

Post by kmaitreys »

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 intention is not write scripts, but high performance numerical/scientific code, and with Julia's JIT-based design, rapid iteration (to me at least) feels slower than Rust (!).

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

#30

Post by celrod »

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 was December 2023, for years after this blog post.

Post reply on HN