<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic The strength of the Xeon Phi in Software Archive</title>
    <link>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036331#M44105</link>
    <description>&lt;P&gt;The strength of the Xeon Phi is with its 512-bit wide vector unit. I suspect that your encoding routine is not fully utilizing the wide vector capability. Also, Xeon Phi programs should be multi-threaded, at least 2 threads per core.&lt;/P&gt;

&lt;P&gt;Happy New Year&lt;/P&gt;

&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
    <pubDate>Wed, 31 Dec 2014 13:30:51 GMT</pubDate>
    <dc:creator>jimdempseyatthecove</dc:creator>
    <dc:date>2014-12-31T13:30:51Z</dc:date>
    <item>
      <title>performance jpeg on phi</title>
      <link>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036330#M44104</link>
      <description>Hello.

I am new in Phi world. I tested jpeg encoding performance (tested on image 1680x1050, single thread):

14 ms - xeon E5-2620 - libjpeg-turbo with SIMD
39 ms - xeon E5-2620 - libjpeg-turbo without SIMD
24 ms - xeon E5-2620 - intel ijg80b with IPP
42 ms - xeon E5-2620 - intel ijg80b without IPP (#undef USE_IPP)
386 ms - xeon Phi 31S1P - native intel ijg80b with IPP
557 ms - xeon Phi 31S1P - native intel ijg80b without IPP (#undef USE_IPP)
435 ms - xeon Phi 31S1P - native libjpeg-turbo without SIMD

Is the performance on Phi so bad even with IPP "acceleration" (nearly 28x) ?
Is there any better Phi implementation of jpeg encoding ?

Thanks for answers and happy new year, Martin</description>
      <pubDate>Wed, 31 Dec 2014 00:45:34 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036330#M44104</guid>
      <dc:creator>Martin_C_1</dc:creator>
      <dc:date>2014-12-31T00:45:34Z</dc:date>
    </item>
    <item>
      <title>The strength of the Xeon Phi</title>
      <link>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036331#M44105</link>
      <description>&lt;P&gt;The strength of the Xeon Phi is with its 512-bit wide vector unit. I suspect that your encoding routine is not fully utilizing the wide vector capability. Also, Xeon Phi programs should be multi-threaded, at least 2 threads per core.&lt;/P&gt;

&lt;P&gt;Happy New Year&lt;/P&gt;

&lt;P&gt;Jim Dempsey&lt;/P&gt;</description>
      <pubDate>Wed, 31 Dec 2014 13:30:51 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036331#M44105</guid>
      <dc:creator>jimdempseyatthecove</dc:creator>
      <dc:date>2014-12-31T13:30:51Z</dc:date>
    </item>
    <item>
      <title>Martin,</title>
      <link>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036332#M44106</link>
      <description>&lt;P&gt;Martin,&lt;/P&gt;

&lt;P&gt;Another factor to consider is the # of data sets you are transferring, their size, and the duration of the encoding you are trying to perform. If you are moving and processing small data sets frequently, the communication costs will be large (you're moving data over a PCIe bus). Even with an effective use of the 512-bit SIMD vector engine and the large amount of parallelism, the computation has to be significantly larger than the communication costs to use the coprocessor to advantage. Though I haven't done tests for extremely large images (or small ones), jpeg encoding may not be appropriate for the coprocessor.&lt;/P&gt;

&lt;P&gt;Regards&lt;BR /&gt;
	--&lt;BR /&gt;
	Taylor&lt;BR /&gt;
	&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 31 Dec 2014 16:58:24 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/performance-jpeg-on-phi/m-p/1036332#M44106</guid>
      <dc:creator>TaylorIoTKidd</dc:creator>
      <dc:date>2014-12-31T16:58:24Z</dc:date>
    </item>
  </channel>
</rss>

