Not your fault at all. We need to make this kind of thing easier to discover. Eg with
https://github.com/astrieanna/TypeCheck.jl > On Jun 17, 2014, at 8:35 AM, Jesus Villaverde <vonbismarck1...@gmail.com> > wrote: > > Ahhhhh!!!!!!!! Sorry, over 20 years of coding in Matlab :( > > Yes, you are right, once I change that line, the type definition is > irrelevant. We should change the paper and the code ASAP > >> On Tuesday, June 17, 2014 12:03:29 AM UTC-4, Peter Simon wrote: >> By a process of elimination, I determined that the only variable whose >> declaration affected the run time was vGridCapital. The variable is >> declared to be of type Array{Float64,1}, but is initialized as >> >> >> vGridCapital = 0.5*capitalSteadyState:0.00001:1.5*capitalSteadyState >> >> which, unlike in Matlab, produces a Range object, rather than an array. If >> the line above is modified to >> >> vGridCapital = [0.5*capitalSteadyState:0.00001:1.5*capitalSteadyState] >> >> then the type instability is eliminated, and all type declarations can be >> removed with no effect on execution time. >> >> --Peter >> >> >>> On Monday, June 16, 2014 2:59:31 PM UTC-7, Jesus Villaverde wrote: >>> Also, defining >>> >>> mylog(x::Float64) = ccall((:log, "libm"), Float64, (Float64,), x) >>> >>> made quite a bit of difference for me, from 1.92 to around 1.55. If I also >>> add @inbounds, I go down to 1.45, making Julia only twice as sslow as C++. >>> Numba still beats Julia, which kind of bothers me a bit >>> >>> Thanks for the suggestions. >>> >>>> On Monday, June 16, 2014 4:56:34 PM UTC-4, Jesus Villaverde wrote: >>>> Hi >>>> >>>> 1) Yes, we pre-compiled the function. >>>> >>>> 2) As I mentioned before, we tried the code with and without type >>>> declaration, it makes a difference. >>>> >>>> 3) The variable names turns out to be quite useful because this code will >>>> be eventually nested into a much larger project where it is convenient to >>>> have very explicit names. >>>> >>>> Thanks >>>> >>>>> On Monday, June 16, 2014 12:13:44 PM UTC-4, Dahua Lin 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 >>>>>> > >>>>>> > >>>>>>
