4 ms·
Besides your points, i've found Julia to have deceptive marketing about speed. I've found it to be super slow, mainly when writing expressive code. So then it b
by hexo 4y ago
Besides your points, i've found Julia to have deceptive marketing about speed. I've found it to be super slow, mainly when writing expressive code. So then it boiled down to writing ugly code which turned out to be a little less slow.
I don't buy "it's compiling at run time" argument, since other (interpreted) languages do not have this problem.
Also there were a lot of inconsistencies mostly when trying to use (or abuse, who know?) broadcasting.
Did it improve somehow since last year? I hope so.
- Sukera 4y agoThat definitely sounds like cause for concern! You seem to have spent some time on this, can you share an example?
- DNF2 4y agoIt is quite likely that you have fallen afoul of some of the standard performance 'gotchas', like non-const globals or inadvertently creating type instabilities. Have you consulted the Performance tips?: https://docs.julialang.org/en/v1/manual/performance-tips/ https://docs.julialang.org/en/v1/manual/performance-tips/ Efficient Julia code should normally look simple and elegant, not 'ugly' (unless you are going into deep optimizations, like manual simd, or some times heavy reliance on in-place operations.) I think calling it 'deceptive' is problematic. Of course you can write slow code in Julia, like in any language, but did you write code that you think should be fast, but wasn't? > I don't buy "it's compiling at run time" argument, since other (interpreted) languages do not have this problem. I'm a bit confused by that statement. Compiled languages have to compile, interpreted don't. What did you mean here?