4 ms·

Are you not talking about Julia v1.9? Packages precompile to binaries (.so/.dll) in this release, and will support direct calls pretty soon. It sounds like you'

Are you not talking about Julia v1.9? Packages precompile to binaries (.so/.dll) in this release, and will support direct calls pretty soon. It sounds like you're talking about a much older Juila. > A lot of Julia's public benchmarks are not idiomatic Julia or packages were created to elide how nonidiomatic they are. ??? https://docs.sciml.ai/SciMLBenchmarksOutput/stable/MultiLanguage/ode_wrapper_packages/ https://docs.sciml.ai/SciMLBenchmarksOutput/stable/MultiLang... this is pretty standard code. I do enjoy programming in Fortran but let's at least keep it concrete and to reality. The older Fortran versions do have a small amount of optimizations that are hard to perform in other languages because the lack of aliasing can make difficult to prove optimizations possible. But the newer Fortran versions don't optimize as well without forcing things like ivdep, which is similar to Julia, which is why you tend to get the same/similar machine code between LFortran and Julia (since both are using the same compiler, LLVM).

cookieperson 3y ago
If by much older you mean the current stable Julia release than sure... As of today Julia 1.8.5 is the stable release. So this post is traditional Julia community stuff.. "it works and everything is perfect you're the problem. We didn't create our own message board and stop posting in other places to try to control the narrative". Gas light city. I wasn't referring to package benchmarks, my apologies if that was unclear.
- nojonestownpls 3y ago
  I'm glad I'm not the only one that feels this way. I love Julia as a language (not as an implementation, which is a pain-in-the-ass to work with), but there has long been a pattern of responses which in practice amount to gaslighting. Afaik it's only small set of people who do that, and charitably they're likely just being less-than-thoughtful about generalizing their "work for my project", "works on my 24 core computer", "works when I know half the people developing packages" experiences to everyone. But to an outsider, it looks like the answer is always "the problems are all fixed now, you're just out of date", and most of the time that turns out not to be true.
  - cookieperson 3y ago
    More than half the community feels that way the other half are either sycophants or don't care. It's not like it's one person either, it's the language maintainers general attitude. It's been called out in the past but it sure hasn't changed because there's a product to sell.
