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 >>>>> > >>>>> > >>>>> >>>>>