Compiling for MIC backend on Windows

Front page Forums Installation Compiling for MIC backend on Windows

This topic contains 8 replies, has 2 voices, and was last updated by  cas2 3 years, 4 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #802

    cas2
    Participant

    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 …

    #803

    Dimitar
    Member

    Hi,

    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).

    or

    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.

    Best,
    Dimitar

    #806

    cas2
    Participant

    Thanks Dimitar

    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 …

    #807

    Dimitar
    Member

    Hi,

    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…

    Best,
    Dimitar

    #808

    cas2
    Participant

    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?

    Thanks!

    C

    #809

    Dimitar
    Member

    Hi,

    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; i

    #816

    cas2
    Participant

    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? :-(

    Thanks!

    C

    https://software.intel.com/en-us/forums/topic/519870

    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.”

    #817

    Dimitar
    Member

    Hi,

    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.

    Best,
    Dimitar

    #818

    cas2
    Participant

    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 …

    Best regards,

    C

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.