How do I compile the CASTEP 18.1 periodic electronic structure code to run in parallel on a Cray XC30 MPP system?
Full compilation instructions for CASTEP 18.1 on the UK National Supercomputing service, ARCHER (a Cray XC30 system) can be found on Github at:
https://github.com/hpc-uk/build-instructions/blob/master/CASTEP/ARCHER_18.1.0_gcc6_CrayMPT.md
In short, load modules:
module swap PrgEnv-cray PrgEnv-gnu
module load fftw/3.3.4.11
Set the following options in Makefile:
COMMS_ARCH := mpi
FFT := fftw3
BUILD := fast
MATHLIBS := mkl10
Note the path to Intel MKL libraries and then build with:
unset CPU
make -j8 CASTEP_ARCH=linux_x86_64_gfortran6.0-XT clean
make -j8 CASTEP_ARCH=linux_x86_64_gfortran6.0-XT
The castep.mpi executable can be found at
obj/linux_x86_64_gfortran6.0-XT/castep.mpi
Related
I have to install a package (spatial-correlation-sampler) which calls for gcc: >=5.3. On my system (Linux, remote server), gcc version is 4.8.5, and a Conda virtual environment uses the same version. Is it possible to use a different version within the virtual environment?
Is it possible to use a different gcc version inside a Conda environment?
Probably yes, except if you (or your Conda environment) needs or uses some GCC plugin. These plugins are specific to a particular version of GCC: a plugin coded for GCC 4.8 (such as my old GCC MELT) won't work with GCC 6. But see also this draft report on Bismon (which might become a successor to GCC MELT).
On Linux/x86-64, a C code compiled with GCC 4.8 would be compatible with the same code compiled with GCC 10, since both follow the same ABI and calling conventions.
For C++ code compiled with GCC, there could be subtle ABI or calling conventions incompatibilities (related to name mangling and exceptions).
Be also aware that Python 2 and Python 3 have different foreign function interfaces. Read chapters related to extending and embedding the Python interpreter.
See also the Program Library HowTo, Advanced Linux Programming and C++ dlopen mini-HowTo and Linux Assembly HowTo and of course Linux From Scratch.
On my system (Linux, remote server), gcc version is 4.8.5
GCC is Free Software.
You are allowed to compile and install a more recent GCC from its source code on your system. An installed GCC 4.8 can be use to build e.g. a GCC 8 from its source code (then installed into /usr/local/bin/gcc, then you just configure wisely your $PATH variable). You could even do that with the unsupported GCC 5.
On recent Debian or Ubuntu you would install dependencies with something like sudo aptitude build-dep g++ and you might also want to use Docker. You may need to download several gigabytes.
Some companies or freelancers are able (for a fee) to compile a GCC tailored for your system. I know AdaCore, but there are many others corporations or freelancers selling support on GCC. Contact me by email for more.
PS. On a powerful AMD Threadripper 2970WX desktop, I just built GCC 10.1 with make -j8 and g++ 9.3 on Debian/Sid in 10:21.38 elapsed time, requiring less than 7 Gbytes of disk space (for both GCC source code and object files). Of course, I disabled the compiler bootstrap. You could do the same thru ssh to your system (it could take an hour or two of elapsed time, because a Linux VPS has less cores so you might need to just make -j2).
I am trying to use pocl to cross-compile OpenCL programs for RISCV64. Slide 18 at this link: https://riscv.org/wp-content/uploads/2015/01/riscv-software-toolchain-workshop-jan2015.pdf seems to suggest that it is possible to generate scalar code for the RISCV backend. I am using pocl-0.8 (based on llvm 3.3 since that is the stable version for the riscv-llvm backend).
I ran the configure command as follows:
./configure CC=/path/to/riscv/bin/riscv64-unknown-elf-gcc CXX=/path/to/riscv/bin/riscv64-unknown-elf-g++ --host=riscv64-unknown-elf
I got the following error:
configure: error: unable to find the libtool dl library (usually libltdl-dev)
I don't get any error if I configure pocl for my native system (x86_64). So, I am guessing I need the RISCV variant of the library mentioned in the error message above but I am not sure how to do that. I would appreciate any help with this. Thanks!
Do you want to run pocl on the RISC-V system generating RISC-V code or to run it on host x64 system to generate RISC-V?
Your configure command
./configure CC=riscv64-unknown-elf-gcc CXX=riscv64-unknown-elf-g++ --host=riscv64-unknown-elf
is for compiling native pocl on RISC-V which is hard (you need full cross-environment and RISC-V target cpu/emulator/board with linux, libc, and many packets). And even for this it is incorrect, as your host (machine where you start compilation of the pocl) is not riscv, but x64 (use --target to set target architecture in configure).
But if you want to run pocl on x64, don't set CC and CXX, host and target in ./configure run to get native x64 pocl. llvm will have all backend and will let you to generate RISC-V codes, when starting pocl on x64.
I came across several SO questions regarding specific aspects of improving the turn-around time of CMake enabled C++ projects lately (like "At what level should I distribute my build process?" or "cmake rebuild_cache for just a subdirectory?"), I was wondering if there is a more general guidance utilizing the specific possibilities CMake offers. If there is probably no cross-platform compile time optimization, I'm mainly interested in Visual Studio or GNU toochain based approaches.
And I'm already aware of and investing into the generally recommended areas to speed up C++ builds:
Change/Optimize/fine-tune the toolchain
Optimize your code base/software architecture (e.g by reducing the dependencies and use well-defined sub-projects - unit tests)
Invest in a better hardware (SSD, CPU, memory)
like recommended here, here or here. So my focus in this question is on the first point.
Plus I know of the recommendations to be found in CMake's Wiki:
CMake: building with all your cores
CMake Performance Tips
The former just handles the basics (parallel make), the later handles mostly how to speed-up parsing CMake files.
Just to make this a little more concrete, if I take my CMake example from here with 100 libraries using MSYS/GNU I got the following time measurement results:
$ cmake --version
cmake version 3.5.2
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ time -p cmake -G "MSYS Makefiles" ..
-- The CXX compiler identification is GNU 4.8.1
...
-- Configuring done
-- Generating done
-- Build files have been written to: [...]
real 27.03
user 0.01
sys 0.03
$ time -p make -j8
...
[100%] Built target CMakeTest
real 113.11
user 8.82
sys 33.08
So I have a total of ~140 seconds and my goal - for this admittedly very simple example - would be to get this down to about 10-20% of what I get with the standard settings/tools.
Here's what I had good results with using CMake and Visual Studio or GNU toolchains:
Exchange GNU make with Ninja. It's faster, makes use of all available CPU cores automatically and has a good dependency management. Just be aware of
a.) You need to setup the target dependencies in CMake correctly. If you get to a point where the build has a dependency to another artifact, it has to wait until those are compiled (synchronization points).
$ time -p cmake -G "Ninja" ..
-- The CXX compiler identification is GNU 4.8.1
...
real 11.06
user 0.00
sys 0.00
$ time -p ninja
...
[202/202] Linking CXX executable CMakeTest.exe
real 40.31
user 0.01
sys 0.01
b.) Linking is always such a synchronization point. So you can make more use of CMake's Object Libraries to reduce those, but it makes your CMake code a little bit uglier.
$ time -p ninja
...
[102/102] Linking CXX executable CMakeTest.exe
real 27.62
user 0.00
sys 0.04
Split less frequently changed or stable code parts into separate CMake projects and use CMake's ExternalProject_Add() or - if you e.g. switch to binary delivery of some libraries - find_library().
Think of a different set of compiler/linker options for your daily work (but only if you also have some test time/experience with the final release build options).
a.) Skip the optimization parts
b.) Try incremental linking
If you often do changes to the CMake code itself, think about rebuilding CMake from sources optimized for your machine's architecture. CMake's officially distributed binaries are just a compromise to work on every possible CPU architecture.
When I use MinGW64/MSYS to rebuild CMake 3.5.2 with e.g.
cmake -DCMAKE_BUILD_TYPE:STRING="Release"
-DCMAKE_CXX_FLAGS:STRING="-march=native -m64 -Ofast -flto"
-DCMAKE_EXE_LINKER_FLAGS:STRING="-Wl,--allow-multiple-definition"
-G "MSYS Makefiles" ..
I can accelerate the first part:
$ time -p [...]/MSYS64/bin/cmake.exe -G "Ninja" ..
real 6.46
user 0.03
sys 0.01
If your file I/O is very slow and since CMake works with dedicated binary output directories, make use of a RAM disk. If you still use a hard drive, consider switching to a solid state disk.
Depending of your final output file, exchange the GNU standard linker with the Gold Linker. Even faster than Gold Linker is lld from the LLVM project. You have to check whether it supports already the needed features on your platform.
Use Clang/c2 instead of Visual C++ compiler. For the Visual C++ compiler performance recommendations are provided from the Visual C++ team, see https://blogs.msdn.microsoft.com/vcblog/2016/10/26/recommendations-to-speed-c-builds-in-visual-studio/
Increadibuild can boost the compilation time.
References
CMake: How to setup Source, Library and CMakeLists.txt dependencies?
Replacing ld with gold - any experience?
Is the lld linker a drop-in replacement for ld and gold?
For speeding up the CMake configure time see: https://github.com/cristianadam/cmake-checks-cache
LLVM + Clang got a ~3x speedup.
I have to cross compile opensawn for a OMAP4 Board and GMP is prerequisite. First I tried it on 64 bit OS but it gave me this error:
configure: error: Oops, mp_limb_t is 64 bits, but the assembler code in this configuration expects 32 bits.
Then I shifted to Ubuntu 12.04 32 Bit and the GMP V6.0.0 got compiled after few trials. Even after having the ARCH, TOOLCHAIN and CROSS_COMPILER variables in .bashrc I had to export the following:
export ARCH=arm<BR>
export PATH=/home/harsh32bit/Work/Projects/BSQ_VVDN/BISQUARE/gcc-SourceryCodeBenchLite-arm/bin/:$PATH<BR>
export CROSS_COMPILE=arm-none-linux-gnueabi-<BR>
Then following commands were observed:
./configure --build=i686-pc-linux-gnu --host=arm-none-linux-gnueabi --prefix=/home/harsh32bit/Work/Projects/BSQ_VVDN/BISQUARE/gcc-SourceryCodeBenchLite-arm/
make clean
make
make install
Then Soft-linking GMP Library to Toolchain
~/Work/Projects/BSQ_VVDN/BISQUARE/gcc-SourceryCodeBenchLite-arm/lib/gcc/arm-none-linux-gnueabi/4.7.3
# ln -s ~/Work/Projects/BSQ_VVDN/packages/gmp-6.0.0/.libs/libgmp.so libgmp.so
I had the GMP compiled successfully although the make check reported all test failed.
9 of 9 tests failed.
Now when I try to cross compile Openswan-2.6.41 after making changes in CROSSCOMPILE.sh and do this make programs I get this error:
In file included from /home/harsh32bit/Work/Projects/BSQ_VVDN/packages/openswan-2.6.41/include/certs.h:24:0,from /home/harsh32bit/Work/Projects/BSQ_VVDN/packages/openswan-2.6.41/lib/libopenswan/id.c:42:
/home/harsh32bit/Work/Projects/BSQ_VVDN/packages/openswan-2.6.41/include/secrets.h:20:41: fatal error: gmp.h: No such file or directory
compilation terminated
I have gone to TI E2E site for this, sniffed internet for pointers in last 4 weeks but I couldn't figure out. If anyone has any clue about cross compiling openswan and GMP for ARM please advise me.
So essentially
The static linkage of gmp files had to be done sans sudo - since when you call make programs from openswan package without sudo you are not root instead a normal user and if you use make programs with sudo it misses some exported variables particularly ARCH. It takes the default architecture instead of target architecture you want to compile for; like in my case it was for arm.
If you have to use the sudo, make it readable-writeable for all. That is after linking the library files in the toolchain you can call chmod 777 on that file - because then it will be available for rw for all user groups.
I have set up target fs on
/home/myself/filesys/bin..etc//
GCC
compile:
host $ arm_v5t_le-gcc hello.c -o hello
run:
target $ cd /opt/hello
target $./hello
I have installed opencv2.3 on host ubuntu machine now I want opencv to be ported to DM6446
so i follow
uncompress opencv2.3 tarball
sudo cmake OpenCV-2.3.1
sudo make ARCH=arm CROSS_COMPILE=arm_v5t_le-
but when I run the sample test from bin it runs on x86 machine which was made for ARM
I think I am not following the correct procedure to make opencv.
Is there anything I have to do to make opencv for ARM architecture,
what are the steps to follow in cross compiling?
The 2nd command you executed should provide a clue as to whether you are cross-compiling or not. If you look closely it would have shown that it was building for the i686 and not for the ARM platform.
This blog discusses how to Cross Compile using cmake.
cmake uses different environment variables from standard make (so don't use ARCH, and CROSS-COMPILE).