<?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 Well, it depends. in Software Archive</title>
    <link>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925486#M13763</link>
    <description>&lt;P&gt;We support Cilk Plus on Windows, Linux and Mac OS for the x86 architecture (both 32-bit and 64-bit).&lt;/P&gt;

&lt;P&gt;How hard it is to port Cilk Plus&amp;nbsp;depends on how close you are to the existing implemenations.&lt;/P&gt;

&lt;P&gt;If you're going to a Unix variant, the runtime should port without much problem.&amp;nbsp; If you're going to a completely different environment (comparable to Windows, say) then there's a lot of work you'll need to do there.&lt;/P&gt;

&lt;P&gt;If you're going to use GCC or LLVM, you can leverage off of the work that we've already done.&amp;nbsp; We did a trial with the ARM version of GCC for Linux and managed to run fib correctly.&amp;nbsp; But we only proved that it was possible.&amp;nbsp; Once we got that one test working, we moved onto other tasks.&amp;nbsp; We made no attempt to do a full port.&lt;/P&gt;

&lt;P&gt;On&amp;nbsp;non-x86 architectures you'll need to consider whether the memory model assumptions in the handling of the deque (spawning, stealing and returning from a spawned function) are correct.&amp;nbsp; The x86 architecture makes guarantees about the consistency of memory between processors that may not hold true on other architectures.&amp;nbsp; The THE protocol (which is depending on the memory model) is discussed in scheduler.c.&amp;nbsp; Details of the THE protocol &amp;nbsp;are available in&amp;nbsp;&lt;A href="http://supertech.csail.mit.edu/papers/cilk5.pdf" target="_blank"&gt;The Implementation of the Cilk-5 Multithreaded Language&lt;/A&gt; by Frigo, Leiserson and Randall.&lt;/P&gt;

&lt;P&gt;If you're interested in working on this, we'd be happy to consult with you and merge the changes into the source pool.&amp;nbsp; The &lt;A href="https://www.cilkplus.org/download#runtime-sources" target="_blank"&gt;sources&lt;/A&gt; and &lt;A href="https://www.cilkplus.org/download#open-specification" target="_blank"&gt;specifications&lt;/A&gt; for Cilk Plus are available from the Cilk Plus &lt;A href="https://www.cilkplus.org/download" target="_blank"&gt;Downloads&lt;/A&gt; page.&amp;nbsp; See the &lt;U&gt;&lt;FONT color="#0066cc"&gt;Cilk&lt;/FONT&gt;&lt;/U&gt;&lt;U&gt;&lt;FONT color="#0066cc"&gt; Plus &lt;A href="http://www.cilkplus.org/submit-cilk-contribution" target="_blank"&gt;Contribution &lt;/A&gt;page&lt;/FONT&gt;&lt;/U&gt;&amp;nbsp;for the details on how to contribute sources.&lt;/P&gt;</description>
    <pubDate>Mon, 02 Dec 2013 22:15:00 GMT</pubDate>
    <dc:creator>Barry_T_Intel</dc:creator>
    <dc:date>2013-12-02T22:15:00Z</dc:date>
    <item>
      <title>Cilk portability to non Intel processors</title>
      <link>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925485#M13762</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;

&lt;P&gt;I'm investigating the use of Cilk in embedded computer environment.&lt;/P&gt;

&lt;P&gt;I've understood that Cilk is only supported on Intel processors for Linux and MacOS X. Is it right?&lt;/P&gt;

&lt;P&gt;Cilk also requires some specific compilers. Such compilers are available from Intel, GCC and LLVM.&lt;/P&gt;

&lt;P&gt;What should be the effort to port Cilk to a different processor (i.e. ARM or Sparc)?&lt;/P&gt;

&lt;P&gt;I assume that it involves some non trivial adaptation of the compiler backend?&lt;/P&gt;

&lt;P&gt;Regards, Dominique T&lt;/P&gt;</description>
      <pubDate>Mon, 02 Dec 2013 17:02:33 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925485#M13762</guid>
      <dc:creator>Dominique_T_</dc:creator>
      <dc:date>2013-12-02T17:02:33Z</dc:date>
    </item>
    <item>
      <title>Well, it depends.</title>
      <link>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925486#M13763</link>
      <description>&lt;P&gt;We support Cilk Plus on Windows, Linux and Mac OS for the x86 architecture (both 32-bit and 64-bit).&lt;/P&gt;

&lt;P&gt;How hard it is to port Cilk Plus&amp;nbsp;depends on how close you are to the existing implemenations.&lt;/P&gt;

&lt;P&gt;If you're going to a Unix variant, the runtime should port without much problem.&amp;nbsp; If you're going to a completely different environment (comparable to Windows, say) then there's a lot of work you'll need to do there.&lt;/P&gt;

&lt;P&gt;If you're going to use GCC or LLVM, you can leverage off of the work that we've already done.&amp;nbsp; We did a trial with the ARM version of GCC for Linux and managed to run fib correctly.&amp;nbsp; But we only proved that it was possible.&amp;nbsp; Once we got that one test working, we moved onto other tasks.&amp;nbsp; We made no attempt to do a full port.&lt;/P&gt;

&lt;P&gt;On&amp;nbsp;non-x86 architectures you'll need to consider whether the memory model assumptions in the handling of the deque (spawning, stealing and returning from a spawned function) are correct.&amp;nbsp; The x86 architecture makes guarantees about the consistency of memory between processors that may not hold true on other architectures.&amp;nbsp; The THE protocol (which is depending on the memory model) is discussed in scheduler.c.&amp;nbsp; Details of the THE protocol &amp;nbsp;are available in&amp;nbsp;&lt;A href="http://supertech.csail.mit.edu/papers/cilk5.pdf" target="_blank"&gt;The Implementation of the Cilk-5 Multithreaded Language&lt;/A&gt; by Frigo, Leiserson and Randall.&lt;/P&gt;

&lt;P&gt;If you're interested in working on this, we'd be happy to consult with you and merge the changes into the source pool.&amp;nbsp; The &lt;A href="https://www.cilkplus.org/download#runtime-sources" target="_blank"&gt;sources&lt;/A&gt; and &lt;A href="https://www.cilkplus.org/download#open-specification" target="_blank"&gt;specifications&lt;/A&gt; for Cilk Plus are available from the Cilk Plus &lt;A href="https://www.cilkplus.org/download" target="_blank"&gt;Downloads&lt;/A&gt; page.&amp;nbsp; See the &lt;U&gt;&lt;FONT color="#0066cc"&gt;Cilk&lt;/FONT&gt;&lt;/U&gt;&lt;U&gt;&lt;FONT color="#0066cc"&gt; Plus &lt;A href="http://www.cilkplus.org/submit-cilk-contribution" target="_blank"&gt;Contribution &lt;/A&gt;page&lt;/FONT&gt;&lt;/U&gt;&amp;nbsp;for the details on how to contribute sources.&lt;/P&gt;</description>
      <pubDate>Mon, 02 Dec 2013 22:15:00 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925486#M13763</guid>
      <dc:creator>Barry_T_Intel</dc:creator>
      <dc:date>2013-12-02T22:15:00Z</dc:date>
    </item>
    <item>
      <title>A further comment is that the</title>
      <link>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925487#M13764</link>
      <description>&lt;P&gt;A further comment is that the usability of the array notation depends on compiler extensions that are available in Intel C++ but not GNU C++; specifically, variably modified arrays.&amp;nbsp; If you need to write generic n-D array functions (e.g. LU decomposition),&amp;nbsp; you should check that out; it may or may not be relevant to you.&amp;nbsp; Exactly how C++ (i.e. WG21) is going to proceed with that requirement is a matter of debate ....&lt;/P&gt;</description>
      <pubDate>Tue, 03 Dec 2013 10:42:30 GMT</pubDate>
      <guid>https://community.intel.com/t5/Software-Archive/Cilk-portability-to-non-Intel-processors/m-p/925487#M13764</guid>
      <dc:creator>Nick_M_3</dc:creator>
      <dc:date>2013-12-03T10:42:30Z</dc:date>
    </item>
  </channel>
</rss>

