Why is BCSoption "in core" solution not faster?
Using the benchmarks that I downloaded from the web, I found some interesting comments about the bcsoption command.
The bcsoption command can be used to force the analysis to run in-core. However, this does not equate to a faster solve time.
Every change that I made to the default memory settings just increased the solve times (I tried both incore,8gb and default,8gb).
I was surprised by this. I would be curious to know if this will always hold true? Under what circumstances would it be good to issue
the bcsoption?
|
It would depend on the physical memory for the machine they used. If the incore memory needed is 8 GB and you have a machine with 4 GB physical memory and 4+ GB of virtual memory then running in-core will not be fast because the system will be constantly paging/swapping memory to disk during the factorization and backsolve phase of the Sparse solver. This swapping of memory is much slower than the alternative case of running out-of-core and doing the typical Sparse solver I/O. Now if the user has 8+ GB of physical memory then running in-core should be slightly faster than running in an out-of-core mode. It is not unexpected that the performance gain by running in-core is minimal (~10% or so) even if you have enough memory to do so. That is because most operating systems use the system buffer cache to effectively hide the cost of doing true I/O by holding files in-memory. Running the Sparse solver does essentially the same thing as the system buffer cache (or vice versa). Running the Sparse solver in-core means you do not do I/Oand instead hold all of the files in memory. Well, if you run out-of-core and the operating system holds all of the files in physical memory then you get about the same level of performance. |
||
|