3 ms·

Julia is GC based language. If you are ok with then there is whole world of other languages with similar disadvantages. For high performance numerical computing

Julia is GC based language. If you are ok with then there is whole world of other languages with similar disadvantages. For high performance numerical computing most GC based languages won’t cut it and that fact is typically swept under the rug by creating C++ implementation wrapped by your GC based language bindings.

ddragon 8y ago
High performance numerical computing is one area that garbage collection doesn't really matter though, unlike real-time applications that needs consistency more than raw speed. Some occasional milliseconds (or even seconds) long stop-the-world GC won't really affect anything in an hour long or days long simulation, training or calculation. Not to mention you don't really allocate that much in many of those applications, in ML for example is not unusual to allocate all tensors once and just update the values during the training loop (usually on GPUs or TPUs), so there won't be anything to even trigger GC. And for Julia in particular, there isn't really a need for bindings over C/C++ (the whole purpose of the language is not requiring another language for performance). Many of the most popular libraries for numeric computing are 100% written Julia, including Flux.jl [1] for Machine Learning and DifferentialEquations.jl [2]. Plus even real-time applications can be done with careful programming, since Julia allows writing programs with either no or minimal allocations, for example [3]. [1] https://github.com/FluxML/Flux.jl https://github.com/FluxML/Flux.jl [2] https://github.com/JuliaDiffEq/DifferentialEquations.jl https://github.com/JuliaDiffEq/DifferentialEquations.jl [3] https://juliacomputing.com/case-studies/mit-robotics.html https://juliacomputing.com/case-studies/mit-robotics.html
pjmlp 8y ago
Just like Swift is one.
- ajconway 8y ago
  One can argue that automatic reference counting is a form of garbage collection. It is, however, deterministic and that’s why some engineers tend to prefer it.
  - pjmlp 8y ago
    It is not deterministic in the presence of deep nested data structures like acyclic graphs, where the amount of time running cascading deletes canny be fully calculated. Likewise the amount of stack space cannot be fully determined. Finally, sharing pointers across threads introduces non-deterministic cache locks and delays. Herb Sutter has a quite good CppCon talk about it. Many engineers prefer it due to cargo cult and anti-tracing GC bias, despite years of CS papers proving the contrary since the early 80's.
    - 0815test 8y ago
      It is deterministic wrt. the object lifetime which is exactly what you need if your "delete" is actually controlling access to some shared resource that must be freed promptly when it goes out of use. The drawbacks you mentioned are largely-unavoidable consequences of that requirement, and they mostly matter when the allocation graph is large and complex. It's why obligate RC as found in Swift is likely a bad idea, and even inferior to obligate tracing GC - but other languages can do better than that, e.g. introducing arenas that can be used to allocate or free objects as a group, in a single operation.
      - pjmlp 8y ago
        Plenty of tracing GC also offer the same control over arenas and deterministic destruction, one just needs to actually use them, e.g. D, Modula-3, Mesa/Cedar, Active Oberon, Eiffel, System C#, C# 7.3/8...

ddragon 8y ago

High performance numerical computing is one area that garbage collection doesn't really matter though, unlike real-time applications that needs consistency more than raw speed. Some occasional milliseconds (or even seconds) long stop-the-world GC won't really affect anything in an hour long or days long simulation, training or calculation. Not to mention you don't really allocate that much in many of those applications, in ML for example is not unusual to allocate all tensors once and just update the values during the training loop (usually on GPUs or TPUs), so there won't be anything to even trigger GC. And for Julia in particular, there isn't really a need for bindings over C/C++ (the whole purpose of the language is not requiring another language for performance). Many of the most popular libraries for numeric computing are 100% written Julia, including Flux.jl [1] for Machine Learning and DifferentialEquations.jl [2]. Plus even real-time applications can be done with careful programming, since Julia allows writing programs with either no or minimal allocations, for example [3]. [1] https://github.com/FluxML/Flux.jl https://github.com/FluxML/Flux.jl [2] https://github.com/JuliaDiffEq/DifferentialEquations.jl https://github.com/JuliaDiffEq/DifferentialEquations.jl [3] https://juliacomputing.com/case-studies/mit-robotics.html https://juliacomputing.com/case-studies/mit-robotics.html

pjmlp 8y ago

Just like Swift is one.

ajconway 8y ago
One can argue that automatic reference counting is a form of garbage collection. It is, however, deterministic and that’s why some engineers tend to prefer it.
- pjmlp 8y ago
  It is not deterministic in the presence of deep nested data structures like acyclic graphs, where the amount of time running cascading deletes canny be fully calculated. Likewise the amount of stack space cannot be fully determined. Finally, sharing pointers across threads introduces non-deterministic cache locks and delays. Herb Sutter has a quite good CppCon talk about it. Many engineers prefer it due to cargo cult and anti-tracing GC bias, despite years of CS papers proving the contrary since the early 80's.
  - 0815test 8y ago
    It is deterministic wrt. the object lifetime which is exactly what you need if your "delete" is actually controlling access to some shared resource that must be freed promptly when it goes out of use. The drawbacks you mentioned are largely-unavoidable consequences of that requirement, and they mostly matter when the allocation graph is large and complex. It's why obligate RC as found in Swift is likely a bad idea, and even inferior to obligate tracing GC - but other languages can do better than that, e.g. introducing arenas that can be used to allocate or free objects as a group, in a single operation.
    - pjmlp 8y ago
      Plenty of tracing GC also offer the same control over arenas and deterministic destruction, one just needs to actually use them, e.g. D, Modula-3, Mesa/Cedar, Active Oberon, Eiffel, System C#, C# 7.3/8...