Re: [Boost-users] [Thread] Beginner question regarding thread groups

From: Mike Marchywka (marchywka_at_[hidden])
Date: 2008-08-25 12:09:17

> Date: Mon, 25 Aug 2008 08:31:16 -0700
> From: michel.lestrade_at_[hidden]
> To: boost-users_at_[hidden]
> Subject: Re: [Boost-users] [Thread] Beginner question regarding thread groups
>
> Hi,
>
> I actually looked at that first as well as another Intel Fortran solution called TBB (Thread Building Blocks). It seems to me that these approaches are made for instruction-level parallelism (i.e. processing a long loop with parallel_do or different but independent sections of code). I have a ton of other Fortran code that would benefit from this but ray tracing is not one of them.
>

They have vectorization and parallelization but IIRC openMP is quite general multi-threading.
[ soliciting a sales pitch from a boost person here, LOL ]

>>From what I read so far, what I am looking for is task-level parallelism, not instruction-level, which is why I am looking into threads.
>> If you want some ideas for reference, I did a quick check on the intel
>> site and they have some papers and apparently even an openMP Fortran
>> compiler if that helps you,
>> [ obviously their comments are specific to their products but quite generally useful
>> esp if you are looking for ideas ]
>> http://cache-www.intel.com/cd/00/00/21/92/219292_hyperthreading_extract.pdf
>>
>> ( http://www.google.com/search?hl=en&q=site%3Aintel.com+openmp+performance+optimization
> In our approach, light emission is isotropic (physically, it corresponds to spontaneous emission in a semiconductor) and we want to know what the extraction efficiency (how much light actually gets out) and what the output distribution is going to look like. This is affected by die shaping, external packaging, refractive index of cladding layers, position and reflectivity of metal contacts, TE/TM emission, etc... So the difference between nearby rays is critical, unlike a visualization/CG render situation.
>

I hadn't read your original post at the time but I'm not saying "be sloppy" just that
you could still do quantitative work but make better use of the surface characteristics
or locality. Ideas, that may or may not be useful, include things like expanding trig functions
based on nearby calculations and breaking things up based on the "small" number of ( mostly flat) surfaces. Even things like look-up-tables can end up costing performance ( extreme case
of course being VM). In at least one case, I found that an "irrelevant" sort of some text files
may a huge difference in execution time ( due to later thrashing).

> Just FYI but here is a quick reference to a few papers by my predecessor who wrote this Fortran code in the first place: http://scholar.google.ca/scholar?hl=en&lr=&q=author%3AShmatov+ray+tracing&btnG=Search
>

Thanks, I always ask people to post links to their work since it makes things more interesting 
and I'll look as soon as I can. I thought the code may be a bit old given the language :)

> We already have locality to a certain extent since each ray is bouncing around in its own "box" with a fixed number of facets and only interacts with certain predefined neighboring "boxes". So I am not too worried about cache at this point. I may have to change my mind later on though if this turns out to be a bottleneck.
>

In this case, you could imagine a thread-per-box or something. Don't underestimate
the return on things like upfront sorting or difference representations ( if deltas
are smaller and reduce memory, you may still be able to get  a net gain in performance
from undoing the "compression").

>> While you say that rays are independent, if you do classical physical optics,
>> nearby rays tend to have similar trajectories etc. Rather than let an ignorant
>> but fair thread scheduler decide what piece of memory to access next, if you
>> are cache aware, you could even consider something like sorting the rays
>> to get the best locality and making them dependent with a transform
>> scheme that recognizes they are similar if nearby etc.
> Regards,
>
> Michel Lestrade
> Crosslight Software
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

_________________________________________________________________
Get ideas on sharing photos from people like you.  Find new ways to share.
http://www.windowslive.com/explore/photogallery/posts?ocid=TXT_TAGLM_WL_Photo_Gallery_082008