That's an interesting comparison. Being on par with Java is quite respectable. There's nothing really obvious to change with that code and it definitely doesn't need so many type annotations – if the annotations do improve the performance, it's possible that there's a type instability somewhere without the annotation. The annotation would avoid the instability, but by converting, but conversion itself can be expensive.
On Mon, Jun 16, 2014 at 12:21 PM, Florian Oswald <florian.osw...@gmail.com> wrote: > Hi guys, > > thanks for the comments. Notice that I'm not the author of this code [so > variable names are not on me :-) ] just tried to speed it up a bit. In > fact, declaring types before running the computation function and using > @inbounds made the code 24% faster than the benchmark version. here's my > attempt > > > https://github.com/floswald/Comparison-Programming-Languages-Economics/tree/master/julia/floswald > > should try the Base.maxabs. > > in profiling this i found that a lot of time is spent here: > > > https://github.com/floswald/Comparison-Programming-Languages-Economics/blob/master/julia/floswald/model.jl#L119 > > which i'm not sure how to avoid. > > > On 16 June 2014 17:13, Dahua Lin <linda...@gmail.com> wrote: > >> First, I agree with John that you don't have to declare the types in >> general, like in a compiled language. It seems that Julia would be able to >> infer the types of most variables in your codes. >> >> There are several ways that your code's efficiency may be improved: >> >> (1) You can use @inbounds to waive bound checking in several places, such >> as line 94 and 95 (in RBC_Julia.jl) >> (2) Line 114 and 116 involves reallocating new arrays, which is probably >> unnecessary. Also note that Base.maxabs can compute the maximum of absolute >> value more efficiently than maximum(abs( ... )) >> >> In terms of measurement, did you pre-compile the function before >> measuring the runtime? >> >> A side note about code style. It seems that it uses a lot of Java-ish >> descriptive names with camel case. Julia practice tends to encourage more >> concise naming. >> >> Dahua >> >> >> >> On Monday, June 16, 2014 10:55:50 AM UTC-5, John Myles White wrote: >> >>> Maybe it would be good to verify the claim made at >>> https://github.com/jesusfv/Comparison-Programming- >>> Languages-Economics/blob/master/RBC_Julia.jl#L9 >>> >>> I would think that specifying all those types wouldn’t matter much if >>> the code doesn’t have type-stability problems. >>> >>> — John >>> >>> On Jun 16, 2014, at 8:52 AM, Florian Oswald <florian...@gmail.com> >>> 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 >>> > >>> > >>> >>> >
