> On 29 Jul 2017, at 02:39, Christopher Sean Morrison <brl...@mac.com> wrote:
>
>
>> I did some testing over the trunk code, to compare the performance between
>> the bool_eval() function there and the version in the OpenCL branch. I added
>> the column with the results to my previous table, which I attach with this
>> email. It looks like the version in the trunk is faster, and the difference
>> becomes quite noticeable once the model complexity grows.
>
> Rewrites of the goto-happy C version to have fewer jumps has been attempted
> many times, all resulting in slower code or different (incorrect) results.
> Of course none of them really had coherency in mind.
>
> One interesting one was a rewrite in java, which circumvented the entire
> approach with a simpler direct evaluation of the Boolean expression (see
> Tree::evaluate() and the Partition class operators):
>
> https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Tree.java
>
> <https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Tree.java>
> https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Partition.java
>
> <https://svn.code.sourceforge.net/p/brlcad/code/jbrlcad/trunk/src/main/java/org/brlcad/geometry/Partition.java>
>
> This not only works but fixed a bug in the C boolweave code where wrong
> normals might get used because it makes decisions without regard for the CSG
> operation. I’ve always thought it would be really interesting to
> re-transcode the Java version back to C to see what the performance impact
> would be. Almost certainly more incoherent, but probably much easier to
> optimize (and maintain).
>
>> Figures. It would be too good to be true otherwise. We will have to
>> prototype a new tree storage structure and bool_eval() in ANSI C.
>> Then port that over to OpenCL. This is a chance to make a contribution to
>> the state of the art. We'll precompute all the jumps and store them in the
>> tree.
>
> ++1
>
> For that table, it would be informative to see a comparison with rt -l5
> -s1024 (i.e., without -z1). What’s the distinction of the first two columns
> (e.g., havoc 1.208s vs 2.198s)? That is, what change resulted in havoc being
> 1.9x faster?? That’s unexpected.
The first column (1.208s) is the time it takes over the code currently in the
trunk (it uses a different bool_eval() function) and the 2nd column (2.198s) is
the time taken from the OpenCL branch code (which uses the bool_eval() function
with the boolean tree in RPN from Vasco).
>
> Also, what’s the VGR number on your test machine? My laptop (~7K VGR)
> renders havoc -s1024 in 0.39s (2.4M rays/s) …
Okay so this difference in time made me go check if I was doing things
correctly, and well, I wasn’t testing with a Release build… With the Release
build I got 0.64s (rt -s1024) and 0.35s (rt -l5 -s1024, but this is a
different lighting model from the one with the command ‘rt -z1 -l5’, as Vasco
mentions in his email). This for the havoc scene with the view: az35, el25.
Is the VGR the number from the benchmark results? If that is the case then I
got ~32k VGR on my machine.
Cheers!
Marco
>
> Cheers!
> Sean
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
