Opened 12 years ago

Closed 12 years ago

#68 closed help (fixed)

vn4.5 speed with new compiler?

Reported by: iamack@… Owned by: jeff
Component: UM Model Keywords: v4.5, compiler, fortran
Cc: rdamoah@…, dstevens@… Platform:
UM Version:

Description

Hello,
It appears that my vn4.5 UM (plus stochem) runs compiled with the new version 10.1 fortran compiler and its default options are requiring about five times as many CPU seconds per day as with the old compiler and its default options. Is this possible? If so, can I choose different compile options which will restore the original speed at the expense of bit reproducibility?

Regards,
Ian

Change History (5)

comment:1 follow-up: Changed 12 years ago by jeff

  • Owner changed from um_support to jeff
  • Status changed from new to assigned

Hi Ian

That seems very strange there shouldn't be anything like that difference between the compilers. The options for 10.1 were only changed so they were equivalent to the 9.1 options. Can you give me access to the compile/run output. What version of 4.5 are you using (resolution etc), and what percentage of the run time is taken up by stochem? Do you have any executables compiled before the compiler change and if so have you tried running with them? I still have some 9.1 executables I can try for standard 4.5 HadAM3, I'll let you know if I see any major differences.

Jeff.

comment:2 in reply to: ↑ 1 Changed 12 years ago by umdoc

Hi Jeff,
It looks like this is a STOCHEM issue. I've done two equivalent 5-day 4.5 UM(96,72,L19)/STOCHEM runs, one using an executable created with the new compiler (job xaaza) and one using an existing executable from the old compiler (job xaazb). The compile/run output is in /hpcx/devt/n02/n02-ncas/iamack/um/umui_out/compile_check. (The executable for xaazb was created with compile job xaaua.) The job with the old executable took 6 minutes and that with the new executable 33 minutes, with the timer output seeming to indicate that all the extra time was spent in the STOCHEM routines. (The STOCHEM code can be found in /hpcx/home/n02/n02/iamack/mods/ files stochem_link_l19_1.0_ibm and st_ma_l19_IPCC4_2000_1.4_ibm32_HT_SR1).

Do you think it's worth trying some different compilation options with the new compiler?

Regards,
Ian

Replying to jeff:

Hi Ian

That seems very strange there shouldn't be anything like that difference between the compilers. The options for 10.1 were only changed so they were equivalent to the 9.1 options. Can you give me access to the compile/run output. What version of 4.5 are you using (resolution etc), and what percentage of the run time is taken up by stochem? Do you have any executables compiled before the compiler change and if so have you tried running with them? I still have some 9.1 executables I can try for standard 4.5 HadAM3, I'll let you know if I see any major differences.

Jeff.

comment:3 follow-up: Changed 12 years ago by jeff

One thing to try would be to use the version 10.1 mass library, I copied over the 9.1 version to maintain bit reproducibility. Not sure why this would affect stochem but this is a very strange problem. The easiest way to do this is to unpack your source code, edit the makefile.link file and change the linker option from -lmass_9.1 to -lmass, then do

make -f makefile.compile
make -f makefile.link

If this doesn't make any difference then you could try an email to the hpcx helpdesk and see if they can think of any reason for such a huge increase in run times.

Jeff.

comment:4 in reply to: ↑ 3 Changed 12 years ago by umdoc

Hi Jeff,
Thanks for the assistance; if changing the mass library doesn't help I'll contact the hpcx people.

Regards,
Ian

Replying to jeff:

One thing to try would be to use the version 10.1 mass library, I copied over the 9.1 version to maintain bit reproducibility. Not sure why this would affect stochem but this is a very strange problem. The easiest way to do this is to unpack your source code, edit the makefile.link file and change the linker option from -lmass_9.1 to -lmass, then do

make -f makefile.compile
make -f makefile.link

If this doesn't make any difference then you could try an email to the hpcx helpdesk and see if they can think of any reason for such a huge increase in run times.

Jeff.

comment:5 Changed 12 years ago by jeff

  • Resolution set to fixed
  • Status changed from assigned to closed

I didn't get around to closing this query, so I'll do it now. Did you manage to solve the problems with the new compiler?

Jeff.

Note: See TracTickets for help on using tickets.