Thanks for the several comments and Daniel for the alternate versions of
the calc_net function! Viral, unfortunately I'm not a GitHub/version
control user (yet), but I've copied the code into a gist here:
https://gist.github.com/anonymous/cee196ee43cb9bf1c8b6. The code can be run
by running "run_sim.jl".
On top of the changes I described in my last post, I made changes based on
Daniel's two posts (including his re-written function, thanks!). Basically,
this amounted to replacing single-line array manipulation (e.g., with
".==") with for loops. Daniel, can you clarify your comment of "the first
two lines require memory allocation and might also have a bad memory
profile"? I'm not sure if it's addressed in this latest gist or not.
I ran this version of the code on my laptop, and got the following:
elapsed time: 3.473756352 seconds (713768968 bytes allocated, 15.06% gc
time)
elapsed time: 2.5804882 seconds (673465152 bytes allocated, 20.63% gc time)
elapsed time: 2.579725004 seconds (673465152 bytes allocated, 19.07% gc
time)
This is an improvement! With that said, the Julia code is still 1.8x to 2x
slower than the Matlab code. Any tips on additional changes I can make so I
can (greatly) outperform the Matlab code?
Lastly, since this is my first post to the group, it seems my messages and
replies need to be moderated and approved, so there's some delay in my
replies. Hasn't been a huge issue thus far, but just an FYI.
On Sunday, September 20, 2015 at 9:14:22 AM UTC-5, Valentin Churavy wrote:
>
> take a look at
> @code_warntype calc_net(0, 0, 0, Dict{String,Float64}(), Dict{String,
> Float64}())
>
> It tells you where the compiler has problems inferring the types of the
> variables.
>
> Problematic in this case is
> b_hist::Any
> b_hist_col2::Any
> numB::Any
> b_hist_col2_A::Any
> b_hist_col2_B::Any
> total_b_A_::Any
> total_b_B_::Any
> net_::Any
>
>
> On Sunday, 20 September 2015 22:55:50 UTC+9, Daniel Carrera wrote:
>>
>> Hi Steven,
>>
>> I am not the OP, I am trying to help the OP with his code. Anyway, the
>> first thing I did was replace Dict{Any,Any} by the more explicit
>> Dict{String,Float64} but that didn't help. I did not think to try a
>> composite type. I might try that later. It would be interesting to figure
>> out why the OP's code is so much slower in Julia.
>>
>> Cheers,
>> Daniel.
>>
>>
>> On 20 September 2015 at 15:20, Steven G. Johnson <[email protected]>
>> wrote:
>>
>>> Daniel, you are still using a Dict of params, which kills type
>>> inference. Pass parameters directly or put them in (typed) fields of a
>>> composite type.
>>>
>>> (On the other hand, common misconception: there is no performance need
>>> to declare the types of function arguments.)
>>
>>
>>
