Hi Mike, Just a thought, I am not sure if it matters in the end: In your `intersect` function you are using `None` as a default return value and later in `radiance` you compare objects with `None`. I think it would be better to use (for example) `nothing` here, because the comparison is faster (nothing is just a pointer):
julia> obj1=nothing julia> obj2=None None julia> @elapsed for i=1:10000; obj1==nothing; end 0.000413841 julia> @elapsed for i=1:10000; obj2==None; end 0.001035038 Hope that helps! Best, Alex. On Tuesday, 20 May 2014 03:14:30 UTC+2, mike c wrote: > > Hi all, (first post) > > I"m having my first look at julia and translated a pathtracer written in > python into julia. (A pathtracer is a kind of raytracer) > > The translation was relatively painless, and I've mimicked the python > classes that I lost by using julia's compound types. Code is here => > https://bitbucket.org/mikefc/julia-pathtracer/overview > > However, after going through performance tips and looking for low hanging > fruit, the julia version is still 3x slower than the python version. Note: > the python version does have core matrix/vector and intersection functions > written in C, and I run it using pypy. > > What are some ways I can make the julia code faster? > > * Is there something in the way I'm systematically handling arrays/vectors > which is leading to slowdown? > * The algorithms/techniques are a direct translation of the python code. > Is this style "not liked" by the compiler? > * Are there better ways of passing around config information? (see > Config.jl) > > The key difference between the python and julia code is that I've > aggressively removed temporary vectors by doing nearly all calculations in > pre-allocated memory. I started going down the same road with julia, and > while I did see some improvements I didn't see enough improvement to > implement it everywhere (it makes the code quite messy). > > I've toyed with parallel rendering (on multiple cores), but for the moment > I'm just comparing single-core rendering speed. I've also had a look at > the profiling information, and I didn't get a lot of it. > > Any help appreciated! > > thanks > mike. >
