Good catch! I'd already added returning bar to my parameterized Julia version, comparing the two now on my machine, they are essentially identical in performance. Still, writing 1/3 the code (and having it much more readable), having generic code that would also work for complex, integer, decimal floats, or whatever, not just `double`/`Float64`, and getting the exact same speed as Fortran, long the scientific speed champ, is absolutely excellent!
On Wednesday, June 1, 2016 at 9:42:29 AM UTC-4, Kristoffer Carlsson wrote: > > Remember to actually return bar when you benchmark the julia code. Also, > you are not running the fortran code with optimizations on: > > ➜ Documents gfortran test.f -O2; ./a.out > 0.000001 seconds > > > Making sure that bar is actually used: > > ➜ Documents gfortran test.f -O2; ./a.out > 0.047754 seconds > > > > > > On Wednesday, June 1, 2016 at 3:10:26 PM UTC+2, Mosè Giordano wrote: >> >> Oh my bad, this was really easy to fix! I usually do inspect the code >> with @code_warntype but missed to do the same this time. Lesson >> learned. >> >> Now the same loop is about ~30 times faster in Julia than in Fortran, >> really impressive. >> >> Thank you all for the prompt comments! >> >> Bye, >> Mosè >> >> >> 2016-06-01 13:27 GMT+02:00 Lutfullah Tomak: >> > First thing I caught in your code >> > >> > >> http://docs.julialang.org/en/release-0.4/manual/performance-tips/#avoid-changing-the-type-of-a-variable >> >> > >> > make bar non-type-changing >> > function foo() >> > array1 = rand(70, 1000) >> > array2 = rand(70, 1000) >> > array3 = rand(2, 70, 20, 20) >> > bar = 0.0 >> > @time for l = 1:1000, k = 1:20, j = 1:20, i = 1:70 >> > bar = bar + >> > (array1[i, l] - array3[1, i, j, k])^2 + >> > (array2[i, l] - array3[2, i, j, k])^2 >> > end >> > end >> > >> > Second, Julia checks array bounds so @inbounds macro before for-loop >> should >> > help >> > improve performance. In some situation @simd may emit vector >> instructions >> > thus faster >> > code. >> >
