For those of you following along, here are the actual times. These are render times, not just ustring, but the texturing has been bypassed. The "-t" numbers are threads, this is on a 12 core hyperthreaded (so it looks like 24 cores, but they aren't really as fast as 24 full cores), and the percentages are (single-thread-time/nthreads)/n-thread-time, i.e. percentage of "light speed" if we got a truly linear speedup with number of cores. Remember, we expect it to take a hit after 12 cores (when we're using HT, not full cores), but still show improvement beyond.
OK, here were the original numbers, bypassing texture but still performing the ustring construction of the filenames for every texture lookup: -t1 444s -t2 230s 97% (expected 222) -t4 117s 95% (expected 111) -t8 62s 90% (expected 56) -t12 43s 86% (expected 37) -t16 40s 70% (expected 28) -t20 39s 56% (expected 22) -t24 41s 44% (expected 18) -t32 47s See what's happening? Not only does it stop improving by the time we hit 16 threads, but it starts getting worse again. And for reference, here we take an early out *before* the ustring construction (so, mentally subtract these numbers from the last to isolate just the ustring-related time): -t1 428s -t2 223s 96% (expected 214) -t4 111s 96% (expected 107) -t8 59s 92% (expected 54) -t12 41s 88% (expected 36) -t16 36s 75% (expected 27) -t20 34s 62% (expected 21) -t24 31s 58% (expected 18) -t32 31s That's the behavior we wanted -- linear and high utilization up to 12 threads, still fairly linear even though lower utilization from 12-24 (i.e. still improving with more HT cores), and then flat beyond 24 (where there are no additional cores for the extra threads). OK, so now with the changes I made last week (hold the lock a little less) and the changes of this patch (reader/writer locks), here's where we stand, which you can see is back to the behavior we want. Ustring construction is not free, of course, but it no longer seems to be a particular bottleneck when highly threaded: -t1 447 -t2 230 97% expected 223.5 -t4 117 95% 111.8 -t8 61 92% 55.9 -t12 43 87% 37.2 -t16 39 72% 27.9 -t20 36 62% 22.3 -t24 35 53% 18.6 -t32 32 On Jul 17, 2011, at 11:41 PM, lgritz wrote: > I wrote a reader/writer spin lock, used it for the ustring table, and it > produces another significant improvement when there's heavy contention in > ustring creation. In particular, with this patch the ustring performance > continues to improve all the way up to the number of threads greater than the > number of cores, whereas previously it "leveled off" earlier, with at some > point additional HT cores not providing any additional benefit. Now, more > cores always benefit. (For just a few cores, performance is the same as > before.) > > Now that this class is written, we could possibly improve performance by > finding other places where a good spin rw lock is appropriate that's > currently a purely exclusive lock. > > -- > Reply to this email directly or view it on GitHub: > https://github.com/OpenImageIO/oiio/pull/126 -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