TheRealKing 3y ago
Your benchmarks are not concrete and realistic. I have never seen any language but (unsurprisingly) Julia, to compare its performance with the performance of other languages by calling those languages from within the host language. Definitely 15000 times faster than MATLAB as claimed by JuliaComputing can be achieved with such seemingly concrete and realistic benchmarks. LLVM has benefited and learned so much from Fortran and its compilers. But free food and service are always undervalued.
- adgjlsfhk1 3y ago
  The benchmarks on Julia's website are ones that take around 1 second. The couple nanoseconds of call overhead doesn't matter.
  - TheRealKing 3y ago
    It is not just about call overhead. It is about a whole suite of aggressive optimizations only possible for a whole program. Point to one person or entity in the world who calls SUNDIALS Julia wrapper to bind their C production code to SUNDIALS. If you cannot, you have two options: 1. make your Julia benchmarks concrete and realistic or 2. cease and desist from pointless advocacy of your employer (JuliaComputing) and its benchmarks in public forums.
    - ChrisRackauckas 3y ago
      Sure you can keep moving goal posts. Of course it doesn't make sense to bind a C production code to a C package (SUNDIALS) through Julia. But if you're asking who is using Julia bindings to SUNDIALS as part of a real case, one case that comes to mind is the Sienna power systems dynamics stuff out of NREL (https://www.nrel.gov/analysis/sienna.html https://www.nrel.gov/analysis/sienna.html). If you look inside of the dynamics part of Sienna you can clearly see IDA being used (https://github.com/NREL-Sienna/PowerSimulationsDynamics.jl https://github.com/NREL-Sienna/PowerSimulationsDynamics.jl). IIRC at a recent Julia meetup in the Benelux region kite model simulations also used it for the same reasons (https://github.com/aenarete/KiteSimulators.jl https://github.com/aenarete/KiteSimulators.jl) which of course is pointing to the open source code organization for Aenarete (http://aenarete.eu/ http://aenarete.eu/). The way to find other use cases is to look through the citations. Generally there will be a pattern to it. For cases which reduce to (mass matrix) ODEs FBDF generally (but not always) outperforms CVODE's BDF these days, so those cases have mostly converted over to using the pure Julia solvers. This includes not just ODEs but also other DAEs which are defined through ModelingToolkit, as the index reduction process generates ODEs and generally the ODE form ends up more efficient than using the original DAE form (though not always of course). It's in the fully implicit DAE form that the documentation (as of May 1st 2023, starting somewhere back in 2017 according to the historical docs) recommends using Sundials' IDA as the most efficient method for that case (https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/ https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/) (yes, the docs recommend non-Julia solvers when appropriate. There's more than a few of such recommendations in the documentation). Power systems is such a case with Index-1 DAEs written in the fully implicit form which are difficult in many instances to write in mass matrix form and not already written in ModelingToolkit, hence its use of IDA here. By the same reasoning you can also search around in the citations for other use cases of IDA.

cookieperson 3y ago

If by much older you mean the current stable Julia release than sure... As of today Julia 1.8.5 is the stable release. So this post is traditional Julia community stuff.. "it works and everything is perfect you're the problem. We didn't create our own message board and stop posting in other places to try to control the narrative". Gas light city. I wasn't referring to package benchmarks, my apologies if that was unclear.

nojonestownpls 3y ago
I'm glad I'm not the only one that feels this way. I love Julia as a language (not as an implementation, which is a pain-in-the-ass to work with), but there has long been a pattern of responses which in practice amount to gaslighting. Afaik it's only small set of people who do that, and charitably they're likely just being less-than-thoughtful about generalizing their "work for my project", "works on my 24 core computer", "works when I know half the people developing packages" experiences to everyone. But to an outsider, it looks like the answer is always "the problems are all fixed now, you're just out of date", and most of the time that turns out not to be true.
- cookieperson 3y ago
  More than half the community feels that way the other half are either sycophants or don't care. It's not like it's one person either, it's the language maintainers general attitude. It's been called out in the past but it sure hasn't changed because there's a product to sell.

TheRealKing 3y ago

Your benchmarks are not concrete and realistic. I have never seen any language but (unsurprisingly) Julia, to compare its performance with the performance of other languages by calling those languages from within the host language. Definitely 15000 times faster than MATLAB as claimed by JuliaComputing can be achieved with such seemingly concrete and realistic benchmarks. LLVM has benefited and learned so much from Fortran and its compilers. But free food and service are always undervalued.

adgjlsfhk1 3y ago
The benchmarks on Julia's website are ones that take around 1 second. The couple nanoseconds of call overhead doesn't matter.
- TheRealKing 3y ago
  It is not just about call overhead. It is about a whole suite of aggressive optimizations only possible for a whole program. Point to one person or entity in the world who calls SUNDIALS Julia wrapper to bind their C production code to SUNDIALS. If you cannot, you have two options: 1. make your Julia benchmarks concrete and realistic or 2. cease and desist from pointless advocacy of your employer (JuliaComputing) and its benchmarks in public forums.
  - ChrisRackauckas 3y ago
    Sure you can keep moving goal posts. Of course it doesn't make sense to bind a C production code to a C package (SUNDIALS) through Julia. But if you're asking who is using Julia bindings to SUNDIALS as part of a real case, one case that comes to mind is the Sienna power systems dynamics stuff out of NREL (https://www.nrel.gov/analysis/sienna.html https://www.nrel.gov/analysis/sienna.html). If you look inside of the dynamics part of Sienna you can clearly see IDA being used (https://github.com/NREL-Sienna/PowerSimulationsDynamics.jl https://github.com/NREL-Sienna/PowerSimulationsDynamics.jl). IIRC at a recent Julia meetup in the Benelux region kite model simulations also used it for the same reasons (https://github.com/aenarete/KiteSimulators.jl https://github.com/aenarete/KiteSimulators.jl) which of course is pointing to the open source code organization for Aenarete (http://aenarete.eu/ http://aenarete.eu/). The way to find other use cases is to look through the citations. Generally there will be a pattern to it. For cases which reduce to (mass matrix) ODEs FBDF generally (but not always) outperforms CVODE's BDF these days, so those cases have mostly converted over to using the pure Julia solvers. This includes not just ODEs but also other DAEs which are defined through ModelingToolkit, as the index reduction process generates ODEs and generally the ODE form ends up more efficient than using the original DAE form (though not always of course). It's in the fully implicit DAE form that the documentation (as of May 1st 2023, starting somewhere back in 2017 according to the historical docs) recommends using Sundials' IDA as the most efficient method for that case (https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/ https://docs.sciml.ai/DiffEqDocs/stable/solvers/dae_solve/) (yes, the docs recommend non-Julia solvers when appropriate. There's more than a few of such recommendations in the documentation). Power systems is such a case with Index-1 DAEs written in the fully implicit form which are difficult in many instances to write in mass matrix form and not already written in ModelingToolkit, hence its use of IDA here. By the same reasoning you can also search around in the citations for other use cases of IDA.