On Tue, Aug 15, 2017 at 5:22 PM, Marco Domingues <marcodomingue...@gmail.com
> wrote:
> To give some context, I am currently cleaning and refactoring the code to
> prepare a ticket with the OpenCL CSG boolean evaluation code, to possibly
> merge with the trunk. And I noticed that we could just cache the first
> region index during boolean evaluation and pass it directly to the
> rt_default_multioverlap(), which avoids having to search for the first set
> bit in the regiontable bitfield, and that could be a problem for very
> sparse bitfields.
>
>
> On the surface, patch seems like an optimization to skip iterating twice.
> Yes? It would be interesting to know if the C code would benefit (and
> operate identically) if the same patch is applied -- have you / can you
> test that? Just applying the patch and running benchmark before/after
> should be adequate.
>
>
> This is actually an approach to replicate what the C code does. The C code
> uses a list to store the regions involved in each partition, and in the
> rt_default_multioverlap(), the first region in the regiontable is directly
> accessed:
>
> [-
> lastregion = (struct region *)BU_PTBL_GET(regiontable, 0);
> -]
>
> So in theory, applying this patch in the C code shouldn’t have any impact
> in the results, as the first region is already being directly accessed.
>
Nice idea. The current OpenCL librt code does probably spend more time with
iterations because of the sparse bitvector, versus the list used in ANSI C
trunk/ librt, although it should spend less time on insertions, so this
should be a good optimization.
How much of a performance impact does this change have btw?
--
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel