<?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 Thanks for the useful hint.  in Software Archive</title>
    <link>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047314#M48516</link>
    <description>&lt;P&gt;Thanks for the useful hint.&amp;nbsp; I updated the benchmarks (Fortran, C, C++, Cilk(tm) Plus) at &lt;A href="https://github.com/tprince/lcd" target="_blank"&gt;https://github.com/tprince/lcd&lt;/A&gt; after finding that all my use of (int)__sec_implicit_index work well on all targets without target-dependent variations.&amp;nbsp; It's fairly well known that MIC (like ia32 mode) doesn't have full native int64_t instruction level support, but I hadn't guessed this would be an issue for implicit_index.&amp;nbsp; Even on host, implicit cast from unsigned long long to float is ridiculously slow.&lt;/P&gt;</description>
    <pubDate>Tue, 24 Jun 2014 16:30:00 GMT</pubDate>
    <dc:creator>TimP</dc:creator>
    <dc:date>2014-06-24T16:30:00Z</dc:date>
    <item>
      <title>sec_implicit_index</title>
      <link>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047312#M48514</link>
      <description>&lt;P&gt;I've been trying to understand what the implicit_index intrinsic may be intended for.&amp;nbsp; It's tricky to get adequate performance from it, and apparently not possible in some of the more obvious contexts (unless the goal is only to get a positive vectorization report).&lt;/P&gt;

&lt;P&gt;It seems to be competitive for the usage of setting up an identity matrix.&lt;/P&gt;

&lt;P&gt;In the context of dividing its result by 2, different treatments are required on MIC and host:&lt;/P&gt;

&lt;P&gt;#ifdef __MIC__&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; a[2:i__2-1] = b[2:i__2-1] + c[((unsigned)__sec_implicit_index(0)&amp;gt;&amp;gt;1)+1] * d__[2:i__2-1];&lt;BR /&gt;
	#else&lt;BR /&gt;
	&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp;&amp;nbsp; a[2:i__2-1] = b[2:i__2-1] + c[__sec_implicit_index(0)/2+1] * d__[2:i__2-1];&lt;BR /&gt;
	#endif&lt;/P&gt;

&lt;P&gt;That is, the unsigned right shift is several times as fast as the divide on MIC (and not much slower than plain C code), while the signed divide by 2 is up to 60% faster on host (but not as fast as C code).&lt;/P&gt;

&lt;P&gt;The only advantage in it seems to be the elimination of a for(), if in fact that is considered to be an advantage.&lt;/P&gt;

&lt;P&gt;I didn't see documented anywhere that it is int data type, although the opt-report shows it.&amp;nbsp; I can't see how it could be anything other than positive integers, so the (unsigned) cast seems valid.&amp;nbsp; I guess &amp;gt;&amp;gt;1U would have the same effect with less space taken up compared with (unsigned).&amp;nbsp; The notation is already cryptic from my point of view.&lt;/P&gt;</description>
      <pubDate>Tue, 24 Jun 2014 01:01:58 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047312#M48514</guid>
      <dc:creator>TimP</dc:creator>
      <dc:date>2014-06-24T01:01:58Z</dc:date>
    </item>
    <item>
      <title>Section 5.15.12 of the</title>
      <link>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047313#M48515</link>
      <description>&lt;P&gt;Section 5.15.12 of the c&lt;A href="http://www.cilkplus.org/sites/default/files/open_specifications/Intel_Cilk_plus_lang_spec_1.2.htm"&gt;urrent Cilk Plus specification&lt;/A&gt;&amp;nbsp;documents __sec_implicit_index as returning an intptr_t. &amp;nbsp;That's a 64-bit integer type on MIC, which lacks support for vectorizing 64-bit integer arithmetic. &amp;nbsp;(Well, the compiler "vectorizes" it, but through a remarkably circuitous sequence of instructions.) &amp;nbsp;The cast to unsigned gets it down to 32 bits, for which there is more direct vectorization support.&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 24 Jun 2014 14:23:13 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047313#M48515</guid>
      <dc:creator>ARCH_R_Intel</dc:creator>
      <dc:date>2014-06-24T14:23:13Z</dc:date>
    </item>
    <item>
      <title>Thanks for the useful hint. </title>
      <link>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047314#M48516</link>
      <description>&lt;P&gt;Thanks for the useful hint.&amp;nbsp; I updated the benchmarks (Fortran, C, C++, Cilk(tm) Plus) at &lt;A href="https://github.com/tprince/lcd" target="_blank"&gt;https://github.com/tprince/lcd&lt;/A&gt; after finding that all my use of (int)__sec_implicit_index work well on all targets without target-dependent variations.&amp;nbsp; It's fairly well known that MIC (like ia32 mode) doesn't have full native int64_t instruction level support, but I hadn't guessed this would be an issue for implicit_index.&amp;nbsp; Even on host, implicit cast from unsigned long long to float is ridiculously slow.&lt;/P&gt;</description>
      <pubDate>Tue, 24 Jun 2014 16:30:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/sec-implicit-index/m-p/1047314#M48516</guid>
      <dc:creator>TimP</dc:creator>
      <dc:date>2014-06-24T16:30:00Z</dc:date>
    </item>
  </channel>
</rss>

