<?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 Hi Kyle, in Intel® Integrated Performance Primitives</title>
    <link>https://community.intel.com/t5/Intel-Integrated-Performance/ipprFilter-for-32f-volume-data/m-p/1092451#M24977</link>
    <description>&lt;P&gt;Hi Kyle,&lt;/P&gt;

&lt;P&gt;IPP filter functions are one and two dimensional only.&lt;/P&gt;

&lt;P&gt;The two-step approach as mentioned is working and is efficient on small data volumes. When your volume is large, you might run into memory bandwidth issues. You can quickly check this with tools like Intel VTune™ here. If you find out that your algorithm is memory bandwidth limited, consider changing the algorithm.&lt;/P&gt;

&lt;P&gt;Small volume data means data size up to the size of the processors cache size. So for best performance you need to make sure that your data fits into the cache. To do so you need to split your volume space into multiple smaller data cubes where the data of each of those cubes fit into the processors cache. You then apply your two-step filter to the first cube before moving to the next cube. This way you significantly reduce memory traffic on the bus as you load data only once from memory. Algorithms taking into account the physical limitation of the processor cache are often called cache-blocking-algorithms. You will find more on this when doing some research.&lt;/P&gt;

&lt;P&gt;From personal experience you might easily get a performance boost of 30% or more (depending on data, algorithm, and compute complexity). When doing so, pay special attention to the cube boarders during calculation. And check the processors cache size of the target system at &lt;A href="http://ark.intel.com"&gt;ark.intel.com&lt;/A&gt; as they are significantly different across the processor segments and SKUs (IPP functions are helping you here also by&amp;nbsp;returning the cache size of the processor).&lt;/P&gt;

&lt;P&gt;Thanks &amp;amp; Best,&lt;/P&gt;

&lt;P&gt;Bjoern&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Tue, 23 Aug 2016 14:46:24 GMT</pubDate>
    <dc:creator>Bjoern_B_Intel</dc:creator>
    <dc:date>2016-08-23T14:46:24Z</dc:date>
    <item>
      <title>ipprFilter for 32f volume data?</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/ipprFilter-for-32f-volume-data/m-p/1092450#M24976</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;

&lt;P&gt;Is there any plan to add the 32f_&lt;SPAN class="kwd"&gt;C1PV&lt;/SPAN&gt; datatype for the ipprFilter function? In particular, I apply large (9x9x9) Gaussian filters to volume data extensively, and currently do it by a two-step call to ippiFilterGaussianBorder_32f_C1R, once for XY-planes, and once for Z-planes. This incurs a lot of data transfer overhead, especially for filtering in Z. A single call to a &lt;SPAN class="kwd"&gt;ipprFilter_32f_C1PV, or a&amp;nbsp;&lt;/SPAN&gt; ipprFilterGaussianBorder_32f_&lt;SPAN class="kwd"&gt;C1PV would be a huge help.&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;Thanks!&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 10 Aug 2016 22:30:26 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/ipprFilter-for-32f-volume-data/m-p/1092450#M24976</guid>
      <dc:creator>kyle_l_1</dc:creator>
      <dc:date>2016-08-10T22:30:26Z</dc:date>
    </item>
    <item>
      <title>Hi Kyle,</title>
      <link>https://community.intel.com/t5/Intel-Integrated-Performance/ipprFilter-for-32f-volume-data/m-p/1092451#M24977</link>
      <description>&lt;P&gt;Hi Kyle,&lt;/P&gt;

&lt;P&gt;IPP filter functions are one and two dimensional only.&lt;/P&gt;

&lt;P&gt;The two-step approach as mentioned is working and is efficient on small data volumes. When your volume is large, you might run into memory bandwidth issues. You can quickly check this with tools like Intel VTune™ here. If you find out that your algorithm is memory bandwidth limited, consider changing the algorithm.&lt;/P&gt;

&lt;P&gt;Small volume data means data size up to the size of the processors cache size. So for best performance you need to make sure that your data fits into the cache. To do so you need to split your volume space into multiple smaller data cubes where the data of each of those cubes fit into the processors cache. You then apply your two-step filter to the first cube before moving to the next cube. This way you significantly reduce memory traffic on the bus as you load data only once from memory. Algorithms taking into account the physical limitation of the processor cache are often called cache-blocking-algorithms. You will find more on this when doing some research.&lt;/P&gt;

&lt;P&gt;From personal experience you might easily get a performance boost of 30% or more (depending on data, algorithm, and compute complexity). When doing so, pay special attention to the cube boarders during calculation. And check the processors cache size of the target system at &lt;A href="http://ark.intel.com"&gt;ark.intel.com&lt;/A&gt; as they are significantly different across the processor segments and SKUs (IPP functions are helping you here also by&amp;nbsp;returning the cache size of the processor).&lt;/P&gt;

&lt;P&gt;Thanks &amp;amp; Best,&lt;/P&gt;

&lt;P&gt;Bjoern&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 23 Aug 2016 14:46:24 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-Integrated-Performance/ipprFilter-for-32f-volume-data/m-p/1092451#M24977</guid>
      <dc:creator>Bjoern_B_Intel</dc:creator>
      <dc:date>2016-08-23T14:46:24Z</dc:date>
    </item>
  </channel>
</rss>

