3 ms·

> The performance Julia provides without interfacing C/C++ or Fortran is not just a convenience, it has architectural consequences. These statements set the ex

by vletal 5y ago

> The performance Julia provides without interfacing C/C++ or Fortran is not just a convenience, it has architectural consequences. These statements set the expectations really high. Yet they omit the ugly truth of increasingly slow compilation times, pure compilation caching, JIT which might affect overall performance due to type instability. Yeah, like Haskell has a nice Quick-sort example prominently displayed at the front page, Julia is sleek for scientific computing, yet it can bite you really bad as soon as you start wrapping the developed model into a real world REST app. Do not get me wrong, I see some of the benefits of Julia. On the other hand, I do not think this uncritical hype about "coding 'further'" does good for the language.

DNF2 5y ago
Compilation times are still an issue, but what do you mean with 'increasingly slow' compilation times? As far as I know and can tell, compilation times have been getting faster not slower, and by a significant amount.
- ChrisRackauckas 5y ago
  Let's even put raw numbers to it. DifferentialEquations.jl usage has seen compile times drop from 22 seconds to 3 seconds over the last few months. https://github.com/SciML/DifferentialEquations.jl/issues/786 https://github.com/SciML/DifferentialEquations.jl/issues/786
  - vletal 5y ago
    Yeah, I should not have used "increasingly", yet what you are pointing out is an example of an improvement in a single module, not the language compiler & llvm. It does not actually prove the original comment wrong.
    - ChrisRackauckas 5y ago
      Almost all of the improvements came from changes to Julia's Base that improved compilation times and changes to tooling which suggest trivial changes to improve compilation times. In v1.5 or so this would've been a heroic feat. In v1.7 this is something any undergrad could do in a weekend to any module. So yes that proves that things have changed quite a bit.
    - gugagore 5y ago
      It's not due to effort that is specific to a single module. It reflects an improvement in the community's understanding of what patterns causes slow compile times and also tooling that helps improve compile times by reducing method invalidations. There may well have also been improvements in the Julia compiler.

by vletal 5y ago

DNF2 5y ago

Compilation times are still an issue, but what do you mean with 'increasingly slow' compilation times? As far as I know and can tell, compilation times have been getting faster not slower, and by a significant amount.

ChrisRackauckas 5y ago
Let's even put raw numbers to it. DifferentialEquations.jl usage has seen compile times drop from 22 seconds to 3 seconds over the last few months. https://github.com/SciML/DifferentialEquations.jl/issues/786 https://github.com/SciML/DifferentialEquations.jl/issues/786
- vletal 5y ago
  Yeah, I should not have used "increasingly", yet what you are pointing out is an example of an improvement in a single module, not the language compiler & llvm. It does not actually prove the original comment wrong.
  - ChrisRackauckas 5y ago
    Almost all of the improvements came from changes to Julia's Base that improved compilation times and changes to tooling which suggest trivial changes to improve compilation times. In v1.5 or so this would've been a heroic feat. In v1.7 this is something any undergrad could do in a weekend to any module. So yes that proves that things have changed quite a bit.
  - gugagore 5y ago
    It's not due to effort that is specific to a single module. It reflects an improvement in the community's understanding of what patterns causes slow compile times and also tooling that helps improve compile times by reducing method invalidations. There may well have also been improvements in the Julia compiler.