OpenImageIO/oiio — pull request #609 by lgritz (2013-06-05 23:03:55+00:00)
Title: TextureSystem thread benchmarking

testtex --threadtimes computes threading benchmarks of the texture system.

The argument n selects among one of several "workload profiles" that simulate different access patterns (e.g., all threads access the same pixel, all threads access the same file but at different coordinates, different threads access different files, etc.). Then it runs a whole bunch of texture queries with differing numbers of threads and prints a report.

The idea is to have an objective way to measure thread performance and efficiency, allow us to zero in on exactly where the threading bottlenecks are, and know exactly how much any proposed fixes improve various situations.

Example usage:

# first, make lots of copies of a texture file
mkdir tmp ; chdir tmp
for i in 0 1 2 3 4 5 6 7 8 9 ; do for j in 0 1 2 3 4 5 6 7 8 9 ; do ln -s ../grid.tx grid$i$j.tx ; done ; done
cd ..
# run benchmark
testtex --nodedup --threads 12 --wedge --threadtimes 7 tmp/grid*.tx

Example output:

Workload: Coherent access, many files, partially overlapping texture sets
texture cache size = 256 MB
hw threads = 12
times are best of 3 trials

threads time (s) efficiency
-------- -------- ----------
1 4.32 100.0% range 0.01 (2000000 iters/thread)
2 4.30 100.5% range 0.40 (2000000 iters/thread)
4 4.88 88.5% range 0.10 (2000000 iters/thread)
6 7.81 55.3% range 0.03 (2000000 iters/thread)
8 13.36 32.3% range 0.38 (2000000 iters/thread)
10 19.89 21.7% range 0.01 (2000000 iters/thread)
12 26.06 16.6% range 0.12 (2000000 iters/thread)

Now, keep in mind that this is really stressing just the texture system; we are not seeing such bad performance degredation in actual renders. But still, if we can improve efficiency of highly threaded "texture access only" benchmarks, surely that will bring improvement to a real render (of which texture is only part) as well.

But yowee, I'm not happy with our texture performance when there are more than 4 threads. Being able to quantify this and keep my feet to the fire is precisely the reason for this patch. (Preview of things to come: I have some really big improvements almost ready to submit for review.)

This pull request also includes an improvement in the IC stat of total data in files opened. When a particular file was closed and reopened, it was incorrectly adding to the files_totalsize stat each time. Now it will not multiply count the size of files that are opened and closed multiple times.