5 ms·

Yeah funnily enough I think "no GC" would be a much better feature in Julia, which would make it a great language for real time applications.

by ummonk 3y ago

dermesser 3y ago
This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.
- sylvaticus 3y ago
  Note that in Julia 1.9 (rc3 currently) and thanks to `PrecompileTools.jl` being adopted by the vast majority of the packages, the compilation latency is a dead issue... (ok, it is moved to the package installation time...)
  - eigenspace 3y ago
    PrecompileTools.jl has definitely not been adopted by the "vast majority of packages" and compilation latency is not a dead issue. There's been huge progress, and the rate of progress on this is much higher than before, but let's not get ahead of ourselves.
- Archit3ch 3y ago
  After the 1st JIT-compilation (which here we treat as C++ static compilation), there is no compilation cost. As long as you avoid doing dynamic things (e.g. GC), there's a great case to be made for real time Julia.
  - dermesser 3y ago
    Of course, but other than in C++ you need to use ways and means to achieve this - never hitting u compiled code - that are not very natural to Julia. Yes it may be possible to compile Julia code to binaries, but it obviously is neither straightforward nor widely used.
- adgjlsfhk1 3y ago
  Julia is already being used in a number of systems with varying levels of real-time-ness. It's early days for sure, but there's a bunch of progress. It turns out lots of "real time" applications actually just need fast code. JIT compile also can be overcome since in real time systems, you generally know all the code you are going to call so you can just make a .so with all of those bits compiled and know that nothing will need to be compiled at runtime. Also on a related topic, the PR for parallel GC in Julia just merged 4 days ago (https://github.com/JuliaLang/julia/pull/48600 https://github.com/JuliaLang/julia/pull/48600), so GC is in the process of getting a bunch faster.
  - sundarurfriend 3y ago
    > Julia is already being used in a number of systems with varying levels of real-time-ness. Any examples you could link to?
    - adgjlsfhk1 3y ago
      The coolest I know of is ASML putting Julia on their giant chip making machines https://www.youtube.com/watch?v=EafTuyy7apY https://www.youtube.com/watch?v=EafTuyy7apY. I think there's also work on putting Julia on satellites, but I don't have the details.
- pjmlp 3y ago
  A JIT works perfectly alright for real time applications, PTC and Aicas are still in business. What matters is how it is implemented, naturally a general purpose one won't do it.
  - dermesser 3y ago
    Yes, I'm not saying it's not possible, but real time abilities were likely one of the least important aspects of Julia's design... So why shoehorn it into something it's not been designed for
- socialdemocrat 3y ago
  That is not really true. People think that because they have spent time with Java which is excessively GC dependent. More modern GC languages such as Go and Julia have opted to use GCs in a far more conservative manner. They don't produce the exorbitant amount of garbage that Java produces. I've talked to NASA guys using Go for real time systems. They say it works great. GC doesn't need to be a problem if you do it right.
bobbylarrybobby 3y ago
You could do a lot worse than modern GC. For instance, in Rust, lack of GC may cause you to reallocate memory or use reference counting, both of which are likely slower than GC. For instance, building a tree in Rust will do a lot of reference counting, which is a lot of heap accesses.
- nmsmith 3y ago
  > building a tree in Rust will do a lot of reference counting This isn't true in most cases. If every subtree is only referenced by its (unique) parent, then you can use a standard Rust "Box", which means that during compilation, the compiler inserts calls to malloc() (when the Box is created) and free() (when the Box goes out of scope). There will be no reference counting — or any other overhead — at runtime.
  - pjmlp 3y ago
    Tree based structures with root ownership are very constrained as general purpose data structure.
ElectronCharge 3y ago
I have wanted deterministic timing in Julia for years. It's come up periodically in the forums. That, and optimized static binaries, would make Julia truly general purpose. I don't mind Python syntax, I hope Mojo lives up to all these claims...it could easily (and finally!) hit the sweet spot of C performance, elegance, and expressiveness!
- ModernMech 3y ago
  What’s your use case for this? Do you mean like a real-time Julia?
  - ElectronCharge 3y ago
    Yes. There are already efforts in that direction, such as Julia Robotics (juliarobotics.org). With Julia, there is work to be done to get to small, optimized, static binaries - which it sounds like Mojo will provide out of the box, given it’s targeting resource-constrained (and novel) hardware. The Rust-inspired features are also VERY interesting!
  - deleted 3y ago
    [deleted]

Yeah funnily enough I think "no GC" would be a much better feature in Julia, which would make it a great language for real time applications.

by ummonk 3y ago

Yeah funnily enough I think "no GC" would be a much better feature in Julia, which would make it a great language for real time applications.

dermesser 3y ago

This is not true at all! Julia usually being JIT-compiled makes it very unsuitable for real time applications (and there's no reason why it should be great for it). GC is the least issue here, and I say that as a fan and daily user of Julia.

sylvaticus 3y ago
Note that in Julia 1.9 (rc3 currently) and thanks to `PrecompileTools.jl` being adopted by the vast majority of the packages, the compilation latency is a dead issue... (ok, it is moved to the package installation time...)
- eigenspace 3y ago
  PrecompileTools.jl has definitely not been adopted by the "vast majority of packages" and compilation latency is not a dead issue. There's been huge progress, and the rate of progress on this is much higher than before, but let's not get ahead of ourselves.
Archit3ch 3y ago
After the 1st JIT-compilation (which here we treat as C++ static compilation), there is no compilation cost. As long as you avoid doing dynamic things (e.g. GC), there's a great case to be made for real time Julia.
- dermesser 3y ago
  Of course, but other than in C++ you need to use ways and means to achieve this - never hitting u compiled code - that are not very natural to Julia. Yes it may be possible to compile Julia code to binaries, but it obviously is neither straightforward nor widely used.
adgjlsfhk1 3y ago
Julia is already being used in a number of systems with varying levels of real-time-ness. It's early days for sure, but there's a bunch of progress. It turns out lots of "real time" applications actually just need fast code. JIT compile also can be overcome since in real time systems, you generally know all the code you are going to call so you can just make a .so with all of those bits compiled and know that nothing will need to be compiled at runtime. Also on a related topic, the PR for parallel GC in Julia just merged 4 days ago (https://github.com/JuliaLang/julia/pull/48600 https://github.com/JuliaLang/julia/pull/48600), so GC is in the process of getting a bunch faster.
- sundarurfriend 3y ago
  > Julia is already being used in a number of systems with varying levels of real-time-ness. Any examples you could link to?
  - adgjlsfhk1 3y ago
    The coolest I know of is ASML putting Julia on their giant chip making machines https://www.youtube.com/watch?v=EafTuyy7apY https://www.youtube.com/watch?v=EafTuyy7apY. I think there's also work on putting Julia on satellites, but I don't have the details.
pjmlp 3y ago
A JIT works perfectly alright for real time applications, PTC and Aicas are still in business. What matters is how it is implemented, naturally a general purpose one won't do it.
- dermesser 3y ago
  Yes, I'm not saying it's not possible, but real time abilities were likely one of the least important aspects of Julia's design... So why shoehorn it into something it's not been designed for
socialdemocrat 3y ago
That is not really true. People think that because they have spent time with Java which is excessively GC dependent. More modern GC languages such as Go and Julia have opted to use GCs in a far more conservative manner. They don't produce the exorbitant amount of garbage that Java produces. I've talked to NASA guys using Go for real time systems. They say it works great. GC doesn't need to be a problem if you do it right.

bobbylarrybobby 3y ago

You could do a lot worse than modern GC. For instance, in Rust, lack of GC may cause you to reallocate memory or use reference counting, both of which are likely slower than GC. For instance, building a tree in Rust will do a lot of reference counting, which is a lot of heap accesses.

nmsmith 3y ago
> building a tree in Rust will do a lot of reference counting This isn't true in most cases. If every subtree is only referenced by its (unique) parent, then you can use a standard Rust "Box", which means that during compilation, the compiler inserts calls to malloc() (when the Box is created) and free() (when the Box goes out of scope). There will be no reference counting — or any other overhead — at runtime.
- pjmlp 3y ago
  Tree based structures with root ownership are very constrained as general purpose data structure.

ElectronCharge 3y ago

I have wanted deterministic timing in Julia for years. It's come up periodically in the forums. That, and optimized static binaries, would make Julia truly general purpose. I don't mind Python syntax, I hope Mojo lives up to all these claims...it could easily (and finally!) hit the sweet spot of C performance, elegance, and expressiveness!

ModernMech 3y ago
What’s your use case for this? Do you mean like a real-time Julia?
- ElectronCharge 3y ago
  Yes. There are already efforts in that direction, such as Julia Robotics (juliarobotics.org). With Julia, there is work to be done to get to small, optimized, static binaries - which it sounds like Mojo will provide out of the box, given it’s targeting resource-constrained (and novel) hardware. The Rust-inspired features are also VERY interesting!
- deleted 3y ago
  [deleted]