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

[jens_klostermann]

Hi Nicolas,

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?

Jens

PS One suggestion I have is to reduce your NonOrthogonalCorrectors to 1, I don't think 2 are really necessary.

[nico765]

Hello,

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.


OF/commercial solvers:

*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.

Nico

[eugene]

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.