For loop slower than reduce?

Question

I'm getting very strange timings from this code. At times the for loop runs much more slowly.

var len = 8e6

function *rands(){
  for(let i =0; i < len; i++)
    yield Math.random()
}

var add = (a,b) => a + b
var arr = new Float64Array([...rands()])


console.time('reduce')
var sum = arr.reduce(add)
console.log(sum)
console.timeEnd('reduce')

console.time('loop')
var sum = 0
for(let i = 0; i < len; i++)
  sum += arr[i]
console.log(sum)
console.timeEnd('loop')

I consistently get the loop performing about 10x faster on Node v10.5.0 — juanpa.arrivillaga, Nov 21 '18 at 17:12
I figured, just thought it might be of interest. I'm seeing the opposite in the browser as well, Chrome too. Version 70.0.3538.102 (Official Build) (64-bit) — juanpa.arrivillaga, Nov 21 '18 at 17:16
@tommyO except that answer makes the opposite conclusion that this benchmark is demonstrating. — Patrick Roberts, Nov 21 '18 at 17:21
This is especially interesting as Buffers are multithreaded, therefore the difference might be caused by different thread locks (lock & unlock at every iteration vs. lock iterate unlock) (haven't worked with them yet, so I can't tell if that really matters) — Jonas Wilms, Nov 21 '18 at 17:21
When I was modifying the benchmark to see what might be affecting performance, I noticed that isolating the scope of `sum` for each test at least makes the results more consistent. This benchmark results in `reduce` performing 3-10x faster in the first run on Chrome 70, and then up to 60x faster on sequential runs, whereas if you put them into separate block scopes and use `let` or `const`, it consistently performs about 10x faster on all runs for me. — Patrick Roberts, Nov 21 '18 at 17:25
@JonasWilms I'm not sure it's the Buffers been multi-threaded, but more the fact the buffers are typed,. See my answer below. — Keith, Nov 22 '18 at 11:31
@PatrickRoberts I think it a classic, comparing apples to oranges syndrome, see my answer the for loop is now 5 times faster. — Keith, Nov 22 '18 at 11:53

Keith · Answer 1 · 2018-11-22T11:22:49.693

In your first example your giving the V8 compiler lots of hints about what the type is, so there is no boxing / unboxing for it to worry about.

A slightly modified version of the for loop here.. On my machine the for loop is now about 5 times faster than the reduce.

var len = 8e6

function *rands(){
  for(let i =0; i < len; i++)
    yield Math.random()
}

var add = (a,b) => a + b
var arr = new Float64Array([...rands()])


console.time('reduce')
var sum = arr.reduce(add)
console.log(sum)
console.timeEnd('reduce')

console.time('loop')
var sum = new Float64Array([0]);
for(var i = 0; i < len; i++)
  sum[0] += arr[i];
console.log(sum[0])
console.timeEnd('loop')

As you can see sum[0] += arr[i]; , it's now easy for the V8 compiler to know that this calculation is using a Float64 for adding, because both left & right sides have to be a Float64.

When you had -> sum += arr[i], the right side V8 knows it's a Float64, but the left side could be anything, it could be an integer, string, or even a Float64, so the V8 has to check if it needs boxing into a Float64.

With reduce, again it's implicit that the left & right sides of the add function are going to be Float64, because the v8 engine is traversing an array of Float64, a & b it knows are going to be Float64.

To verify the final claim it would be interesting how `arr.reduce(add, 0)` or `var sum = arr[0];` perform — Jonas Wilms, Nov 22 '18 at 12:59
@JonasWilms It has very little effect, yes the accumulator will initially be untyped, but after the first pass it's now known to be Float64, as it would now be boxed, and there would be no reason to unbox back to untyped. IOW: All other ops in the loop are known to be Float64. That's how I see it anyway, I might be off base.. :) — Keith, Nov 22 '18 at 14:52
@JonasWilms Also doing `var sum = arr[0]` will cause it to be unboxed, you need to keep access to `arr[..]` directly to ensure Float64 typing. — Keith, Nov 22 '18 at 14:56

For loop slower than reduce?

1 Answers1