4 ms·

I wish they would stop overselling too. There are so many problems with trying to adopt it for real projects it isn't even funny... Good for researchers sometim

I wish they would stop overselling too. There are so many problems with trying to adopt it for real projects it isn't even funny... Good for researchers sometimes, but even then... It's got issues. Pretty toxic community too.

dunefox 4y ago
> Pretty toxic community too. Quite the opposite according to my own experience.
Sukera 4y ago
> There are so many problems with trying to adopt it for real projects it isn't even funny... Good for researchers sometimes, but even then... It's got issues. Can you expand on that, so that it's possible to improve on them?
- JZerf 4y ago
  It seems to use a lot of memory which can be unacceptable for many people and can become impractical if you plan on running several programs simultaneously. For several of the problems at https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... on the Computer Language Benchmarks Games, it shows the Julia programs as using several times more memory than similar Java programs. It's even worse when comparing to C, C++, Rust, etc...
  - ChrisRackauckas 4y ago
    Remember that for those benchmarks, C, C++, and Rust compile the binaries and then run the benchmark, while Julia compiles as part of the benchmark. The memory usage is dramatically decreased if you do a workflow similar to the other languages using something like PackageCompiler.jl to build a binary that is benchmarked. If you treat the other languages as "JIT" and include those factors in the benchmarking process, it's a lot closer.
    - adgjlsfhk1 4y ago
      While this is true, it's also true that Julia currently brings more into ram than it should (and brings stuff in earlier than it should). The best example of this is that we currently allocate buffers ahead of time for matrix multiplication temporaries (even if matrix multiplication is never performed in the program). We do need to fix that type of thing eventually.
    - JZerf 4y ago
      Thanks, I hadn't noticed that Julia was also doing compilation during the benchmarking and I'm curious if it would be hard to get those benchmarks to be done with PackageCompiler.jl. With that being said, the memory usage still seems very high. For many of the problems, Julia is often using the second most memory of all the programming language implementations being benchmarked and several of those other programming languages implementations (Node.js, OpenJDK, .NET, etc...) also are doing some sort of compilation during the benchmarking as well. I also tried compiling several of the C programs with GCC and GCC usually only used ~30 MB of additional memory so even if you add that to the the memory usage of the C programs, it's still much less than the Julia programs. Using PackageCompiler.jl does look promising but that does add another step which looks to be slightly more involved (looks a bit comparable to using profile-guided optimization) than compilation steps for other programming languages and some could see that as another problem for using Julia in real projects.
      - adgjlsfhk1 4y ago
        In the past the benchmarkgame people haven't let us use PackageCompiler. The big memory gain would be that you could skip loading things like LinearAlgebra and the other standard libraries that aren't being used (but which you are still loading code for).
        JZerf 4y ago
        I think some more effort should be made in getting the default memory usage down to a more reasonable level. This site https://programming-language-benchmarks.vercel.app/problem/helloworld https://programming-language-benchmarks.vercel.app/problem/h... shows a simple Hello World Julia program as using 169 MB of memory (and I saw similar memory usage on my computer running '/usr/bin/time julia -e 'println("Hello World!")'') which was the third worse of all the programming language implementations that were tested.

dunefox 4y ago

> Pretty toxic community too. Quite the opposite according to my own experience.

Sukera 4y ago

> There are so many problems with trying to adopt it for real projects it isn't even funny... Good for researchers sometimes, but even then... It's got issues. Can you expand on that, so that it's possible to improve on them?

JZerf 4y ago
It seems to use a lot of memory which can be unacceptable for many people and can become impractical if you plan on running several programs simultaneously. For several of the problems at https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/julia.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... on the Computer Language Benchmarks Games, it shows the Julia programs as using several times more memory than similar Java programs. It's even worse when comparing to C, C++, Rust, etc...
- ChrisRackauckas 4y ago
  Remember that for those benchmarks, C, C++, and Rust compile the binaries and then run the benchmark, while Julia compiles as part of the benchmark. The memory usage is dramatically decreased if you do a workflow similar to the other languages using something like PackageCompiler.jl to build a binary that is benchmarked. If you treat the other languages as "JIT" and include those factors in the benchmarking process, it's a lot closer.
  - adgjlsfhk1 4y ago
    While this is true, it's also true that Julia currently brings more into ram than it should (and brings stuff in earlier than it should). The best example of this is that we currently allocate buffers ahead of time for matrix multiplication temporaries (even if matrix multiplication is never performed in the program). We do need to fix that type of thing eventually.
  - JZerf 4y ago
    Thanks, I hadn't noticed that Julia was also doing compilation during the benchmarking and I'm curious if it would be hard to get those benchmarks to be done with PackageCompiler.jl. With that being said, the memory usage still seems very high. For many of the problems, Julia is often using the second most memory of all the programming language implementations being benchmarked and several of those other programming languages implementations (Node.js, OpenJDK, .NET, etc...) also are doing some sort of compilation during the benchmarking as well. I also tried compiling several of the C programs with GCC and GCC usually only used ~30 MB of additional memory so even if you add that to the the memory usage of the C programs, it's still much less than the Julia programs. Using PackageCompiler.jl does look promising but that does add another step which looks to be slightly more involved (looks a bit comparable to using profile-guided optimization) than compilation steps for other programming languages and some could see that as another problem for using Julia in real projects.
    - adgjlsfhk1 4y ago
      In the past the benchmarkgame people haven't let us use PackageCompiler. The big memory gain would be that you could skip loading things like LinearAlgebra and the other standard libraries that aren't being used (but which you are still loading code for).
      - JZerf 4y ago
        I think some more effort should be made in getting the default memory usage down to a more reasonable level. This site https://programming-language-benchmarks.vercel.app/problem/helloworld https://programming-language-benchmarks.vercel.app/problem/h... shows a simple Hello World Julia program as using 169 MB of memory (and I saw similar memory usage on my computer running '/usr/bin/time julia -e 'println("Hello World!")'') which was the third worse of all the programming language implementations that were tested.