5 ms·

Yes, Gadfly does have a large compile time. Reducing the time to first plot (essentially compilation time) has been a major focus for the 1.5 release. People o

Yes, Gadfly does have a large compile time. Reducing the time to first plot (essentially compilation time) has been a major focus for the 1.5 release. People often use Plots.jl or PyPlot which have significantly lesser compile times.

orbifold 6y ago
time to precompile Plots: 138s julia> @time Plots.scatter(data.eq_site_limit, data.hu_site_limit) 5.461595 seconds subsequent calls report significant speed ups compared to matplotlib, but render about as quickly julia> @time Plots.histogram(data.eq_site_limit) 2.143983 seconds
- ViralBShah 6y ago
  There are 3 different phases: 1. Precompilation time: Only once when you install or upgrade a package. 2. First running time (that includes compilation time): When you call a function like `plot` the first time in a session 3. Second and subsequent running times: The compiled code is now in the cache, and what you see is the actual running time. Thus what you are reporting here as precompilation (1) is not something that a user will see every time. What they will see is (2) for the first time in a session and (3) on subsequent plots. Could you confirm this is what you see - to ensure that those following along understand the terminology? Here are the usage times I see when I use Plots on a daily basis in a Julia session: ~ exec '/Users/viral/Desktop/Julia_Releases/Julia-1.5.app/Contents/Resources/julia/bin/julia' _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.5.2 (2020-09-23) _/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release |__/ | julia> @time using Plots 11.341632 seconds (20.21 M allocations: 1.108 GiB, 2.87% gc time) julia> @time plot(1:10,1:10) 2.291147 seconds (3.24 M allocations: 165.569 MiB, 7.80% gc time) (Another 2 seconds for the window to be drawn the first time on mac) julia> @time plot(1:10,1:10) 0.000763 seconds (2.80 k allocations: 166.023 KiB)
fermienrico 6y ago
@ViralBShah and @StefanKarpinski I've had similar problems and so have many of my colleagues in silicon valley. No matter how you spin it and whatever benchmarks you show - Julia is a very slow fast language. :) The UX of Julia needs major work - everything is just slow. If you've used Python for 10 years and it is like running through molasses. Benchmarks are meaningless for the most part. This is what bothers me about Julia's marketing - it claims to be fast, but in reality, precompilation time alone is a no go unless you're doing high-compute large batch processing. Julia cannot be come a general purpose language unless you fix these issues. > These "conflations" sound suspiciously like excuses. I think you're the one conflating total end-to-end time spent between given a task and going home early to see my kids if I used Python.
- ddragon 6y ago
  While I hope they'll keep the pace of improving the JIT lag (perhaps even adding a fast optional interpreter or AoT compilation of parts of code), the benchmarks are fine considering compilation is a one time paid ticket, while runtime is paid by usage. It's not just high compute, if I set up a website in Julia on a docker after the "cold start" (which can be handled before using packagecompiler if I don't want any client to feel the slow JIT compilation, as I obviously should) then it should run at the benchmarked runtime speed even if each request is very short (as the compilation price was paid already). That applies to most services in general, and even during development Julia programmers eventually learn not to cold start all the times (keeping the session open until you stop programming, so you again only pay the cost once). Of course, any short task that must cold start like a bash script isn't convenient at all (and packagecompiler will generate a fat binary that runs fast, but it's still inconveniently fat if it's for something simple). And Julia's first impression is really important, which the "time to first plot" seems to affect the most (as you need to go deeper on the language to adapt to it's unusual workflow), so I agree that it's a UX priority.
