Using uSCIF.dll in Windows 7

[John_F_1]

I am trying to use uSCIF.dll in Windows 7 Enterprise and running into problems.  When I launch an application which depends on this DLL I get a dialogue:

The application was unable to start correctly (0xc0000142). Click OK to close the application.

This same executable works fine on Windows Server 2008 R2 Enterprise. I have MPSS 3.2.1 on both systems. Do you know the cause for this error?

[John_F_1]

It appears that the variable here is the presence of a MIC card in the machine. I get the same error on a 2008 server that does not have a MIC installed. Is there a version of uSCIF that can operate on cpu only? It would be useful for debugging.

[John_F_1]

Should this be reported as a bug?

[Loc_N_Intel]

Hi John,

What compiler version are you using? Is it possible that you attach your sample program so I can reproduce the problem? Thank you.

[John_F_1]

I am using Intel C++ Composer XE 2013 SP1 Update 3, but I believe the relevant library (uSCIF.dll) comes from MPSS which is version 3.3. It also happened with 3.2.1. You can reproduce it with any of the programs included with scif_tutorials, but you must run it on a windows machine without a MIC present.

[Loc_N_Intel]

Thank you. I investigate it and will get back to you. 

[Loc_N_Intel]

Hi,

I did test the SDK scif sample code in one system with coprocessor installed and in one system without coprocessor.

In the system with coprocessor installed, I transferred all the binaries to the coprocessor (these coprocessor binaries are built in a separate Linux system) and test the SDK scif sample code, it worked fine.

In the system without coprocessor, I get the same error that you saw. However, I would not call it is a defect, because
the SCIF sample programs are intended for testing SCIF communication between CPU and coprocessor. Without a coprocessor, if you launch the SCIF application it is normal to return an error. Perhaps the error message is not clear enough to indicate the cause (absence of coprocessor in the system).

[John_F_1]

While I understand that SCIF was created to support communication with the coprocessor, the sample programs do not require a coprocessor to work correctly. You can use them successfully with only host processes. In fact, the documentation of SCIF makes it clear that you can use SCIF to communicate not only with coprocessors, but also with other CPU's:

A SCIF node is a physical endpoint in the SCIF network. The host and MIC Architecture devices are SCIF nodes. From the SCIF point of view, all host processors (CPUs) under a single OS are considered a single SCIF (host) node.

...

Normally the endpoints of a connection are on different nodes in the SCIF network. We
therefore often refer to these endpoints as local and remote with respect to one end of the
connection. In fact, SCIF fully supports connections in which both endpoints are on the same
node, and we refer to this as a loopback connection.

It is unfortunate that uSCIF requires the presence of a coprocessor to initialize, because this means I cannot debug SCIF communication on a machine without a coprocessor installed.

[Loc_N_Intel]

Hello,

I contacted SCIF experts and learned that loop back support is not availble for the current architecture. However, the future stack and hardware may support this feature if desired. I will submit a ticket for this feature.

Thank you.