| 2 | |
| 3 | == Overview and Benchmark Procedure == |
| 4 | |
| 5 | I have externalized the caching functionality in our various fault surface classes. There are a couple different implementation of the new SurfaceDistanceCache interface: |
| 6 | |
| 7 | * Traditional, single location cache: org.opensha.sha.faultSurface.cache.SingleLocDistanceCache |
| 8 | * Google guava loading cache with variable size: org.opensha.sha.faultSurface.cache.MultiDistanceCache |
| 9 | * Hybrid of both caches: org.opensha.sha.faultSurface.cache.HybridDistanceCache |
| 10 | |
| 11 | I then ran lots of tests at HPCC with many variations on these caching schemes. All tests were run on nodes with the exact same configuration: |
| 12 | |
| 13 | 2 quad core 2.5 GHz processors, 12 GB RAM. |
| 14 | |
| 15 | I ran the following benchmarks for a UCERF3 ERF with the branch average solution: |
| 16 | |
| 17 | Distance test: how long does it take to calculate each distance metric from 80 sites to every rupture in the ERF? |
| 18 | Hazard test: how long does it take to calculate a hazard curve at 80 sites? |
| 19 | |
| 20 | Sites are randomly distributed (tightly) around 35, -118. Tests were run with 1, 2, 4, and 8 threads (multiple runs of each configuration and times averaged). |
| 21 | |
| 22 | == First Results and Sensitivity to Java Version == |