Although not understanding the final part of the performance tips, I would 
like to make the point here that the "style guide" could also use some love.

I am too obsessive to aesthetic. I cannot accept to write ugly code. 

 

On Thursday, September 24, 2015 at 10:13:18 PM UTC+2, Steven G. Johnson 
wrote:
>
>
>
> 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.
>

Reply via email to