| | 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 == |