- ViralBShah 6y ago
  Nobody is spinning anything here. Julia's compilation time is a known quantity. See my comment in https://news.ycombinator.com/item?id=24750559 https://news.ycombinator.com/item?id=24750559 about the different phases of Julia's compilation and execution (from a user's perspective). Obviously, if you are not working on a problem that doesn't need Julia's speed (and makes it worth paying the compilation cost), and you are more comfortable with a different tool, you should use that. You may in fact be better off using Python, or shell scripting or even Excel. Precompilation time in Julia is akin to `make` in a project with C code. You only compile the library once and use it repeatedly, until you update it. Is it a dealbreaker? Perhaps it is for you (assuming you are using precompilation in the right context). It is not for many who work with Julia day in and day out, and it is something that we continue to improve.

orbifold 6y ago

time to precompile Plots: 138s julia> @time Plots.scatter(data.eq_site_limit, data.hu_site_limit) 5.461595 seconds subsequent calls report significant speed ups compared to matplotlib, but render about as quickly julia> @time Plots.histogram(data.eq_site_limit) 2.143983 seconds

ViralBShah 6y ago
There are 3 different phases: 1. Precompilation time: Only once when you install or upgrade a package. 2. First running time (that includes compilation time): When you call a function like `plot` the first time in a session 3. Second and subsequent running times: The compiled code is now in the cache, and what you see is the actual running time. Thus what you are reporting here as precompilation (1) is not something that a user will see every time. What they will see is (2) for the first time in a session and (3) on subsequent plots. Could you confirm this is what you see - to ensure that those following along understand the terminology? Here are the usage times I see when I use Plots on a daily basis in a Julia session: ~ exec '/Users/viral/Desktop/Julia_Releases/Julia-1.5.app/Contents/Resources/julia/bin/julia' _ _ _ _(_)_ | Documentation: https://docs.julialang.org (_) | (_) (_) | _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help. | | | | | | |/ _` | | | | |_| | | | (_| | | Version 1.5.2 (2020-09-23) _/ |\__'_|_|_|\__'_| | Official https://julialang.org/ release |__/ | julia> @time using Plots 11.341632 seconds (20.21 M allocations: 1.108 GiB, 2.87% gc time) julia> @time plot(1:10,1:10) 2.291147 seconds (3.24 M allocations: 165.569 MiB, 7.80% gc time) (Another 2 seconds for the window to be drawn the first time on mac) julia> @time plot(1:10,1:10) 0.000763 seconds (2.80 k allocations: 166.023 KiB)

fermienrico 6y ago

@ViralBShah and @StefanKarpinski I've had similar problems and so have many of my colleagues in silicon valley. No matter how you spin it and whatever benchmarks you show - Julia is a very slow fast language. :) The UX of Julia needs major work - everything is just slow. If you've used Python for 10 years and it is like running through molasses. Benchmarks are meaningless for the most part. This is what bothers me about Julia's marketing - it claims to be fast, but in reality, precompilation time alone is a no go unless you're doing high-compute large batch processing. Julia cannot be come a general purpose language unless you fix these issues. > These "conflations" sound suspiciously like excuses. I think you're the one conflating total end-to-end time spent between given a task and going home early to see my kids if I used Python.

ddragon 6y ago
While I hope they'll keep the pace of improving the JIT lag (perhaps even adding a fast optional interpreter or AoT compilation of parts of code), the benchmarks are fine considering compilation is a one time paid ticket, while runtime is paid by usage. It's not just high compute, if I set up a website in Julia on a docker after the "cold start" (which can be handled before using packagecompiler if I don't want any client to feel the slow JIT compilation, as I obviously should) then it should run at the benchmarked runtime speed even if each request is very short (as the compilation price was paid already). That applies to most services in general, and even during development Julia programmers eventually learn not to cold start all the times (keeping the session open until you stop programming, so you again only pay the cost once). Of course, any short task that must cold start like a bash script isn't convenient at all (and packagecompiler will generate a fat binary that runs fast, but it's still inconveniently fat if it's for something simple). And Julia's first impression is really important, which the "time to first plot" seems to affect the most (as you need to go deeper on the language to adapt to it's unusual workflow), so I agree that it's a UX priority.
ViralBShah 6y ago
Nobody is spinning anything here. Julia's compilation time is a known quantity. See my comment in https://news.ycombinator.com/item?id=24750559 https://news.ycombinator.com/item?id=24750559 about the different phases of Julia's compilation and execution (from a user's perspective). Obviously, if you are not working on a problem that doesn't need Julia's speed (and makes it worth paying the compilation cost), and you are more comfortable with a different tool, you should use that. You may in fact be better off using Python, or shell scripting or even Excel. Precompilation time in Julia is akin to `make` in a project with C code. You only compile the library once and use it repeatedly, until you update it. Is it a dealbreaker? Perhaps it is for you (assuming you are using precompilation in the right context). It is not for many who work with Julia day in and day out, and it is something that we continue to improve.