4 ms·

The two language problem exists for a bunch of reasons, some good and some not. The biggest reason is because some function of the high level language is incom

by duped 5y ago

The two language problem exists for a bunch of reasons, some good and some not. The biggest reason is because some function of the high level language is incompatible with the application domain. Like garbage collection in hot or real-time code or proprietary compilers for processors. Julia does not solve these problems. Other reasons are practical, like portable executables in Go or Rust (portable in the sense they do not require dependencies on their target systems, usually). Julia does not solve this problem. Then there are the reasons to use scripting languages over the system languages, like expressive syntax with low cognitive overhead. Julia definitely helps here. But this comes at the cost of execution and startup time. Julia only kind of solves this problem. So if Julia is trying to make a more performance scripting language then that is admirable. But for most of the projects where I have needed to prototype in a script and implement in a systems language, Julia would not have worked. Even today I don't have a good reason to use it over MATLAB for day to day work, since I already have the license and their ecosystem is more mature.

deleted 5y ago
[deleted]
eigenspace 5y ago
> The biggest reason is because some function of the high level language is incompatible with the application domain. Like garbage collection in hot or real-time code or proprietary compilers for processors. Julia does not solve these problems. The presence of garbage collection in julia is not a problem at all for hot, high performance code. There's nothing stopping you from manually managing your memory in julia. The easiest way would be to just preallocate your buffers and hold onto them so they don't get collected. Octavian.jl is a BLAS library written in julia that's faster than OpenBLAS and MKL for small matrices and saturates to the same speed for very large matrices [1]. These are some of the hottest loops possible! For true, hard-real time, yes julia is not a good choice but it's perfectly fine for soft realtime. [1] https://github.com/JuliaLinearAlgebra/Octavian.jl/issues/24#issuecomment-766243445 https://github.com/JuliaLinearAlgebra/Octavian.jl/issues/24#...
- duped 5y ago
  Doesn't Julia use a mark-and-sweep GC? How is it possible to use in a soft-real-time context without stopping the world?
  - eigenspace 5y ago
    Just because a GC exists doesn't mean you have to use it though. It's just another tool on your belt. There's various options depending on your problem. You could just hold firmly onto memory, preallocating all your buffers before the program starts and then don't allow them to be GC'd, you could also use stack allocated arrays like in StrideArrays.jl / StaticArrays.jl, or some combination of the above. You could also just manually use ccall to malloc and free memory as needed I guess. There's a nice talk here [1] about using julia in soft-real-time for robotics. I'd say the biggest impediment to real-time programming in julia currently is not the GC, but instead that the language has lots of optional optimizations that the compiler can choose to not perform if it thinks it'd be beneficial to do so, and those optimizations can change between minor versions. Hence, there's a lot of testing you'd need to do to make sure your code really is doing exactly what you want and you won't hit the GC or dynamic dispatch, and you'll need to redo that testing every time you update julia or any packages, which is obviously not ideal. [1] https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo
    - eigenspace 5y ago
      Okay, reading my earlier comment I said "perfectly find for soft realtime", that's maybe a bit too far. Let's go with "okay for soft realtime" instead.
      - cbkeller 5y ago
        Honestly you were probably fine the first time, given that you can easily disable the GC, and that it's really not that hard to entirely avoid generating garbage (in which case the GC generally wouldn't have been triggered even if you'd left it on).

by duped 5y ago

deleted 5y ago

[deleted]

eigenspace 5y ago

> The biggest reason is because some function of the high level language is incompatible with the application domain. Like garbage collection in hot or real-time code or proprietary compilers for processors. Julia does not solve these problems. The presence of garbage collection in julia is not a problem at all for hot, high performance code. There's nothing stopping you from manually managing your memory in julia. The easiest way would be to just preallocate your buffers and hold onto them so they don't get collected. Octavian.jl is a BLAS library written in julia that's faster than OpenBLAS and MKL for small matrices and saturates to the same speed for very large matrices [1]. These are some of the hottest loops possible! For true, hard-real time, yes julia is not a good choice but it's perfectly fine for soft realtime. [1] https://github.com/JuliaLinearAlgebra/Octavian.jl/issues/24#issuecomment-766243445 https://github.com/JuliaLinearAlgebra/Octavian.jl/issues/24#...

duped 5y ago
Doesn't Julia use a mark-and-sweep GC? How is it possible to use in a soft-real-time context without stopping the world?
- eigenspace 5y ago
  Just because a GC exists doesn't mean you have to use it though. It's just another tool on your belt. There's various options depending on your problem. You could just hold firmly onto memory, preallocating all your buffers before the program starts and then don't allow them to be GC'd, you could also use stack allocated arrays like in StrideArrays.jl / StaticArrays.jl, or some combination of the above. You could also just manually use ccall to malloc and free memory as needed I guess. There's a nice talk here [1] about using julia in soft-real-time for robotics. I'd say the biggest impediment to real-time programming in julia currently is not the GC, but instead that the language has lots of optional optimizations that the compiler can choose to not perform if it thinks it'd be beneficial to do so, and those optimizations can change between minor versions. Hence, there's a lot of testing you'd need to do to make sure your code really is doing exactly what you want and you won't hit the GC or dynamic dispatch, and you'll need to redo that testing every time you update julia or any packages, which is obviously not ideal. [1] https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo
  - eigenspace 5y ago
    Okay, reading my earlier comment I said "perfectly find for soft realtime", that's maybe a bit too far. Let's go with "okay for soft realtime" instead.
    - cbkeller 5y ago
      Honestly you were probably fine the first time, given that you can easily disable the GC, and that it's really not that hard to entirely avoid generating garbage (in which case the GC generally wouldn't have been triggered even if you'd left it on).