DifferentialEquations.jl
JuliaInterpreter.jl
DifferentialEquations.jl | JuliaInterpreter.jl | |
---|---|---|
6 | 5 | |
2,756 | 157 | |
0.7% | 0.6% | |
7.2 | 7.6 | |
26 days ago | 24 days ago | |
Julia | Julia | |
GNU General Public License v3.0 or later | GNU General Public License v3.0 or later |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
DifferentialEquations.jl
-
Startups are building with the Julia Programming Language
This lists some of its unique abilities:
https://docs.sciml.ai/DiffEqDocs/stable/
The routines are sufficiently generic, with regard to Julia’s type system, to allow the solvers to automatically compose with other packages and to seamlessly use types other than Numbers. For example, instead of handling just functions Number→Number, you can define your ODE in terms of quantities with physical dimensions, uncertainties, quaternions, etc., and it will just work (for example, propagating uncertainties correctly to the solution¹). Recent developments involve research into the automated selection of solution routines based on the properties of the ODE, something that seems really next-level to me.
[1] https://lwn.net/Articles/834571/
-
From Common Lisp to Julia
https://github.com/SciML/DifferentialEquations.jl/issues/786. As you could see from the tweet, it's now at 0.1 seconds. That has been within one year.
Also, if you take a look at a tutorial, say the tutorial video from 2018,
-
When is julia getting proper precompilation?
It's not faith, and it's not all from Julia itself. https://github.com/SciML/DifferentialEquations.jl/issues/785 should reduce compile times of what OP mentioned for example.
-
Julia 1.7 has been released
Let's even put raw numbers to it. DifferentialEquations.jl usage has seen compile times drop from 22 seconds to 3 seconds over the last few months.
https://github.com/SciML/DifferentialEquations.jl/issues/786
- Suggest me a Good library for scientific computing in Julia with good support for multi-core CPUs and GPUs.
-
DifferentialEquations compilation issue in Julia 1.6
https://github.com/SciML/DifferentialEquations.jl/issues/737 double posted, with the answer here. Please don't do that.
JuliaInterpreter.jl
-
Do you use Julia for general purpose tasks?
The projects page is a list of suggestions of projects that someone has already said they want to run. If you can find a mentor, you can submit a project for anything. For potential performance improvements, I'd look at https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/206, https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/312, and https://github.com/JuliaDebug/JuliaInterpreter.jl/issues/314. I'm not sure if Tim Holy or Kristoffer have time to mentor a project, but if you're interested in doing a gsoc, ask around in the Julia slack/zulip, and you might be able to find a mentor.
-
Julia 1.7 has been released
I would not go as far as calling it very naive, there has certainly been some work put into optimizing performance within the current design.
There are probably some gains to be had by using a different storage format for the IR though as proposed in [1], but it is difficult to say how much of a difference that will make in practice.
[1] https://github.com/JuliaDebug/JuliaInterpreter.jl/pull/309
-
What's Bad about Julia?
You're right, done some more research and there seems to be an interpreter in the compiler: https://github.com/JuliaDebug/JuliaInterpreter.jl. It's only enabled by putting an annotation, and is mainly used for the debugger, but it's still there.
Still, it still seems to try executing the internal SSA IR in its raw form (which is more geared towards compiling rather than dynamic execution in a VM). I was talking more towards a conventional bytecode interpreter (which you can optimize the hell out of it like LuaJIT did). A bytecode format that is carefully designed for fast execution (in either a stack-based or register-based VM) would be much better for interpreters, but I'm not sure if Julia's language semantics / object model can allow it. Maybe some intelligent people out there can make the whole thing work, is what I was trying to say.
-
Julia: faster than Fortran, cleaner than Numpy
It could, but that is a lot more work than it sounds. It might be easier to make it possible to swap out the compiler for one that is much faster (LLVM is slow but does good optimisations, other compilers like cranelift are faster but produce slower code). There is a Julia interpreter but it was written in Julia itself (it was written to support debuggers), so it doesn't really solve the latency issues.
-
Julia: Faster than Fortran, cleaner than Numpy
If you need to run small scripts and can't switch to a persistent-REPL-based workflow, you might consider starting Julia with the `--compile=min` option. You can also reduce startup times dramatically by building a sysimg with PackageCompiler.jl
There is also technically an interpreter if you want to go that way [1], so in principle it might be possible to do the same trick javascript does, but someone would have to implement that.
[1] https://github.com/JuliaDebug/JuliaInterpreter.jl
What are some alternatives?
ModelingToolkit.jl - An acausal modeling framework for automatically parallelized scientific machine learning (SciML) in Julia. A computer algebra system for integrated symbolics for physics-informed machine learning and automated transformations of differential equations
Diffractor.jl - Next-generation AD
diffeqpy - Solving differential equations in Python using DifferentialEquations.jl and the SciML Scientific Machine Learning organization
DaemonMode.jl - Client-Daemon workflow to run faster scripts in Julia
Gridap.jl - Grid-based approximation of partial differential equations in Julia
Tullio.jl - ⅀
ApproxFun.jl - Julia package for function approximation
julia-numpy-fortran-test - Comparing Julia vs Numpy vs Fortran for performance and code simplicity
DiffEqBase.jl - The lightweight Base library for shared types and functionality for defining differential equation and scientific machine learning (SciML) problems
Infiltrator.jl - No-overhead breakpoints in Julia
FFTW.jl - Julia bindings to the FFTW library for fast Fourier transforms
rust - Empowering everyone to build reliable and efficient software.