Thanks! I'll learn those tools. In any case, paper updated online, github page with new commit. This is really great. Nice example of aggregation of information. Economists love that :)
On Tuesday, June 17, 2014 9:11:08 AM UTC-4, Stefan Karpinski wrote: > > 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 <[email protected] > <javascript:>> 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 <[email protected]> >>>>>> 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 >>>>>> > >>>>>> > >>>>>> >>>>>>
