On Thursday, September 24, 2015 at 1:55:18 PM UTC-4, Sisyphuss wrote: > > However, Julia is assumed to be fast (high expectation), and performance > varies a lot according to the knowledge/skill a programmer own (high > variance). >
Again, that's true in any language where you are trying to get high performance. It's true in C as well. If you ask a bunch of programmers in C to implement something as "trivial" as a matrix multiplication, performance can easily vary between their implementations by a factor of 10 or more. (See e.g. http://nbviewer.ipython.org/url/math.mit.edu/~stevenj/18.335/Matrix-multiplication-experiments.ipynb for some examples and explanations.) The performance variation can be even larger for more complicated problems. It is really hard to know whether you are obtaining nearly "maximum" performance in any language, even "high-performance" languages, unless you either have (a) a lot of knowledge or (b) have alternative highly optimized code for similar problems to compare to. Ideally you have both, even if you are an expert. (e.g. FFTW would never have existed if I hadn't started by benchmarking a bunch of FFT implementations, and noticing the wide variation in performance for different codes, different problem sizes, and different machines.) What is true, however, is that in a very high-level language there can be more going on "under the hood" than in lower-level languages like C that require you to write lots of low-level instructions explicitly. The tradeoff here is that you can be more productive in a higher-level language, but you need to have some more knowledge to avoid performance traps that arise from expressions that seem unexpectedly slow for new users. Fortunately, the rules in Julia are fairly straightforward once you get used to them (see the performance tips section of the manual), and the situation is much better than in other high-level languages where it is often not even possible to get good performance without dropping down to a separate C-like language.
