...but the Numba version doesn't use tricks like that. The uniform metric can also be calculated with a small loop. I think that requiring dependencies is against the purpose of the exercise.
2014-06-17 18:56 GMT+02:00 Peter Simon <[email protected]>: > As pointed out by Dahua, there is a lot of unnecessary memory allocation. > This can be reduced significantly by replacing the lines > > maxDifference = maximum(abs(mValueFunctionNew-mValueFunction)) > mValueFunction = mValueFunctionNew > mValueFunctionNew = zeros(nGridCapital,nGridProductivity) > > > > > with > > maxDifference = maximum(abs!(subtract!(mValueFunction, > mValueFunctionNew))) > (mValueFunction, mValueFunctionNew) = (mValueFunctionNew, > mValueFunction) > fill!(mValueFunctionNew, 0.0) > > > > abs! and subtract! require adding the line > > using NumericExtensions > > > > prior to the function line. I think the OP used Julia 0.2; I don't > believe that NumericExtensions will work with that old version. When I > combine these changes with adding > > @inbounds begin > ... > end > > > > block around the "while" loop, I get about 25% reduction in execution > time, and reduction of memory allocation from roughly 700 MByte to 180 MByte > > --Peter > > > On Tuesday, June 17, 2014 9:32:34 AM UTC-7, John Myles White wrote: > >> Sounds like we need to rerun these benchmarks after the new GC branch >> gets updated. >> >> -- John >> >> On Jun 17, 2014, at 9:31 AM, Stefan Karpinski <[email protected]> >> wrote: >> >> That definitely smells like a GC issue. Python doesn't have this >> particular problem since it uses reference counting. >> >> >> On Tue, Jun 17, 2014 at 12:21 PM, Cristóvão Duarte Sousa < >> [email protected]> wrote: >> >>> I've just done measurements of algorithm inner loop times in my machine >>> by changing the code has shown in this commit >>> <https://github.com/cdsousa/Comparison-Programming-Languages-Economics/commit/4f6198ad24adc146c268a1c2eeac14d5ae0f300c> >>> . >>> >>> I've found out something... see for yourself: >>> >>> using Winston >>> numba_times = readdlm("numba_times.dat")[10:end]; >>> plot(numba_times) >>> >>> >>> <https://lh6.googleusercontent.com/-m1c6SAbijVM/U6BpmBmFbqI/AAAAAAAADdc/wtxnKuGFDy0/s1600/numba_times.png> >>> julia_times = readdlm("julia_times.dat")[10:end]; >>> plot(julia_times) >>> >>> >>> <https://lh4.googleusercontent.com/-7iprMnjyZQY/U6Bp8gHVNJI/AAAAAAAADdk/yUgu8RyZ-Kw/s1600/julia_times.png> >>> println((median(numba_times), mean(numba_times), var(numba_times))) >>> (0.0028225183486938477,0.0028575707378805993,2.4830103817464292e-8) >>> >>> println((median(julia_times), mean(julia_times), var(julia_times))) >>> (0.0028240440000000004,0.0034863882123824454,1.7058255003790299e-6) >>> >>> So, while inner loop times have more or less the same median on both >>> Julia and Numba tests, the mean and variance are higher in Julia. >>> >>> Can that be due to the garbage collector being kicking in? >>> >>> >>> On Monday, June 16, 2014 4:52:07 PM UTC+1, Florian Oswald wrote: >>>> >>>> Dear all, >>>> >>>> I thought you might find this paper interesting: http://economics. >>>> sas.upenn.edu/~jesusfv/comparison_languages.pdf >>>> >>>> It takes a standard model from macro economics and computes it's >>>> solution with an identical algorithm in several languages. Julia is roughly >>>> 2.6 times slower than the best C++ executable. I was bit puzzled by the >>>> result, since in the benchmarks on http://julialang.org/, the slowest >>>> test is 1.66 times C. I realize that those benchmarks can't cover all >>>> possible situations. That said, I couldn't really find anything unusual in >>>> the Julia code, did some profiling and removed type inference, but still >>>> that's as fast as I got it. That's not to say that I'm disappointed, I >>>> still think this is great. Did I miss something obvious here or is there >>>> something specific to this algorithm? >>>> >>>> The codes are on github at >>>> >>>> https://github.com/jesusfv/Comparison-Programming-Languages-Economics >>>> >>>> >>>> >> >> -- Med venlig hilsen Andreas Noack Jensen
