2012-10-09 8 views
5

Ich habe einige Tests an einem Projekt durchgeführt, das ich kürzlich mit CMake gebaut habe. Bevor ich zu CMake wechselte, bemerkte ich signifikante Verbesserungen in der Bauzeit, wenn ich die -j Option für make mit meinem handgeschriebenen Makefile benutze.Parallele Jobs mit einem CMake generierten Makefile (keine Geschwindigkeitsverbesserung)

Jetzt mit CMake mache ich das gleiche und es gibt keine merkliche Steigerung der Geschwindigkeit. Ob ich mit -j laufe oder nicht, bekomme ich vier Prozesse für make.exe, obwohl nur einer von ihnen CPU-Zeit taktet und nie mehr die 25% der CPU verwendet.

Im Allgemeinen ist das CMake erzeugte Makefile viel langsamer als mein handgeschriebenes Makefile. Ein kurzer Test zeigt Bauzeiten für beide CMake und handgeschriebener Makefiles mit und ohne -j Flagge:

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

Im Allgemeinen CMake ist viel langsamer und scheint nicht parallel Arbeitsplätze zu nutzen.

Kann mir jemand erklären, warum ich keine Verbesserungen sehe?

(Erstellen Sie ein Fortran-Programm mit Gfortran und mit CMake die automatische Erkennung Abhängigkeitsfunktion ... obwohl ich nicht weiß, ob das für das, was ich sehe, relevant ist).

Hier ist meine CMakeLists.txt Datei:

## 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) 

Und hier ist meine ursprüngliche Makefile:

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

Können Sie Ihre 'CMakeLists.txt' zeigen? – arrowd

+0

Ich habe gerade meine CMakeLists.txt-Datei –

+0

und dein original Makefile gepostet. – Offirmo

Antwort

5

Ist das auf Windows? Wenn das so ist, weil die Windows-Version von gmake keinen Job-Server hat und rekursive Makefiles nicht parallel sind. Ich nehme an, dass, wenn Sie make.exe geschrieben haben, das Windows bedeutet. Ich denke, CVS gmake hat jetzt einen Jobserver. Das cygwin gmake unterstützt auch den Jobserver.

Dieser Link könnte Ihnen helfen:

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

+0

Wie würde dann die Parallelisierung mit seinem benutzerdefinierten Makefile funktionieren, wenn es eine fehlende Funktion von make wäre? – Offirmo

+0

Sein benutzerdefiniertes Makefile ist nicht rekursiv. Es nennt nicht make from make. CMake erzeugte Makefiles tun. Siehe hier: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F –

+0

Interessant. Das könnte dann der Grund sein. – Offirmo

Verwandte Themen