Do me a favor and try booting
Do me a favor and try booting your kernel with the norandmaps kernel parameter and try the same benchmarks. It should reduce TLB misses and possibly increase cache hits for a very very minor trade off in security. If your on a firewalled network increased risk of being hacked is nil.
I just figured out you don't e
I just figured out you don't even have to reboot. just write a 0 to the file /proc/sys/kernel/randomize_va_space though a reboot will keep all running processes from having randomized memory allocation.
Hi Nicolas, Do you really s
Do you really show efficiency or is it speedup?
In our experience the intel quadcore performs poor with respect to efficiency and speedup up to 8 cores (with worst performance for 8 cores). I think this is because of the architecture so try to go beyond those 8 cores.
If we compare OF to commercial solvers, we also see the in the lead (typically 30% to 100% faster ) and I am wondering why?
PS One suggestion I have is to reduce your NonOrthogonalCorrectors to 1, I don't think 2 are really necessary.
Hello, Yes Jens, it should
Yes Jens, it should probably be called speedup; i am plotting cpu_time_1cpu/cpu_time_X_cpu.
I'll try to test above 8 cores, not that easy to test here.
*parallel efficiency/speedup: the commercial solver we have here is performing worst -> speed-up is worst.
*but convergence AND time/iteration is better for the commercial solver.
In the end OF takes around twice as much time to get to a converged solution. But there are quite a few parameters i can still look at. Next one is checking NonOrthogonalCorrectors=1 (thanks for the idea).
Thanks Conn, i ll also give try to your suggestion, sounds interesting.
You don't NEED any nonOrthogon
You don't NEED any nonOrthogonal correctors for a steady state run (unless your mesh is particularly poor). Non-orthogonal correction is done even if there are no additional corrector steps and the solution should be identical at convergence.
|All times are GMT -4. The time now is 14:00.|