Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Things do speed up, but that has nothing to do with parallel versus sequential, you are not comparing apples to apples. The JVM has a JIT (just in time) compiler that will compile some byte code only after the code is used a certain number of times. So what you see in the first iterations is slower execution for code that is not yet JIT-ed as well as time for ongoing JIT compilation itself. Removing the <code>.par</code> so that it's all <strong>sequential</strong> here is what I see on my machine (10x less iteration cause I'm using an older machine):</p> <pre><code>Sequential (ms): 312 Iteration[1] Executed in 117 ms Iteration[2] Executed in 112 ms Iteration[3] Executed in 112 ms Iteration[4] Executed in 112 ms Iteration[5] Executed in 114 ms Iteration[6] Executed in 113 ms Iteration[7] Executed in 113 ms Iteration[8] Executed in 117 ms Iteration[9] Executed in 113 ms Iteration[10] Executed in 111 ms </code></pre> <p>But it's all sequential! You can see what the JVM does in terms of JIT by using the JVM <code>-XX:+PrintCompilation</code> (set in <code>JAVA_OPTS</code> or use <code>-J-XX:+PrintCompilation</code> scala option. In the first iterations you will see a large numbers of JVM print statements showing what's being JIT-ed, then it stabilizes later on.</p> <p>So to compare apples to apples, you first run without the par, then add the par and run the same program. On my dual core, when using <code>.par</code> I get:</p> <pre><code>Sequential (ms): 329 Iteration[1] Executed in 197 ms Iteration[2] Executed in 60 ms Iteration[3] Executed in 57 ms Iteration[4] Executed in 58 ms Iteration[5] Executed in 59 ms Iteration[6] Executed in 73 ms Iteration[7] Executed in 56 ms Iteration[8] Executed in 60 ms Iteration[9] Executed in 58 ms Iteration[10] Executed in 57 ms </code></pre> <p>So more or less a 2x speedup once it's stable.</p> <p>On related note, the other thing you want to be careful with is boxing and un-boxing, especially if you are comparing to just Java. The scala library high order functions like filter are doing boxing and un-boxing of primitive types and this is typically source of initial disappointment for those that convert code from Java to Scala. </p> <p>Though it does not apply in this case as the <code>for</code> is outside the timing, there is also some cost for using <code>for</code> instead of <code>while</code>, but the 2.9.1 compiler should be doing a decent job when using the <code>-optimize</code> scalac flag.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload