Do any of the more initiated have an idea why Numba performs better for this application, as both it and Julia use LLVM? I'm just asking out of pure curiosity.
Cameron On Tue, Jun 17, 2014 at 10:11 AM, Tony Kelman <t...@kelman.net> wrote: > Your matrices are kinda small so it might not make much difference, but it > would be interesting to see whether using the Tridiagonal type could speed > things up at all. > > > On Tuesday, June 17, 2014 6:25:24 AM UTC-7, Jesus Villaverde wrote: >> >> 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 <vonbism...@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 >>>>>>>> > >>>>>>>> > >>>>>>>> >>>>>>>>
