Ah! Excellent sleuthing. That's about the kind of thing I suspected was going 
on.

> On Jun 17, 2014, at 12:03 AM, Peter Simon <psimon0...@gmail.com> 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 
>>>>> > 
>>>>> > 
>>>>> 

Reply via email to