[pypy-dev] PyPy translation on Xeon Phi (pka MIC)

[Ajit Dingankar]

Hi Wim! I tried your suggestions (CC=icc and including -mmic in CFLAGS) and copied the executable to the Phi co-processor card, but it fails due to a library dependency. ---- $ ./example2-c bottles.b  /lib64/ld-linux-x86-64.so.2: No such file or directory
$ ls -l /lib64/ld-linux*
lrwxrwxrwx    1 root     root            13 Jan  1  1970 /lib64/ld-linux-k1om.so.2 -> ld-2.14.90.so---- 
When I tried to run it from the Xeon host with micnativeloadex I also get an error:---- $ export SINK_LD_LIBRARY_PATH=/opt/intel/composer_xe_2015.1.133/lib/mic
$ micnativeloadex ./example2-c
Supplied binary does not match the Intel(R) Xeon Phi(TM)
coprocessor that is installed.---- 

I couldn't find any unresolved library dependencies: ---- $ micnativeloadex ./example2-c -lDependency information for ./example2-c Full path was resolved as 
 /tmp/usession-release-2.5.1-6/testing_1/./example2-c Binary was built for X86_64 architecture SINK_LD_LIBRARY_PATH = /opt/intel/composer_xe_2015.1.133/lib/mic Dependencies Found:
  (none found) Dependencies Not Found Locally (but may exist already on the coprocessor):
  librt.so.1
  libm.so.6
  libgcc_s.so.1
  libpthread.so.0
  libc.so.6
  libdl.so.2---- 

I noticed in the output above that the "Binary was built for X86_64 architecture" but couldn't find any info re it. 
Plain ldd does show the dependency on ld-linux-x86-64.so.2 (here shown with extra libraries libm, libgcc and libdl included with the "-mmic" flag):---- $ ldd example2-c
 linux-vdso.so.1 =>  (0x00007fffcabc1000)
 librt.so.1 => /lib64/librt.so.1 (0x00000037d8c00000)
 libm.so.6 => /lib64/libm.so.6 (0x00000037d9400000)
 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000037de800000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037d8400000)
 libc.so.6 => /lib64/libc.so.6 (0x00000037d8000000)
 libdl.so.2 => /lib64/libdl.so.2 (0x00000037d8800000)
 /lib64/ld-linux-x86-64.so.2 (0x00000037d7c00000)
---- 
I'd appreciate any help/pointers to the library dependency! 
Thanks, Ajit==== 
 


     On Sunday, April 12, 2015 9:46 PM, Ajit Dingankar <ajit.dingankar at ieee.org> wrote:
   
 

 @Wim: 
Yes, I am trying to translate on the card since I couldn't find much info 
re cross-compiling and someone had suggested direct translation on the 
target platform (though not specifically for Xeon Phi). Anyway, thanks 
a lot for the tips! I'll try them at work tomorrow. BTW, I'm more interested 
in providing new functionality, not targeting high performance initially, so 
multi-threading is not important for me now; I just need to get it working... 

@Armin: 
Sorry I didn't have access to the actual error message when I posted the 
question as a general query. Will do so if I can't make progress trying 
Wim's suggestions from work. 
@Yury: Thanks for the clarification re Xeon Phi generations and usage models. 

Thanks, 
Ajit==== 



 


     On Sunday, April 12, 2015 2:46 AM, Yury V. Zaytsev <yury at shurup.com> wrote:
   
 

 On Sun, 2015-04-12 at 09:32 +0200, Armin Rigo wrote:
> Wim's reply is not helpful at all for me, as it is mostly given as a
> series of three-letter acronyms I've never heard about :-)

He's simply referring to the different generations of MICs (MIC = Many
Integrated Core architecture, KNC = Knights Corner [older models], KNL =
Knights Landing [newer models]).

> I don't know where Xeon Phi fits there. It seems to be an x86-64 from
> Wikipedia, but I'm not sure about what is special about it.

I've shortly played with KNC, and put very simply in its current shape
it's basically a plug-in computer extension card, which can function in
several modes, e.g. as an accelerator which receives tasks from the host
system and executes them, or even as a more or less stand-alone box
inside the box running (for instance) a stripped down Linux system.

In the latter mode, software just requires cross-compilation and then
can run on the board as if it was a stand-alone computer, in the former
you have to make use of special APIs to run your tasks on the MICs. It
looks like Wim has taken the first approach, which makes total sense to
get it working with minimal effort :-)

So yes, in this approximation, assume it's x86-64 which requires a
special cross-compiler and has a bit different subset of supported
insns.

-- 
Sincerely yours,
Yury V. Zaytsev




 
   

 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20150413/44dce71e/attachment-0001.html>