whizard is hosted by Hepforge, IPPP Durham

Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#207 closed enhancement (fixed)

Split amplitudes in smaller chunks

Reported by: Juergen Reuter Owned by: ohl
Priority: P1 Milestone:
Component: omega Version: 2.0.0rc2
Severity: blocker Keywords: flags
Cc:

Description (last modified by ohl)

Large amplitudes can overflow compiler limits. Split into separate modules.

Change History (8)

comment:1 Changed 15 years ago by ohl

Component: configureomega
Description: modified (diff)
Owner: changed from ALL to ohl
Priority: P1P2
Severity: criticalmajor
Status: newassigned
Summary: introduction of compiler flag O0 for processesSplit amplitudes in smaller chunks
Type: defectenhancement

comment:2 Changed 15 years ago by sschmidt

just as an example: for the sin-file

alias q = u:U:d:D
alias j = u:U:d:D:g

!process dyuubar =   u, U -> e1, E1, j, j
!process dyuu    =   u, u -> e1, E1, j, j

process dy2 =   q, q -> e1, E1, j, j

compile

if the compiler uses the -O2 flag, the command

libtool: compile:  gfortran -c -I<build>/lib/whizard/mod/models -I<build>/include/omega -I<build>/lib/whizard/mod/whizard-core
  -I<build>/lib/whizard/mod/misc -g -O2 dy2.f90  -fPIC -o .libs/dy2.o

lets the gfortran compiler allocate some hundred MBs of memory (Then I killed it, because it used almost the entire RAM and was still getting bigger). Compilation with -O0 works without problems.

comment:3 Changed 15 years ago by Juergen Reuter

Priority: P2P1
Severity: majorblocker

OK; this seems to be an urgent must. For sm_ext, the compilation now is a killer. Would rank this even higher than the VAMP stuff (tooth-bitingly).

comment:4 Changed 15 years ago by ohl

Update:

  • For moderate cases like g g -> g g g g with -O2, there appears to be very little difference when compiling several modules in a single file or in separate files (unless we make use of multiple cpus/cores). That's a big surprise for me.
  • The speedup and reduction in memory consumption wrt. the single module case is significant with -O2.
  • I have not yet tried multiple functions in a single module.

comment:5 Changed 15 years ago by ohl

Suprise: from my first benchmarks (gl gl -> gl gl gl gl) it appears that multiple functions in a single module is significantly faster than the more elaborate approaches. The only explanation that I can come up with is that this approach keeps all variables local to a single module.

Let's see what the longer benchmarks reveal during the night ...

comment:6 Changed 15 years ago by ohl

OK, runtime benchmarks show that the penalty for splitting the functions is minimal (O(2%), much smaller than the O(40%) from optimization). Therefore we can safely make it the default.

I will merge the branch, after removing some (a lot) of duplicate code.

comment:7 Changed 15 years ago by ohl

Resolution: fixed
Status: assignedclosed

Implemented in r2276:

  -target:single_function compute the matrix element(s) in a monolithis function
  -target:split_function split the matrix element(s) into small functions [default, size = 10]
  -target:split_module split the matrix element(s) into small modules
  -target:split_file split the matrix element(s) into small files

comment:8 Changed 14 years ago by Juergen Reuter

Milestone: v2.0.0final

Milestone v2.0.0final deleted

Note: See TracTickets for help on using tickets.