No, it's the non-constant globals although JIT compilation is also an issue.
On Sat, Nov 1, 2014 at 1:15 PM, Kapil <[email protected]> wrote: > okay, I think this is because julia will first compile the code and so the > performance is slow, subsequent runs would give improved performance > ᐧ > > Regards, > Kapil Agarwal > > On Sat, Nov 1, 2014 at 1:10 PM, Kapil <[email protected]> wrote: > >> The updated code is available at >> https://github.com/kapiliitr/JuliaBenchmarks/blob/master/streamp.jl >> >> I am getting a performance slightly less than C for multiple processes, >> but for single process, performance is much less (though better than >> previous values) >> >> Just a very basic implementation of one of the benchmarks is: >> >> julia> size=5000000; >> julia> a=fill(3,size); >> julia> b=fill(0,size); >> julia> @time for i=1:size >> b[i]=a[i] >> end >> >> The output is >> elapsed time: 0.537257426 seconds (159983648 bytes allocated, 3.16% gc >> time) >> >> In C, the same code takes 0.012210 seconds. >> >> ᐧ >> >> Regards, >> Kapil Agarwal >> >> On Sat, Nov 1, 2014 at 12:36 PM, Jason Merrill <[email protected]> >> wrote: >> >>> On Saturday, November 1, 2014 9:35:03 AM UTC-7, Jason Merrill wrote: >>>> >>>> On Saturday, November 1, 2014 9:15:43 AM UTC-7, Kapil Agarwal wrote: >>>>> >>>>> I need those variables as globals as otherwise I will have to pass >>>>> them from one function to another all the time. >>>>> >>>> >>>> It's generally better long-term design to pass the relevant state >>>> around than to have it be global. One thing that helps is to define a type >>>> that encapsulates the relevant state, so that you only have to pass one >>>> thing around between functions instead of many. E.g. if I have >>>> >>>> f(a, b, c, d) >>>> mutatea!(a) >>>> mutateb!(b) >>>> mutatec!(c) >>>> mutated!(d) >>>> return g(a,b,c,d) >>>> end >>>> >>> >>> Sorry, this wasn't quite real Julia syntax. Should have written >>> `function` before `f(a, b, c, d)` here and below. >>> >>> >>>> and suppose that g calls another function that also depends on a, b, c, >>>> and d, and so on, it can get kind of tedious to pass all the arguments >>>> separately. >>>> >>>> But you can do >>>> >>>> type algorithmState >>>> a::Ta >>>> b::Tb >>>> c::Tc >>>> d::Td >>>> end >>>> >>>> (where the Ta, Tb, Tc, and Td should be replaced by appropriate >>>> concrete types). >>>> >>>> Then you can do >>>> >>>> f(x::algorithmState) >>>> mutateState!(x) >>>> g(x) >>>> end >>>> >>>> >>> >> >
