CFD Online Logo CFD Online URL
Home > Forums

Build times for OpenFOAM 2.0.x code with Ubuntu 10.10 with its gcc 4.4.5

Register Blogs Members List Search Today's Posts Mark Forums Read

Rating: 2 votes, 4.50 average.

Build times for OpenFOAM 2.0.x code with Ubuntu 10.10 with its gcc 4.4.5

Posted August 20, 2011 at 12:41 by wyldckat
Updated August 27, 2011 at 14:36 by wyldckat (Added a few notes)

This post is gathers information about OpenFOAM 2.0.x build times, using the gcc version that comes with Ubuntu 10.10, namely 4.4.5.

_____________ This was initially posted here: _____________

Since I was curious about using N+1 processes, I've built OpenFOAM 3 times on my machine that has 8GB of DDR2 800MHz and one AMD 1055T X6, using Ubuntu 10.10 with its original gcc version:
  • 1st build with 6 processes;
  • 2nd build with 7 processes;
  • 3rd build with 6 processes again, to account for file cache on RAM.

Which resulted in the following timings:
  1. Code:
    10273.99user 372.12system 36:14.82elapsed 489%CPU (0avgtext+0avgdata 2001584maxresident)k
    227072inputs+4583896outputs (452major+127455000minor)pagefaults 0swaps
  2. Code:
    10274.53user 368.04system 36:10.27elapsed 490%CPU (0avgtext+0avgdata 2001552maxresident)k
    56inputs+4584104outputs (0major+127470259minor)pagefaults 0swaps
  3. Code:
    10209.99user 366.84system 35:49.39elapsed 492%CPU (0avgtext+0avgdata 2001536maxresident)k
    200inputs+4583880outputs (0major+127473965minor)pagefaults 0swaps
Conclusion: at least on my machine, it does not justify using N+1.

Additional timings for comparison:
  • 1 core:
    8213.30user 298.34system 2:24:07elapsed 98%CPU (0avgtext+0avgdata 2001648maxresident)k
    218880inputs+4585496outputs (343major+127443737minor)pagefaults 0swaps
  • 2 cores:
    8437.93user 321.37system 1:16:39elapsed 190%CPU (0avgtext+0avgdata 2001584maxresident)k
    16inputs+4584432outputs (0major+127456817minor)pagefaults 0swaps
  • 3 cores:
    8990.99user 363.41system 56:40.62elapsed 275%CPU (0avgtext+0avgdata 2001600maxresident)k
    792inputs+4584168outputs (0major+127467703minor)pagefaults 0swaps
  • 4 cores:
    9963.10user 382.46system 48:36.42elapsed 354%CPU (0avgtext+0avgdata 2001584maxresident)k
    8inputs+4584064outputs (0major+127476961minor)pagefaults 0swaps
  • 5 cores:
    10105.92user 385.89system 40:57.82elapsed 426%CPU (0avgtext+0avgdata 2001424maxresident)k
    176inputs+4583944outputs (2major+127468657minor)pagefaults 0swaps
_____________ End of copy-paste-organize ________________

More conclusions:
  • Linking is mostly done in single core, therefore it's normal that the performance drops when more CPUs are added to the computation pool.
  • The second line in each timing output doesn't reflect much about what really happened.
  • Neither does the maxresident value report much about the real total memory used during build time.
Other benchmarks that might be interesting:
  • Using more than one machine.
  • Monitoring the maximum memory used with each set of cores. I already know that 4 cores need around 1.5 to 1.6 GB of RAM, but I don't know how much is needed for 6 cores.
  • Using limited RAM, to reduce file cache, which might then improve timings for using N+1.
  • Building inside a virtual machine on this very same real machine, to compare performance.
Views 5694 Comments 2 Edit Tags Email Blog Entry
« Prev     Main     Next »
Total Comments 2


  1. Old Comment
    So no "-j N+1" myth... I believe the story should deserve a "Busted" by MythBusters

    Posted September 3, 2011 at 11:42 by 7islands 7islands is offline
  2. Old Comment
    Hi Takuya!

    Actually, I do believe it seriously depends on the speed at which the files are accessed and/or accessible. And since modern machines + Linux OS use file cache on RAM abundantly, the necessity for N+1 is reduced to naught.

    But indeed: experiments must be conducted to reach some sort of proof, even if it can be disproved in the future with other experiments

    Best regards,
    Posted September 12, 2011 at 15:59 by wyldckat wyldckat is offline

All times are GMT -4. The time now is 15:29.