6 ms·

Making Julia as Fast as C++ (2019)

86 points by d_tr 5mo ago

slwvx 5mo ago
From 2019
ForceBru 5mo ago
Recent discussion on Julia Discourse: https://discourse.julialang.org/t/making-julia-as-fast-as-c/ https://discourse.julialang.org/t/making-julia-as-fast-as-c/
deleted 5mo ago
[deleted]
StilesCrisis 5mo ago
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.
- brabel 5mo ago
  > code that is uglier and still much slower than C++. Oh such a shame indeed! They didn’t even manage to produce better looking code at least?? Julia was looking great in 2019 but it was very buggy still so I stopped looking. Had hopes that by now it would be a good choice over C++ and Rust with similar performance.
  - cmrdporcupine 5mo ago
    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.
    - 2ndorderthought 5mo ago
      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
      - andyferris 5mo ago
        Personally I never struggled. You can employ interfaces and maintain them judiciously. But interfaces are informal. Not using a monorepo say makes it harder to be sure if your broke downstream or not (via downstream’s unit tests). But freedom from Rust’s orphan rule etc means you can decompose large code into fragments easily, while getting almost Zig-style specialisation yet the ease of use of python (for consumers). I would say this takes a fair bit of skill to wield safely/in a maintainable fashion though, and many packages (including my own) are not extremely mature.
      - cmrdporcupine 5mo ago
        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.
    - csvance 5mo ago
      From the sound of your post I'm guessing you view Julia as a general purpose language. I'd consider it general purpose insofar as the application leans into fast numerical computing, everyone else secondary. It can do most of the things other languages do reasonably well, but that's not why you would pick Julia for a project over say Java. You pick it because you want to write fast numerical code and express it elegantly. All of the other typical "glue" things you need to ship a product are secondary to that, but good enough to get the job done. The key to performance with the GC in Julia is not allocating, but it has gotten substantially better since 2019.
- 2ndorderthought 5mo ago
  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
  - andyferris 5mo ago
    Meh, I’ve never been associated with the company and AFAICT they provide value through platforms for enterprises. Not everyone gets OSS sponsorships to fund team (and using a social media presence to achieve this was a post-Julia phenomenon). It’s nothing like Google-the-ad-company influencing Chrome. The company consumes Julia for products to sell, rather. Maybe this affects the ordering of features landing, but… meh.
  - postflopclarity 5mo ago
    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!
    - 2ndorderthought 5mo ago
      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
      - kelipso 5mo ago
        > 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.
- SatvikBeri 5mo ago
  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.
  - d_tr 5mo ago
    > This is 7 years old. Yeah, I actually totally forgot to check the date...
  - HarHarVeryFunny 5mo ago
    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 easy to write high performance parallel software.
    - tialaramex 5mo ago
      > 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.
      - sheepscreek 5mo ago
        Drawing from the analogies, what’s the Julia equivalent of them?
- neutrinobro 5mo ago
  Hardly seems worth the effort, perhaps things have improved since 2019. It would be interesting to see an updated benchmark, but if your going to end up with code that looks like C++ to get proper performance, you might as well write it in C++. My biggest problem with Julia is that they decided to use column-major indexing for multi-dimensional arrays (i.e. FORTRAN/MATLAB style). This makes interoperability with C/C++ and python numpy a real pain, since you can't do zero-copy array sharing between the two without one side being forced into strided-access. For that reason alone I haven't adopted it in any of my work-flows.
  - csvance 5mo ago
    Just reverse the axis on one side, typically the Julia side. This is the convention used in Lux.jl/Flux.jl. I share memory between the two with zero additional copying for my workflows on a daily basis. If you are really allergic to doing this, I’m sure it’s possible to use metaprogramming / the type system to write it the same way in both places with zero performance overhead.
  - adrian_b 5mo ago
    Actually the column-major order of Fortran is more efficient for some linear algebra operations than the order of C, which has been inherited by many modern languages that do not care about high performance in scientific computations. So I would say that the culprit for interoperability is C and its descendants, not Fortran or Julia. The designers of C and of the languages that have imitated C have not given any thought about which order for multi-dimensional arrays is better, so the users of such languages do not have any right to blame for interoperability other languages that have done the right thing. Even if the Fortran order had not been better, it had already been used for 20 years before C, so there was no reason to choose a different order. C has chosen to store arrays in the order in which they are typically read by humans when written on paper, but this is a choice like the choice between big-endian and little-endian, where big-endian was how Europeans wrote numbers, but little-endian is more efficient on computers. An example of why column-major order is preferable, is the matrix-vector product, i.e. the evaluation of a function that maps linear spaces. The matrix-vector product should not be done as it is typically taught in schools, by scalar products of rows of the matrix with the vector, because this is less efficient, by making more memory accesses. The right way to compute a matrix-vector product is by doing AXPY operations between columns of the matrix and the vector operand (segments of the output of the AXPY operations are held in registers until all partial AXPY operations are accumulated, avoiding memory accesses). In this case, you need to read columns of the input matrix for each AXPY operation, which is much more efficient when the elements of a column are stored compactly in memory, avoiding the need of strided accesses. The same thing happens for matrix-matrix products, which must not be done in the naive way taught in schools, by scalar products of rows of the first matrix with columns of the second matrix, but it must be done by tensor products of columns of the first matrix with rows of the second matrix.
- celrod 5mo ago
  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/ 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.
  - arbitrandomuser 5mo ago
    hey , what happened to LoopModels ?
    - celrod 5mo ago
      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.
      - arbitrandomuser 5mo ago
        oh , is it closed source now ? i couldnt find it on github anymore , github.com/LoopModels returns a 404.
        celrod 5mo ago
        Yeah, for now. I'd like it to be open, but I also want to potentially be able to make money/a living off of it. My dream would be that it can be open while hardware vendors pay me to optimize for their hardware. For how, being closed gives me more options. It's a lot easier to open in the future than to close, so it's just keeping options open. I've thought a lot more about the engineering than any sort of marketing or businesses plan, so I just want to defer those.
- drnick1 5mo ago
  Came here to say that. It's just easier to write C++ in the first place, and LLMs now make this easier than ever.
FattiMei 5mo ago
Very interesting post and I think this exposes the limitations of the Julia compiler. Note that an old version of the compiler is used (1.0.3 from 2019). One could say that we can almost replicate the semantic of a C++ program, but writing in Julia. For example we can remove bounds checks in arrays or remove hidden memory allocations. But the goal of a language for numerical computing is capturing the mathematical formulas using high level constructs closer to the original representation while compiling to efficient code. Domain scientists want to play with the math and the formulas, not doing common subexpression elimination in their programs. Just curious to see how it evolves
- northzen 5mo ago
  I think the best compromise would be to get the best of two words. By default perform bound checks, but have a compiler flag which skips it. Might broke many programs written with default behaviour in mind, but allow perform additional optimizations.
  - postflopclarity 5mo ago
    this is exactly what julia does. boundschecks are default on, and there are compiler flags --- either locally, via the `@inbounds` macro, or globally with `--check-bounds=no`--- to disable them
ekjhgkejhgk 5mo ago
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.
- kelipso 5mo ago
  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.
orthogonal_cube 5mo ago
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.
kmaitreys 5mo ago
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 (!).
- arbitrandomuser 5mo ago
  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)
  - thimotedupuch 5mo ago
    Exactly ! The new LSP is getting ready https://github.com/aviatesk/JETLS.jl/ 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.
- jakobnissen 5mo ago
  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.
  - 5mo ago
kasperset 5mo ago
I wonder how Mojo ranks along with Julia. Mojo was discussed yesterday here. Mojo seems to be more python focused while Julia is very much focused on Scientific computation. I may be wrong.
mgkuhn 5mo ago
I'm always surprised when people describe Julia syntax as "Pythonic": Julia's syntax was clearly inspired by MATLAB rather than Python. And that's a good thing, because Python+NumPy syntax is far more cumbersome than either Julia or MATLAB's. You can see this at a glance from this nice trilingual cheat sheet: https://cheatsheets.quantecon.org/ https://cheatsheets.quantecon.org/
- SatvikBeri 5mo ago
  It's definitely closer to matlab than python, but it's closer to python than most mainstream programming languages. I ported ~20k lines of python code to Julia over a couple years manually, and for the most part could do line-by-line translations that worked (but weren't necessarily performant until I profiled and switched to using Julia idioms.)
mgkuhn 5mo ago
Note that this article is about Julia 1.0.3, whereas today you should consider as obsolete any experience reports involving Julia versions prior to Julia 1.10 (the current LTS version), the most significant milestone in the maturity and usability of the language.
Syzygies 5mo ago
Julia is reasonably fast. I returned to a language comparison project specific to my math research, to see how I might do better. My agents and I studied the advice in the post and various more recent links from the comments, but we were already mostly on target and nothing left moved the needle. My work is more combinatorial. Julia does excel at numerical computation. There's a tribal divide in math between people who can't go 30 seconds away from the real or complex numbers, and those whose tolerance is about that long. I try to keep an open mind, but I'm closer to the second camp. Julia is good enough to consider either way. A development in recent months, AI can assist in general purpose Lean 4 programming, no longer getting confused by the dominant proof-oriented training corpus. If one is a functional programmer who believes that Haskell was on the right track, then Lean is the most interesting language choice for shaping one's thoughts. Benchmarks are inherently misleading if a better language makes it possible to express algorithms out of reach of more primitive languages. https://github.com/Syzygies/Compare https://github.com/Syzygies/Compare C++ 100 13.08s ±0.08s Rust 99 13.16s ±0.02s Julia 90 14.54s ±0.01s F# 90 14.54s ±0.04s Kotlin-native 88 14.79s ±0.01s Kotlin 86 15.18s ±0.01s Scala 79 16.50s ±0.08s Scala-native 76 17.14s ±0.02s Nim 65 20.17s ±0.01s Swift 64 20.54s ±0.04s Ocaml 52 25.38s ±0.04s Chez 49 26.64s ±0.02s Haskell 37 34.96s ±0.06s Lean 29 45.39s ±0.15s
vivzkestrel 5mo ago
- why are all the newer posts on page 1 and page 2 under blog empty? I mean I literally only see the title - not a single post has anything inside here https://flow.byu.edu/posts/ https://flow.byu.edu/posts/
Woodi 5mo ago
Over the years there already was almost the identical articles about making in language X program as fast as C or C++... And results was exactly the same: write C/C++ style programs! Why ? Because of CPU's architecture - given CPU one just need to structure code in a way CPU can perform efficiently! Is it such surprising that all sugar and multi-functional smartness have cost of all that if's and loops like maps? CPU is just rock stupid and can't do anything else! That's from where all that specialized instructions are coming and programs just need to be structured or compiled to CPU arch way to perform as fast as CPU and rest of hardware allows... And there are some "Java machines" and that is exaclty the same story: use CPU native lang :) As much as posible. So: give us better cpus pls :)

86 points by d_tr 5mo ago

slwvx 5mo ago

From 2019

Recent discussion on Julia Discourse: https://discourse.julialang.org/t/making-julia-as-fast-as-c/ https://discourse.julialang.org/t/making-julia-as-fast-as-c/

deleted 5mo ago

[deleted]

StilesCrisis 5mo ago

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.

brabel 5mo ago
> code that is uglier and still much slower than C++. Oh such a shame indeed! They didn’t even manage to produce better looking code at least?? Julia was looking great in 2019 but it was very buggy still so I stopped looking. Had hopes that by now it would be a good choice over C++ and Rust with similar performance.
- cmrdporcupine 5mo ago
  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.
  - 2ndorderthought 5mo ago
    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
    - andyferris 5mo ago
      Personally I never struggled. You can employ interfaces and maintain them judiciously. But interfaces are informal. Not using a monorepo say makes it harder to be sure if your broke downstream or not (via downstream’s unit tests). But freedom from Rust’s orphan rule etc means you can decompose large code into fragments easily, while getting almost Zig-style specialisation yet the ease of use of python (for consumers). I would say this takes a fair bit of skill to wield safely/in a maintainable fashion though, and many packages (including my own) are not extremely mature.
    - cmrdporcupine 5mo ago
      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.
  - csvance 5mo ago
    From the sound of your post I'm guessing you view Julia as a general purpose language. I'd consider it general purpose insofar as the application leans into fast numerical computing, everyone else secondary. It can do most of the things other languages do reasonably well, but that's not why you would pick Julia for a project over say Java. You pick it because you want to write fast numerical code and express it elegantly. All of the other typical "glue" things you need to ship a product are secondary to that, but good enough to get the job done. The key to performance with the GC in Julia is not allocating, but it has gotten substantially better since 2019.
2ndorderthought 5mo ago
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
- andyferris 5mo ago
  Meh, I’ve never been associated with the company and AFAICT they provide value through platforms for enterprises. Not everyone gets OSS sponsorships to fund team (and using a social media presence to achieve this was a post-Julia phenomenon). It’s nothing like Google-the-ad-company influencing Chrome. The company consumes Julia for products to sell, rather. Maybe this affects the ordering of features landing, but… meh.
- postflopclarity 5mo ago
  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!
  - 2ndorderthought 5mo ago
    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
    - kelipso 5mo ago
      > 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.
SatvikBeri 5mo ago
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.
- d_tr 5mo ago
  > This is 7 years old. Yeah, I actually totally forgot to check the date...
- HarHarVeryFunny 5mo ago
  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 easy to write high performance parallel software.
  - tialaramex 5mo ago
    > 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.
    - sheepscreek 5mo ago
      Drawing from the analogies, what’s the Julia equivalent of them?
neutrinobro 5mo ago
Hardly seems worth the effort, perhaps things have improved since 2019. It would be interesting to see an updated benchmark, but if your going to end up with code that looks like C++ to get proper performance, you might as well write it in C++. My biggest problem with Julia is that they decided to use column-major indexing for multi-dimensional arrays (i.e. FORTRAN/MATLAB style). This makes interoperability with C/C++ and python numpy a real pain, since you can't do zero-copy array sharing between the two without one side being forced into strided-access. For that reason alone I haven't adopted it in any of my work-flows.
- csvance 5mo ago
  Just reverse the axis on one side, typically the Julia side. This is the convention used in Lux.jl/Flux.jl. I share memory between the two with zero additional copying for my workflows on a daily basis. If you are really allergic to doing this, I’m sure it’s possible to use metaprogramming / the type system to write it the same way in both places with zero performance overhead.
- adrian_b 5mo ago
  Actually the column-major order of Fortran is more efficient for some linear algebra operations than the order of C, which has been inherited by many modern languages that do not care about high performance in scientific computations. So I would say that the culprit for interoperability is C and its descendants, not Fortran or Julia. The designers of C and of the languages that have imitated C have not given any thought about which order for multi-dimensional arrays is better, so the users of such languages do not have any right to blame for interoperability other languages that have done the right thing. Even if the Fortran order had not been better, it had already been used for 20 years before C, so there was no reason to choose a different order. C has chosen to store arrays in the order in which they are typically read by humans when written on paper, but this is a choice like the choice between big-endian and little-endian, where big-endian was how Europeans wrote numbers, but little-endian is more efficient on computers. An example of why column-major order is preferable, is the matrix-vector product, i.e. the evaluation of a function that maps linear spaces. The matrix-vector product should not be done as it is typically taught in schools, by scalar products of rows of the matrix with the vector, because this is less efficient, by making more memory accesses. The right way to compute a matrix-vector product is by doing AXPY operations between columns of the matrix and the vector operand (segments of the output of the AXPY operations are held in registers until all partial AXPY operations are accumulated, avoiding memory accesses). In this case, you need to read columns of the input matrix for each AXPY operation, which is much more efficient when the elements of a column are stored compactly in memory, avoiding the need of strided accesses. The same thing happens for matrix-matrix products, which must not be done in the naive way taught in schools, by scalar products of rows of the first matrix with columns of the second matrix, but it must be done by tensor products of columns of the first matrix with rows of the second matrix.
celrod 5mo ago
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/ 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.
- arbitrandomuser 5mo ago
  hey , what happened to LoopModels ?
  - celrod 5mo ago
    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.
    - arbitrandomuser 5mo ago
      oh , is it closed source now ? i couldnt find it on github anymore , github.com/LoopModels returns a 404.
      - celrod 5mo ago
        Yeah, for now. I'd like it to be open, but I also want to potentially be able to make money/a living off of it. My dream would be that it can be open while hardware vendors pay me to optimize for their hardware. For how, being closed gives me more options. It's a lot easier to open in the future than to close, so it's just keeping options open. I've thought a lot more about the engineering than any sort of marketing or businesses plan, so I just want to defer those.
drnick1 5mo ago
Came here to say that. It's just easier to write C++ in the first place, and LLMs now make this easier than ever.

FattiMei 5mo ago

Very interesting post and I think this exposes the limitations of the Julia compiler. Note that an old version of the compiler is used (1.0.3 from 2019). One could say that we can almost replicate the semantic of a C++ program, but writing in Julia. For example we can remove bounds checks in arrays or remove hidden memory allocations. But the goal of a language for numerical computing is capturing the mathematical formulas using high level constructs closer to the original representation while compiling to efficient code. Domain scientists want to play with the math and the formulas, not doing common subexpression elimination in their programs. Just curious to see how it evolves

northzen 5mo ago
I think the best compromise would be to get the best of two words. By default perform bound checks, but have a compiler flag which skips it. Might broke many programs written with default behaviour in mind, but allow perform additional optimizations.
- postflopclarity 5mo ago
  this is exactly what julia does. boundschecks are default on, and there are compiler flags --- either locally, via the `@inbounds` macro, or globally with `--check-bounds=no`--- to disable them

ekjhgkejhgk 5mo ago

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.

kelipso 5mo ago
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.

orthogonal_cube 5mo ago

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.

kmaitreys 5mo ago

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 (!).

arbitrandomuser 5mo ago
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)
- thimotedupuch 5mo ago
  Exactly ! The new LSP is getting ready https://github.com/aviatesk/JETLS.jl/ 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.
jakobnissen 5mo ago
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.
- 5mo ago

kasperset 5mo ago

I wonder how Mojo ranks along with Julia. Mojo was discussed yesterday here. Mojo seems to be more python focused while Julia is very much focused on Scientific computation. I may be wrong.

mgkuhn 5mo ago

I'm always surprised when people describe Julia syntax as "Pythonic": Julia's syntax was clearly inspired by MATLAB rather than Python. And that's a good thing, because Python+NumPy syntax is far more cumbersome than either Julia or MATLAB's. You can see this at a glance from this nice trilingual cheat sheet: https://cheatsheets.quantecon.org/ https://cheatsheets.quantecon.org/

SatvikBeri 5mo ago
It's definitely closer to matlab than python, but it's closer to python than most mainstream programming languages. I ported ~20k lines of python code to Julia over a couple years manually, and for the most part could do line-by-line translations that worked (but weren't necessarily performant until I profiled and switched to using Julia idioms.)

mgkuhn 5mo ago

Note that this article is about Julia 1.0.3, whereas today you should consider as obsolete any experience reports involving Julia versions prior to Julia 1.10 (the current LTS version), the most significant milestone in the maturity and usability of the language.

Syzygies 5mo ago

Julia is reasonably fast. I returned to a language comparison project specific to my math research, to see how I might do better. My agents and I studied the advice in the post and various more recent links from the comments, but we were already mostly on target and nothing left moved the needle. My work is more combinatorial. Julia does excel at numerical computation. There's a tribal divide in math between people who can't go 30 seconds away from the real or complex numbers, and those whose tolerance is about that long. I try to keep an open mind, but I'm closer to the second camp. Julia is good enough to consider either way. A development in recent months, AI can assist in general purpose Lean 4 programming, no longer getting confused by the dominant proof-oriented training corpus. If one is a functional programmer who believes that Haskell was on the right track, then Lean is the most interesting language choice for shaping one's thoughts. Benchmarks are inherently misleading if a better language makes it possible to express algorithms out of reach of more primitive languages. https://github.com/Syzygies/Compare https://github.com/Syzygies/Compare C++ 100 13.08s ±0.08s Rust 99 13.16s ±0.02s Julia 90 14.54s ±0.01s F# 90 14.54s ±0.04s Kotlin-native 88 14.79s ±0.01s Kotlin 86 15.18s ±0.01s Scala 79 16.50s ±0.08s Scala-native 76 17.14s ±0.02s Nim 65 20.17s ±0.01s Swift 64 20.54s ±0.04s Ocaml 52 25.38s ±0.04s Chez 49 26.64s ±0.02s Haskell 37 34.96s ±0.06s Lean 29 45.39s ±0.15s

vivzkestrel 5mo ago

- why are all the newer posts on page 1 and page 2 under blog empty? I mean I literally only see the title - not a single post has anything inside here https://flow.byu.edu/posts/ https://flow.byu.edu/posts/

Woodi 5mo ago

Over the years there already was almost the identical articles about making in language X program as fast as C or C++... And results was exactly the same: write C/C++ style programs! Why ? Because of CPU's architecture - given CPU one just need to structure code in a way CPU can perform efficiently! Is it such surprising that all sugar and multi-functional smartness have cost of all that if's and loops like maps? CPU is just rock stupid and can't do anything else! That's from where all that specialized instructions are coming and programs just need to be structured or compiled to CPU arch way to perform as fast as CPU and rest of hardware allows... And there are some "Java machines" and that is exaclty the same story: use CPU native lang :) As much as posible. So: give us better cpus pls :)