Want to baseline a standard fortran code that does not contain cuda code before I upgrade it. Can I do that and if so, how?
If you have CUDA 7.5 you can do the following.
nvprof --cpu-profiling on ./a.out
Related
I am compiling a Lua script into a binary on MacOS Catalina.
luac -s -o bin/my-binary.luac src/my-code.lua"
However, the application consuming the compiled script runs a 32-bit version of Lua and can't read the bytecode of the 64-bit compiled Lua script. (Error message: bad header in precompiled chunk).
Can I somehow (cross)compile the Lua script on current MacOS to a 32-bit binary?
My alternative would be doing the compilation with Docker but maybe there is an even simpler approach.
I don't see any option for cross-compilation or changing the bitness, but you may be able to tweak the Lua code to produce the code you need. Here is the maillist thread for Lua 5.1 that recommends using #define LUAC_STR_SIZE_TYPE int.
If this doesn't work, you may be able to change ldump.c to produce 32-bit compatible code. The source code has the following comment (5.4): All high-level dumps go through dumpVector; you can change it to change the endianness of the result. You may be able to update it to change bitness by changing handling of DIBS, dumpSize, and several other places.
I need to call some Fortran code from within MATLAB. I did some research and read about the mex command and how to use it. Sadly I'm already failing at getting the Fortran compiler to work.
First of all, here's my setup:
macOS Sierra 10.12.1 (latest version)
MATLAB R2016b (latest version)
gfortran 4.9.2 (installed via .dmg from official GNU site)
According to the MATLAB documentation, I can use mex -setup FORTRAN to prepare mex for building a mex-file from Fortran. However, running the command in verbose mode yields the following output: mex -setup -v FORTRAN
Verbose mode is on.
... Looking for compiler 'Intel Fortran Composer XE' ...
... Looking for environment variable 'IFORT_COMPILER16' ...No.
... Looking for environment variable 'IFORT_COMPILER15' ...No.
... Looking for environment variable 'IFORT_COMPILER14' ...No.
... Looking for environment variable 'IFORT_COMPILER13' ...No.
... Executing command 'which ifort' ...No.
Did not find installed compiler 'Intel Fortran Composer XE'.
Error using mex
No supported compiler or SDK was found. For options, visit
http://www.mathworks.com/support/compilers/R2016b/maci64.html.
Following the link, one can see that MATLAB does support GNU gfortran 4.9.x on Linux. On Mac however, only Intel's commercial compilers are listed as supported. That's what mex seems to be looking for as well.
Since Mac can also use gfortran to compile Fortran code I thought it'd be possible to get it to work with MATLAB. I've also googled alot and found questions like this one on the MathWorks forum, which suggests that MATLAB should be able to use gfortran, even on Mac.
That's what I think is strange, my MATLAB isn't even looking for a gfortran compiler. All it does is look for an Intel compiler, can't find one and then throws above stated error message.
Regarding my gfortran installation. It is definitely 4.9.2 (which is listed as supported under Linux), which gfortran returns /usr/local/bin and I can successfully compile programs via Terminal.
By the way, mex -setup ANY successfully lists the compilers for C and C++ but no Fortran.
MEX configured to use 'Xcode with Clang' for C language compilation.
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the
new API. You can find more information about this at:
http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html.
MEX configured to use 'Xcode Clang++' for C++ language compilation.
Warning: The MATLAB C and Fortran API has changed to support MATLAB
variables with more than 2^32-1 elements. In the near future
you will be required to update your code to utilize the
new API. You can find more information about this at:
http://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html.
To choose a different C compiler, select one from the following:
Xcode with Clang mex -setup:'/Users/Lennart/Library/Application Support/MathWorks/MATLAB/R2016b/mex_C_maci64.xml' C
Xcode Clang++ mex -setup:'/Users/Lennart/Library/Application Support/MathWorks/MATLAB/R2016b/mex_C++_maci64.xml'
I also had a look at those .xml files mentioned at the very end of the last output. There was no file for anything having to do with Fortran and I wasn't able to successfully write one myself. I'm not even sure whether that's the problem...
So simply put my question is: How can I get MATLAB to actually look for and then of course also find my gfortran compiler to use it to compile mex files?
Appreciate your help!
Thanks to hsuyaa and the provided link I was able to resolve my problem. As it needed some more experimenting by myself, I'd like to post how exactly I was able to get gfortran to work.
Look at this link and the accepted answer. Although the MathWorks Team explicitly states that the instructions are specifically written for xCode 7.0 and MATLAB R2015b, I got everything to work with xCode 8.1, MATLAB R2016b and macOS Sierra 10.12.
MATLAB seems to be storing the compiler configuration details in .xml-files as mentioned before. You can find the directory in MATLAB by entering
cd( fullfile( matlabroot, 'bin', 'maci64', 'mexopts' ) );
I did perform a fresh install of MATLAB before but at that location, only three files where located, one for Clang, one for Clang++, one for Intel's Fortran. The gfortran one was simply missing.
The solution author at MathWorks appended all of these .xml-files to his post. I downloaded the files and copied gfortran.xml to the above mentioned folder. This granted partial success in that it made MATLAB actually look for gfortran when running the mex setup.
However, since the files are not up-to-date, I had to add a few lines. I don't exactly understand how the configuration files work, but I noticed that some lines where referring to older macOS versions. Download the file gfortran.xml behind the above link and then add the following:
Wherever you see
<dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk" />
or
<cmdReturns name="find $$ -name MacOSX10.11.sdk" />
also add
<dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk" />
or
<cmdReturns name="find $$ -name MacOSX10.12.sdk" />
macOS 10.12 is Sierra. Saving the file and running mex -setup FORTRAN again successfully identified gfortran and set it as the fortran compiler for mex.
Your matlab version is not able to detect the supported compilers. May be this Link can help.
The question is about a specific combination of versions but is relevant more generally.
I've just dist-upgraded from Kubuntu 12.04 to 14.04. Now, when I want to compile CUDA code (with CUDA 6.5), I get:
#error -- unsupported GNU version! gcc 4.9 and up are not supported!
I installed gcc-4.8 (and 4.7), and tried to use the symlinks-in-/usr/local/cuda/bin solution suggested here:
CUDA incompatible with my gcc version
but this doesn't work. What should I do?
This solution is relevant to multiple combinations of CUDA and GCC versions.
You can tell CUDA's nvcc to use a specific version of gcc. So, suppose you want gcc 4.7 for use with CUDA 6. You run:
sudo apt-get install gcc-4.7 g++-4.7
and then add the following switch to your nvcc command-line:
nvcc --compiler-bindir /usr/bin/gcc-4.7 # rest of the command line here
If you're building with CMake, add an appropriate setting before looking for CUDA to your CMakeLists.txt, e.g.:
set(CUDA_HOST_COMPILER /usr/bin/gcc-4.7) # -> ADD THIS LINE <-
find_package(CUDA)
Also, it seems clang can compile CUDA as well, maybe that's worth experimenting with (although you would have to build it appropriately).
Note: Some Linux (or other OS) distributions don't have packages for multiple versions of gcc (in the same release of the OS distribution). I would advise against trying to install a package from another release of the distribution on an older release, and consider building gcc instead. That's not entirely trivial but it is quite doable - and of course, it's your only option if you don't have root access to your machine.
Switch back to a supported config. They are listed in the getting started document for any recent CUDA distribution.
For your particular configuration you have currently listed, you might have better luck with CUDA 7 RC, which is now available to registered developers.
I had a similar issue with CUDA Toolkit 7.5 and gcc 5.2.1.
I did modify the host_config.h file in /usr/local/cuda/include/:
Just remove the lines where it check the gcc version. It did solve my problem.
Credits goes to Darren Garvey (https://groups.google.com/forum/#!topic/torch7/WaNmWZqMnzw)
Very often you will find that CUDA has had newer releases by the time you encounter this problem. For example, the original formulation of the question was about CUDA 6 and GCC 4.9; CUDA 7 supported GCC 4.9. CUDA 8 supports GCC 5.x . And so on.
In one application, I've got a bunch of CUDA kernels. Some use dynamic parallelism and some don't. For the purposes of either providing a fallback option if this is not supported, or simply allowing the application to continue but with reduced/partially available features, how can I go about compiling?
At the moment I'm getting invalid device function when running kernels compiled with -arch=sm_35 on a 670 (max sm_30) that don't require compute 3.5.
AFAIK you can't use multiple -arch=sm_* arguments and using multiple -gencode=* doesn't help. Also for separable compilation I've had to create an additional object file using -dlink, but this doesn't get created when using compute 3.0 (nvlink fatal : no candidate found in fatbinary due to -lcudadevrt, which I've needed for 3.5), how should I deal with this?
I believe this issue has been addressed now in CUDA 6.
Here's my simple test:
$ cat t264.cu
#include <stdio.h>
__global__ void kernel1(){
printf("Hello from DP Kernel\n");
}
__global__ void kernel2(){
#if __CUDA_ARCH__ >= 350
kernel1<<<1,1>>>();
#else
printf("Hello from non-DP Kernel\n");
#endif
}
int main(){
kernel2<<<1,1>>>();
cudaDeviceSynchronize();
return 0;
}
$ nvcc -O3 -gencode arch=compute_20,code=sm_20 -gencode arch=compute_35,code=sm_35 -rdc=true -o t264 t264.cu -lcudadevrt
$ CUDA_VISIBLE_DEVICES="0" ./t264
Hello from non-DP Kernel
$ CUDA_VISIBLE_DEVICES="1" ./t264
Hello from DP Kernel
$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2013 NVIDIA Corporation
Built on Sat_Jan_25_17:33:19_PST_2014
Cuda compilation tools, release 6.0, V6.0.1
$
In my case, device 0 is a Quadro5000, a cc 2.0 device, and device 1 is a GeForce GT 640, a cc 3.5 device.
I don't believe there is a way to do this using the runtime API as of CUDA 5.5.
The only way I can think of to get around the problem is to use the driver API to perform your own architecture selection and load code from different cubin files at runtime. The APIs can be safely mixed, so it is only the context establishment-device selection-module load phase which needs to be done with the driver API. You can use the runtime API after that - you will need a little bit of homemade syntactic sugar for the kernel launches, but otherwise no code changes are required in other runtime API code.
I've recently installed a mips-linux-gnu-gcc crosstool in my linux machine which is based on i686. When I want to compile some codes, it showed me that error.
Every installing step was followed by http://developer.mips.com/tools/compilers/open-source-toolchain-linux/
After I installed the crosstool, I wrote a simple helloworld C file like this:
#include<stdio.h>
int main(void)
{
printf("Hello World!\n");
return 0;
}
But when I run:
/mips-linux-gnu-gcc hello.c -o hello -static
The compiler just print error:
bash: ./mips-linux-gnu-gcc: cannot execute binary file
I'm wondering maybe I've made some mistakes in some steps, but I can't figure it out.
Maybe some of you can help me, I'm confused by the problem.
The compiler you downloaded from MIPS is a 64-bit executable. Are you running a 32-bit host?
If you need a cross compiler for a 32-bit host targeting MIPS GNU/Linux, consider using the Sourcery CodeBench Lite compiler for MIPS GNU/Linux targets:
Sourcery CodeBench Lite for MIPS GNU/Linux
The link to the Sourcery CodeBench tools above comes from the MIPS pages just one level up from the link you provided:
MIPS Compilers Page
It looks like the mips-linux-gnu-gcc binary does not match the architecture of the machine you are trying to run it on. This might be something like a 32/64 bit mismatch.
Try using the free Mentor/Codesourcery MIPS gnu/gcc cross compilation tool chain instead. You can download from here.