<?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 Benchmarking code in Intel® oneAPI Math Kernel Library</title>
    <link>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/Benchmarking-code/m-p/787884#M1974</link>
    <description>I'm trying to benchmark LAPACK operations on Linux and I'm getting a funny result. A simple program that performs a small dsyev() times at 0.205s real (I'm using real time on an unloaded system since user time becomes difficult to work with on a multi-core CPU). User time is 0.000 and sys is 0.004. If I perform the same operation a number of times the real time is constant up to about 610 iterations; though it's not consistant, sometimes 610 iterations produces real time of 0.205. At this point the user time is bout 0.800 seconds (4 cores). &lt;BR /&gt;&lt;BR /&gt;As I continue to increase the count the real time is constant for about another 610 iterations where it suddenly jumps to 0.605 seconds. &lt;BR /&gt;&lt;BR /&gt;Is there any reason particular to using MKL that this would be the case. I don't get the same type of result when linking against CLAPACK/ATLAS. &lt;BR /&gt;&lt;BR /&gt;For reference&lt;BR /&gt;&lt;BR /&gt;Linux beast 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux&lt;BR /&gt;&lt;BR /&gt;and I'm building with &lt;BR /&gt;&lt;BR /&gt;$ gcc -O2 -L/opt/intel/composer_xe_2011_sp1.11.339/mkl/lib/intel64/ -L/opt/intel/composer_xe_2011_sp1.11.339/compiler/lib/intel64/ -I/opt/intel/mkl/include -c -o mklev.o mklev.c&lt;BR /&gt;$ gcc -O2 -L/opt/intel/composer_xe_2011_sp1.11.339/mkl/lib/intel64/ -L/opt/intel/composer_xe_2011_sp1.11.339/compiler/lib/intel64/ -o mklev mklev.o -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lm&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;The code is a slightly modified version of the example&lt;BR /&gt;&lt;BR /&gt; lwork = -1;&lt;BR /&gt; dsyev("V", "U", &amp;amp;n, a, &amp;amp;lda, w, &amp;amp;wkopt, &amp;amp;lwork, &amp;amp;info);&lt;BR /&gt; lwork = (int)wkopt;&lt;BR /&gt; if((work = (double *)malloc(lwork*sizeof(double))) == NULL) { perror("malloc()"); goto error2; }&lt;BR /&gt; for(i=0; i&lt;COUNT&gt;&lt;/COUNT&gt; dsyev("V", "U", &amp;amp;n, a, &amp;amp;lda, w, work, &amp;amp;lwork, &amp;amp;info);&lt;BR /&gt; if(info &amp;gt; 0) { printf("The algorithm failed to compute eigenvalues\\n"); goto error3; }&lt;BR /&gt; }&lt;BR /&gt;&lt;BR /&gt;</description>
    <pubDate>Fri, 06 Jul 2012 17:59:04 GMT</pubDate>
    <dc:creator>Michael_Conlen</dc:creator>
    <dc:date>2012-07-06T17:59:04Z</dc:date>
    <item>
      <title>Benchmarking code</title>
      <link>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/Benchmarking-code/m-p/787884#M1974</link>
      <description>I'm trying to benchmark LAPACK operations on Linux and I'm getting a funny result. A simple program that performs a small dsyev() times at 0.205s real (I'm using real time on an unloaded system since user time becomes difficult to work with on a multi-core CPU). User time is 0.000 and sys is 0.004. If I perform the same operation a number of times the real time is constant up to about 610 iterations; though it's not consistant, sometimes 610 iterations produces real time of 0.205. At this point the user time is bout 0.800 seconds (4 cores). &lt;BR /&gt;&lt;BR /&gt;As I continue to increase the count the real time is constant for about another 610 iterations where it suddenly jumps to 0.605 seconds. &lt;BR /&gt;&lt;BR /&gt;Is there any reason particular to using MKL that this would be the case. I don't get the same type of result when linking against CLAPACK/ATLAS. &lt;BR /&gt;&lt;BR /&gt;For reference&lt;BR /&gt;&lt;BR /&gt;Linux beast 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux&lt;BR /&gt;&lt;BR /&gt;and I'm building with &lt;BR /&gt;&lt;BR /&gt;$ gcc -O2 -L/opt/intel/composer_xe_2011_sp1.11.339/mkl/lib/intel64/ -L/opt/intel/composer_xe_2011_sp1.11.339/compiler/lib/intel64/ -I/opt/intel/mkl/include -c -o mklev.o mklev.c&lt;BR /&gt;$ gcc -O2 -L/opt/intel/composer_xe_2011_sp1.11.339/mkl/lib/intel64/ -L/opt/intel/composer_xe_2011_sp1.11.339/compiler/lib/intel64/ -o mklev mklev.o -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lm&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;The code is a slightly modified version of the example&lt;BR /&gt;&lt;BR /&gt; lwork = -1;&lt;BR /&gt; dsyev("V", "U", &amp;amp;n, a, &amp;amp;lda, w, &amp;amp;wkopt, &amp;amp;lwork, &amp;amp;info);&lt;BR /&gt; lwork = (int)wkopt;&lt;BR /&gt; if((work = (double *)malloc(lwork*sizeof(double))) == NULL) { perror("malloc()"); goto error2; }&lt;BR /&gt; for(i=0; i&lt;COUNT&gt;&lt;/COUNT&gt; dsyev("V", "U", &amp;amp;n, a, &amp;amp;lda, w, work, &amp;amp;lwork, &amp;amp;info);&lt;BR /&gt; if(info &amp;gt; 0) { printf("The algorithm failed to compute eigenvalues\\n"); goto error3; }&lt;BR /&gt; }&lt;BR /&gt;&lt;BR /&gt;</description>
      <pubDate>Fri, 06 Jul 2012 17:59:04 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-oneAPI-Math-Kernel-Library/Benchmarking-code/m-p/787884#M1974</guid>
      <dc:creator>Michael_Conlen</dc:creator>
      <dc:date>2012-07-06T17:59:04Z</dc:date>
    </item>
  </channel>
</rss>

