/* * This file is part of the StarPU Handbook. * Copyright (C) 2009--2011 Universit@'e de Bordeaux 1 * Copyright (C) 2010, 2011, 2012, 2013, 2014 Centre National de la Recherche Scientifique * Copyright (C) 2011, 2012 Institut National de Recherche en Informatique et Automatique * See the file version.doxy for copying conditions. */ /*! \page BuildingAndInstallingStarPU Building and Installing StarPU \section InstallingABinaryPackage Installing a Binary Package One of the StarPU developers being a Debian Developer, the packages are well integrated and very uptodate. To see which packages are available, simply type: \verbatim $ apt-cache search starpu \endverbatim To install what you need, type for example: \verbatim $ sudo apt-get install libstarpu-1.2 libstarpu-dev \endverbatim \section InstallingFromSource Installing from Source StarPU can be built and installed by the standard means of the GNU autotools. The following chapter is intended to briefly remind how these tools can be used to install StarPU. \subsection OptionalDependencies Optional Dependencies The hwloc topology discovery library is not mandatory to use StarPU but strongly recommended. It allows for topology aware scheduling, which improves performance. hwloc is available in major free operating system distributions, and for most operating systems. If hwloc is not available on your system, the option \ref without-hwloc "--without-hwloc" should be explicitely given when calling the configure script. If hwloc is installed with a pkg-config file, no option is required, it will be detected automatically, otherwise \ref with-hwloc "--with-hwloc" should be used to specify its location. \subsection GettingSources Getting Sources StarPU's sources can be obtained from the download page of the StarPU website. All releases and the development tree of StarPU are freely available on INRIA's gforge under the LGPL license. Some releases are available under the BSD license. The latest release can be downloaded from the INRIA's gforge or directly from the StarPU download page. The latest nightly snapshot can be downloaded from the StarPU gforge website. \verbatim $ wget http://starpu.gforge.inria.fr/testing/starpu-nightly-latest.tar.gz \endverbatim And finally, current development version is also accessible via svn. It should be used only if you need the very latest changes (i.e. less than a day!). Note that the client side of the software Subversion can be obtained from http://subversion.tigris.org. If you are running on Windows, you will probably prefer to use TortoiseSVN. \verbatim $ svn checkout svn://scm.gforge.inria.fr/svn/starpu/trunk StarPU \endverbatim \subsection ConfiguringStarPU Configuring StarPU Running autogen.sh is not necessary when using the tarball releases of StarPU. If you are using the source code from the svn repository, you first need to generate the configure scripts and the Makefiles. This requires the availability of autoconf and automake >= 2.60. \verbatim $ ./autogen.sh \endverbatim You then need to configure StarPU. Details about options that are useful to give to ./configure are given in \ref CompilationConfiguration. \verbatim $ ./configure \endverbatim If configure does not detect some software or produces errors, please make sure to post the content of config.log when reporting the issue. By default, the files produced during the compilation are placed in the source directory. As the compilation generates a lot of files, it is advised to put them all in a separate directory. It is then easier to cleanup, and this allows to compile several configurations out of the same source tree. For that, simply enter the directory where you want the compilation to produce its files, and invoke the configure script located in the StarPU source directory. \verbatim $ mkdir build $ cd build $ ../configure \endverbatim \subsection BuildingStarPU Building StarPU \verbatim $ make \endverbatim Once everything is built, you may want to test the result. An extensive set of regression tests is provided with StarPU. Running the tests is done by calling make check. These tests are run every night and the result from the main profile is publicly available. \verbatim $ make check \endverbatim \subsection InstallingStarPU Installing StarPU In order to install StarPU at the location that was specified during configuration: \verbatim $ make install \endverbatim Libtool interface versioning information are included in libraries names (libstarpu-1.2.so, libstarpumpi-1.2.so and libstarpufft-1.2.so). \section SettingUpYourOwnCode Setting up Your Own Code \subsection SettingFlagsForCompilingLinkingAndRunningApplications Setting Flags for Compiling, Linking and Running Applications StarPU provides a pkg-config executable to obtain relevant compiler and linker flags. As compiling and linking an application against StarPU may require to use specific flags or libraries (for instance CUDA or libspe2). If StarPU was not installed at some standard location, the path of StarPU's library must be specified in the environment variable PKG_CONFIG_PATH so that pkg-config can find it. For example if StarPU was installed in $prefix_dir: \verbatim $ PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$prefix_dir/lib/pkgconfig \endverbatim The flags required to compile or link against StarPU are then accessible with the following commands: \verbatim $ pkg-config --cflags starpu-1.2 # options for the compiler $ pkg-config --libs starpu-1.2 # options for the linker \endverbatim Note that it is still possible to use the API provided in the version 1.0 of StarPU by calling pkg-config with the starpu-1.0 package. Similar packages are provided for starpumpi-1.0 and starpufft-1.0. It is also possible to use the API provided in the version 0.9 of StarPU by calling pkg-config with the libstarpu package. Similar packages are provided for libstarpumpi and libstarpufft. Make sure that pkg-config --libs starpu-1.2 actually produces some output before going further: PKG_CONFIG_PATH has to point to the place where starpu-1.2.pc was installed during make install. Also pass the option --static if the application is to be linked statically. It is also necessary to set the environment variable LD_LIBRARY_PATH to locate dynamic libraries at runtime. \verbatim $ LD_LIBRARY_PATH=$prefix_dir/lib:$LD_LIBRARY_PATH \endverbatim When using a Makefile, the following lines can be added to set the options for the compiler and the linker: \verbatim CFLAGS += $$(pkg-config --cflags starpu-1.2) LDFLAGS += $$(pkg-config --libs starpu-1.2) \endverbatim \subsection RunningABasicStarPUApplication Running a Basic StarPU Application Basic examples using StarPU are built in the directory examples/basic_examples/ (and installed in $prefix_dir/lib/starpu/examples/). You can for example run the example vector_scal. \verbatim $ ./examples/basic_examples/vector_scal BEFORE: First element was 1.000000 AFTER: First element is 3.140000 \endverbatim When StarPU is used for the first time, the directory $STARPU_HOME/.starpu/ is created, performance models will be stored in that directory (\ref STARPU_HOME). Please note that buses are benchmarked when StarPU is launched for the first time. This may take a few minutes, or less if hwloc is installed. This step is done only once per user and per machine. \subsection KernelThreadsStartedByStarPU Kernel Threads Started by StarPU StarPU automatically binds one thread per CPU core. It does not use SMT/hyperthreading because kernels are usually already optimized for using a full core, and using hyperthreading would make kernel calibration rather random. Since driving GPUs is a CPU-consuming task, StarPU dedicates one core per GPU. While StarPU tasks are executing, the application is not supposed to do computations in the threads it starts itself, tasks should be used instead. TODO: add a StarPU function to bind an application thread (e.g. the main thread) to a dedicated core (and thus disable the corresponding StarPU CPU worker). \subsection EnablingOpenCL Enabling OpenCL When both CUDA and OpenCL drivers are enabled, StarPU will launch an OpenCL worker for NVIDIA GPUs only if CUDA is not already running on them. This design choice was necessary as OpenCL and CUDA can not run at the same time on the same NVIDIA GPU, as there is currently no interoperability between them. To enable OpenCL, you need either to disable CUDA when configuring StarPU: \verbatim $ ./configure --disable-cuda \endverbatim or when running applications: \verbatim $ STARPU_NCUDA=0 ./application \endverbatim OpenCL will automatically be started on any device not yet used by CUDA. So on a machine running 4 GPUS, it is therefore possible to enable CUDA on 2 devices, and OpenCL on the 2 other devices by doing so: \verbatim $ STARPU_NCUDA=2 ./application \endverbatim \section BenchmarkingStarPU Benchmarking StarPU Some interesting benchmarks are installed among examples in $prefix_dir/lib/starpu/examples/. Make sure to try various schedulers, for instance STARPU_SCHED=dmda. \subsection TaskSizeOverhead Task Size Overhead This benchmark gives a glimpse into how long a task should be (in µs) for StarPU overhead to be low enough to keep efficiency. Running tasks_size_overhead.sh generates a plot of the speedup of tasks of various sizes, depending on the number of CPUs being used. \image html tasks_size_overhead.png \image latex tasks_size_overhead.eps "" width=\textwidth \subsection DataTransferLatency Data Transfer Latency local_pingpong performs a ping-pong between the first two CUDA nodes, and prints the measured latency. \subsection MatrixMatrixMultiplication Matrix-Matrix Multiplication sgemm and dgemm perform a blocked matrix-matrix multiplication using BLAS and cuBLAS. They output the obtained GFlops. \subsection CholeskyFactorization Cholesky Factorization cholesky_* perform a Cholesky factorization (single precision). They use different dependency primitives. \subsection LUFactorization LU Factorization lu_* perform an LU factorization. They use different dependency primitives. */