2012-10-09 20 views
5

He estado haciendo algunas pruebas en un proyecto que comencé a construir recientemente con CMake. Antes de pasar a CMake noté mejoras significativas en el tiempo de compilación cuando uso la opción -j para make con mi archivo manuscrito.Trabajos paralelos utilizando un archivo MAKE generado (sin mejora de velocidad)

Ahora con CMake hago lo mismo y no hay un aumento notable en la velocidad. Si ejecuto con -j o no, obtengo cuatro procesos para make.exe, aunque solo uno de ellos está marcando el tiempo de CPU y nunca usa más el 25% de la CPU.

En general, The CMake generated Makefile es mucho más lento que mi archivo Makefile escrito a mano. A muestra las pruebas rápidas construir veces para el CMake y archivos make escritas a mano con y sin la bandera -j:

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

En general, CMake es mucho más lento y no parece utilizar trabajos paralelos.

¿Alguien puede explicar por qué no veo ninguna mejora?

(Creando un programa Fortran con gfortran y usando la función de dependencia de autodetección de CMake ... aunque no sé si eso es relevante para lo que estoy viendo).

Aquí está mi archivo 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) 

Y aquí es mi Makefile original:

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

¿Puede mostrar su 'CMakeLists.txt'? – arrowd

+0

Acabo de publicar mi archivo CMakeLists.txt –

+0

y su Makefile original, también. – Offirmo

Respuesta

5

¿Es esto en Windows? Si es así, es porque la versión de Windows de gmake no tiene un servidor de trabajos y los archivos make no son paralelos. Supongo que cuando escribió make.exe eso significa Windows. Creo que CVS gmake tiene un servidor de trabajos ahora. Cygwin gmake también es compatible con el servidor de trabajos.

Este enlace te pueden ayudar:

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

+0

Entonces, ¿cómo funcionaría la paralelización con su Makefile personalizado si fuera una característica que falta de make? – Offirmo

+0

Su archivo MAKE personalizado no es recursivo. No llama make from make. CMake generó makefiles do. Vea aquí: http://www.cmake.org/Wiki/CMake_FAQ#Why_does_CMake_generate_recursive_Makefiles.3F –

+0

Interesante. Esa puede ser la razón, entonces. – Offirmo

Cuestiones relacionadas