Compiling for MIC backend on Windows
July 30, 2014 at 17:42 #802
I compiled Paralution on Windows by building the paralution_omp_VS12 project with the latest version of Intel Parallel studio. I got the code up and running in OMP mode on the host, but what I really want to do is run it with OMP on a MIC. It seems, however, there is no pre-made VS projects that compiles the MIC backend.
I looked through the makefiles trying to figure out what would be needed to manually include mic backend support in the omp_vs12 project, but having spend most of the day on the project I still can’t get it to work.
Any help will be greatly appreciated …July 30, 2014 at 18:16 #803
We do not have Xeon Phi system with Windows therefore we do not have a VS project for it.
You have two options to compile PARALUTION with Xeon Phi support under Windows:
1) Use cmake – you can download it for Windows and try to compile it by following the instruction (for Linux).
2) Add all src/host/mic/* files to the paralution_omp_VS12 and declare a marco SUPPORT_MIC. Then compile with the Intel compiler.
I hope this can help you. Keep us posted with this issue.
DimitarJuly 31, 2014 at 08:46 #806
Option 2 is exactly what I figured I should try out, but I ran into a few problems on the way.
When compiling mic_utils.hff a warning is thrown a few times: Offload features on this platform currently require that RTTI be disabled. However, if I disable RTTI the code does not compile at all. Should I just ignore the warning?
In mic_vector_kernel.hpp the two templates “template
void amax” and “template
void asum” include calls to the fabs function. These calls produce the compiler error “more than one instance of overloaded function “fabs” matches the argument list”. I changed these two calls from fabs->abs and the code now compiles. My c++ knowledge is a bit limited, however,so I would be great if you could confirm that there are no unintended side effects to making this kind of change inside a template with dynamic arguments?
Last problem is that the linker fails to link the code, which I initially thought was because of me doing something wrong. However, now that you have confirmed I am on the right path I have a post on Intels user forums that suggest it is due to an error in parallel studio. I have submitted a post on the issue in the intel forums and will hopefully have a workaround on the linking soon …July 31, 2014 at 09:45 #807
I would recommend you to try also the second option – using cmake under windows. I know, this might be a pain as well …
About your issues:
1) The RTTI is necessary for the library and you cannot disable it. However, you are probably trying to compile the whole library for the MIC. This is not necessary – you need to compile only the src/base/mic/* files with -offload-option,mic (you can check our Makefile in src/). Basically, the library runs on the host and just offload functions to the MIC. You can check our Makefile for details.
2) I think this should be ok, some compilers are picky about that … it is a bit strange that we do not see this with the icc under Linux…
3) You need to compile the library with normal options for the host and only the src/base/mic/* with the offload to mic option. Under Linux you also need to say that everything should be with -fPIC, this is necessary for the linking.
It might be faster if you just put the Xeon Phi card on a Linux system…
DimitarJuly 31, 2014 at 11:17 #808
Thanks a lot Dimitar!
Moving to Linux is not an option I am afraid ..
Are you sure that you mean -offload-option,mic and not -offload-attribute-target=mic?
As i understand it the MIC offload compiler is only invoked for files that include offload directives, which means all the rest of the files should go untouched no matter what. The way I read the documentation -offload-option,mic is just an option that allows for passing additional compiler switches to the offload compiler (“Lets you explicitly specify options to be used for the specified target and tool.”).
After doing a search in the paralution code I don’t find any __declspec(target(mic)) declarations, so I think you are saying that the MIC backend files should be compiled with the -offload-attribute-target=mic setting?
CJuly 31, 2014 at 11:42 #809
Yes, I am sure. All functions in src/base/mic/* are with offload directives. We compile all MIC files with:
-O3 -Wall -openmp -offload-option,mic,compiler,”-z defs” -fPIC
and rest (all non mic files) with:
-O3 -Wall -openmp -fPIC
For the offload functions, you can check mic_vector_kernel.hpp, the offload looks like that:
#pragma offload target(mic:mic_dev) \
in(vec1:length(0) MIC_REUSE MIC_RETAIN) \
in(vec2:length(0) MIC_REUSE MIC_RETAIN)
#pragma omp parallel for
for (int i=0; iAugust 5, 2014 at 12:52 #816
I have been in contact with Intel and they confirm that there are a number of critical bugs in linking static offload libraries on Windows in the current version of parallel studio. The issues should be resolved in release 15.0 due later this month, so I will postpone further work on the project till then ..
I also contacted Intel about the RTTI warning issue and this issue could turn out to be even more critical. It turns out there are serious limitations in how RTTI can be used in offload application running off a Windows host. I quote Intels reply to most post below and also include a link to the original in the Intel forums. Based on the stated RTTI limitations, do you think it will be possible to run MIC offload on a Windows host or should I just forget about it and move on? :-(
Quote: “Here is a collection of notes that I have gathered about the RTTI restriction on Windows and its impact when using the Language Extensions for Offload (LEO):
There are no plans to support RTTI within offload code on Windows. This is a permanent restriction.
The program cannot have _Cilk_shared or target(mic) types with RTTI enabled.
The appearance of the warning does not imply the code may not use the language extensions for offload. The warning is issued (using a broad brush) when any language extensions for offload are detected in the source file (.cpp) and this in part is why this is only a warning and not an error under the data marshalling (#pragma/!dir$ offload) model.
Attempts to use RTTI with the virtual shared model language extensions for offload (_Cilk_shared) trigger compilation errors.
Applications where the RTTI is not used in any offload code (under data marshalling model); one’s that can section off code such that RTTI is enabled only in non-offloaded code, could (in theory) ignore the warning.
Under the non-shared data marshalling (#pragma/!dir$ offload) model it is permissions to use RTTI locally on the host or MIC but without any sharing.
There is no support for sharing (i.e. sending/receiving) because the structure of the objects has pointers that fall into non-bitwise copyable restriction.
On Windows users must explicitly disable RTTI when using Language Extensions for Offload if the class object is used in an offload region. This is because on Windows the RTTI pointer is stored as a 32bit pointer. Windows image is 32bit and so you can use image offset to store any pointer. On Linux it is stored as 64bit pointer.
Hopefully this helps determine the impact on your application. If not or if you have additional questions related to some specific code then let me know and I’m happy to inquire with our Developers.”August 6, 2014 at 11:49 #817
The RTTI is an essential part of the library and you cannot disable it. However the RTTI is not used in the offload regions, we use RTTI only for the host code. Actually I think this should work, because the Xeon Phi code which you need to compile (in src/base/mic/*) has no RTTI. So, there is still hope.
DimitarAugust 6, 2014 at 16:25 #818
Thank you – that is good news … :-)
I will resume the project once Intels version 15.0 compiler is out and let you know how it goes …
You must be logged in to reply to this topic.