
Announcement: pyMIC v0.5 ========================= I'm happy to announce the release of pyMIC v0.5. pyMIC is a Python module to offload computation in a Python program to the Intel Xeon Phi coprocessor. It contains offloadable arrays and device management functions. It supports invocation of native kernels (C/C++, Fortran) and blends in with Numpy's array types for float, complex, and int data types. For more information and downloads please visit pyMIC's Github page: https://github.com/01org/pyMIC. You can find pyMIC's mailinglist at https://lists.01.org/mailman/listinfo/pymic. Full change log: ================= Version 0.5 ---------------------------- - Introduced new kernel API that avoids insane pointer unpacking. - pyMIC now uses libxstreams as the offload back-end (https://github.com/hfp/libxstream). - Added smart pointers to make handling of fake pointers easier. Version 0.4 ---------------------------- - New low-level API to allocate, deallocate, and transfer data (see OffloadStream). - Support for in-place binary operators. - New internal design to handle offloads. Version 0.3 ---------------------------- - Improved handling of libraries and kernel invocation. - Trace collection (PYMIC_TRACE=1, PYMIC_TRACE_STACKS={none,compact,full}). - Replaced the device-centric API with a stream API. - Refactoring to better match PEP8 recommendations. - Added support for int(int64) and complex(complex128) data types. - Reworked the benchmarks and examples to fit the new API. - Bugfix: fixed syntax errors in OffloadArray. Version 0.2 ---------------------------- - Small improvements to the README files. - New example: Singular Value Decomposition. - Some documentation for the API functions. - Added a basic testsuite for unit testing (WIP). - Bugfix: benchmarks now use the latest interface. - Bugfix: numpy.ndarray does not offer an attribute 'order'. - Bugfix: number_of_devices was not visible after import. - Bugfix: member offload_array.device is now initialized. - Bugfix: use exception for errors w/ invoke_kernel & load_library. Version 0.1 ---------------------------- Initial release. Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052

Hi, Interesting project. How close is the C++ kernel needed from OpenCL kernels ? Is it directly portable ? I have tested my OpenCL code (via pyopencl) on the Phi and I did not get better performances than the dual-hexacore Xeon (i.e. ~2x slower than a GPU). Cheers -- Jérôme Kieffer Data analysis unit - ESRF

Hi Jerome,
That depends a bit on what the kernel does. If the kernel implements something really like a dgemm, it is just calling MKL's dgemm routine and passing the parameters into the routine. If the kernel does more, you would need regular C/C++ coding (with whatever is needed) plus a threading model such as OpenMP and TBB.
Is it directly portable ?
I would say no, just because OpenCL does a lot in terms of parallelization of the kernel whereas pyMIC only gives you control over data transfer and passing control over to the coprocessor. Threading and SIMD vectorization then is done by the compiler and/or the programmers.
What type of code are you offloading? Cheers, -michael Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
participants (2)
-
Jerome Kieffer
-
Klemm, Michael