2012-10-09 14 views
5

Ho eseguito alcuni test su un progetto che ho recentemente iniziato a costruire con CMake. Prima di passare a CMake ho notato miglioramenti significativi nei tempi di costruzione quando si utilizzava l'opzione -j per make con il mio Makefile scritto a mano.Lavori paralleli utilizzando un makefile generato da CMake (nessun miglioramento della velocità)

Ora con CMake faccio la stessa cosa e non c'è alcun aumento notevole della velocità. Sia che corro con -j o no, ottengo quattro processi per make.exe, anche se solo uno di loro sta facendo il cronometro della CPU e non usa mai più il 25% della CPU.

In generale, il Makefile generato da CMake è molto più lento del mio Makefile scritto a mano. Un rapido test mostra costruiscono le volte che sia CMake e makefile scritte a mano con e senza la bandiera -j:

CMake: "make -j all" = 7min 
CMake: "make all" = 7min 
Handwritten: "make -j all" = 2min 
Handwritten: "make all" = 4min 

In generale, CMake è molto più lento e non sembra di utilizzare i lavori paralleli.

Qualcuno può spiegare perché non vedo miglioramenti?

(Creare un programma Fortran con gfortran e utilizzare la funzione di dipendenza con rilevamento automatico di CMake ... anche se non so se questo è rilevante per quello che sto vedendo).

Ecco il mio file CMakeLists.txt:

## CMake Version 
cmake_minimum_required(VERSION 2.8) 

## Project Name 
project(PROJECT) 

## Use FORTRAN 
enable_language(Fortran) 

## Release compiler options 
set (CMAKE_Fortran_FLAGS_RELEASE "-O3 -cpp -ffree-line-length-none -fimplicit-none") 

## Debug compiler options 
set (CMAKE_Fortran_FLAGS_DEBUG "-g -cpp -ffree-line-length-none -fimplicit-none") 

## Set directory for FORTRAN modules 
set (CMAKE_Fortran_MODULE_DIRECTORY "${PROJECT_BINARY_DIR}/modules") 

## Build Executable 
add_executable(EXE 
      Source1.f90 
      Source2.f90   
      . 
      . 
      . 
      Source219.f90 
      Source220.f90) 

Ed ecco la mia Makefile originale:

PROG = PROGRAM.exe 

SRCS = Source1.f90 Source2.f90 ... Source219.o Source220.o 

OBJS = Source1.o Source2.o ... Source219.o Source220.o 

LIBS = 

VPATH = src 
BUILDDIR = debug 
F90 = gfortran 
F90FLAGS = -g -cpp -ffree-line-length-none -fimplicit-none 

all: $(PROG) 

$(PROG): $(OBJS) 
    $(F90) -o [email protected] $(OBJS) $(LIBS) 


clean: 
    erase -f $(BUILDDIR)$(PROG) $(BUILDDIR)\$(OBJS) $(BUILDDIR)\*.mod 

.SUFFIXES: $(SUFFIXES) .f90 

.f90.o: 
    $(F90) $(F90FLAGS) -c $< 

Source1.o: Dependency1.o Dependency2.o ... DependencyN.o 

Source2.o: Dependency1.o Dependency2.o ... DependencyN.o 

. 
. 
. 

Source219.o: Dependency1.o Dependency2.o ... DependencyN.o 

Source220.o: Dependency1.o Dependency2.o ... DependencyN.o 
+1

Potete mostrare il vostro 'CMakeLists.txt'? – arrowd

+0

Ho appena pubblicato il mio file CMakeLists.txt –

+0

e anche il tuo Makefile originale. – Offirmo

risposta

5

È questo su Windows? Se è così, perché la versione di Windows di gmake non ha un job server e i makefile ricorsivi non sono paralleli. Presumo che quando hai scritto make.exe significa windows. Penso che CVS gmake abbia ora un server per i lavori. Cygwin gmake supporta anche il job server.

Questo collegamento potrebbe aiutare:

http://lists.gnu.org/archive/html/make-w32/2011-07/msg00002.html

+0

Quindi come funzionerebbe la parallelizzazione con il suo Makefile personalizzato se fosse una caratteristica mancante del make? – Offirmo

+0

Il suo makefile personalizzato non è ricorsivo. Non chiama make from make. CMake ha generato makefile. Vedi qui: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F –

+0

Interessante. Questa potrebbe essere la ragione, allora. – Offirmo

Problemi correlati