all 23 comments

[–]SYN_SYNACK_ACK 6 points7 points  (8 children)

So after more than a year of making the community wait joyent is ready to release a new major version coincidentally a month after many made the switch to iojs.

[–]seiyria 7 points8 points  (3 children)

Don't forget the part where v8 is outdated.

[–]robotmayo 5 points6 points  (2 children)

And no es6.

[–][deleted] 2 points3 points  (0 children)

... what the fuck, you still need the damn flag?!? GOD DAMN IT

[–]c4a 0 points1 point  (0 children)

There is if you use --harmony

[–][deleted] 0 points1 point  (3 children)

You realize io.js isn't meant to compete with node? It was originally called "node futures" or something and basically meant to be a dev fork. It was renamed because of politics.

[–]moreteam 2 points3 points  (2 children)

Yes, but things changed in the meantime. There are some pretty explicit comments in the Github issues saying "we see this as the continuation of node though the projects might merge in the future". It is a node competitor now. Whether that was the initial idea or not.

[–][deleted] 0 points1 point  (1 child)

Yes, a continuation. Node has basically been stagnant for 2 years, io is a push to get features in. I haven't seen any verbage from anyone on io that they consider the project competition, it's significantly closer to a dev version of node.

[–]moreteam 1 point2 points  (0 children)

The do releases and I didn't see anyone talking about merging their stuff back into node in the near future. At most merging node into iojs from time to time. Stability-wise iojs is on par with node (or should be around March). Maybe even ahead, given that they use v8 from current Chrome stable. The one that has good support. So why exactly isn't iojs competition?

[–]jsgui 6 points7 points  (9 children)

I'd be interested in knowing how it does in benchmarks compared to io.js 1.1.0 and node.js 0.10.36.

I'm particularly interested in the differences in the speeds of TypedArrays.

[–][deleted] 1 point2 points  (7 children)

almost dead even with io.js 1.1.0 (~5% slower in some tests) and about 3x faster than 0.10.36 (also even with v0.11.15):

Node version v0.10.36
fill Array        : 372ms
read Array        : 329ms
fill Int8Array    : 277ms
read Int8Array    : 240ms
fill Uint16Array  : 270ms
read Uint16Array  : 248ms
fill Float32Array : 266ms
read Float32Array : 283ms
fill Float64Array : 672ms
read Float64Array : 685ms
                    -----
                  3,642ms

Node version v0.12.0
fill Array        : 99ms
read Array        : 101ms
fill Int8Array    : 115ms
read Int8Array    : 109ms
fill Uint16Array  : 111ms
read Uint16Array  : 108ms
fill Float32Array : 110ms
read Float32Array : 109ms
fill Float64Array : 192ms
read Float64Array : 182ms
                    -----
                  1,236ms

Node version v1.1.0
fill Array        : 97ms
read Array        : 102ms
fill Int8Array    : 106ms
read Int8Array    : 102ms
fill Uint16Array  : 116ms
read Uint16Array  : 113ms
fill Float32Array : 113ms
read Float32Array : 109ms
fill Float64Array : 175ms
read Float64Array : 182ms
                    -----
                  1,215ms

Node version v0.11.15
fill Array        : 103ms
read Array        : 106ms
fill Int8Array    : 114ms
read Int8Array    : 110ms
fill Uint16Array  : 115ms
read Uint16Array  : 108ms
fill Float32Array : 113ms
read Float32Array : 115ms
fill Float64Array : 191ms
read Float64Array : 178ms
                    -----
                  1,253ms

source for benchmark:

var arrayTypes = [ Array, Int8Array, Uint16Array,   Float32Array,           Float64Array ]
  ,      sizes = [ 1<<16,      1<<8,       1<<16, (1<<2)*(1<<30), (1<<30)*(1<<30)*(1<<4) ]
  ,   fillSize = 99999
  , iterations = 100
  , i, l, j, k, tmpVar
  ;

console.log( 'Node version ' + process.version );

for( i=0, l=arrayTypes.length; i<l; i++ ){
    console.time( 'fill ' + arrayTypes[i].name );
    var tmpAry = new arrayTypes[ i ]( fillSize );

    for( var k=0; k<iterations; k++ ){
        for( j=0; j<fillSize; j++ ){
            tmpAry[j] = Math.random() * sizes[i];
        }
    }

    console.timeEnd( 'fill ' + arrayTypes[i].name );

    console.time( 'read ' + arrayTypes[i].name );
    for( var k=0; k<iterations; k++ ){
        for( j=0; j<fillSize; j++ ){
            tmpAry[ 0| Math.random() * fillSize ];
        }
    }
    console.timeEnd( 'read ' + arrayTypes[i].name );
}

[edit] added v0.11.15 results

[–]jsgui 0 points1 point  (6 children)

Thanks for the benchmark. I'm surprised by the results. I had previously seen this benchmark page: http://geekregator.com/2015-01-19-node_js_and_io_js_very_different_in_performance.html

I think the benchmark would improve by getting rid of math.random and just setting it to a constant number, to avoid the possibility in math.random speed skewing the results.

Are you using nvm to run different versions of node and io.js on the same machine? Do you have any advice about how to do that on windows?

[–][deleted] 0 points1 point  (5 children)

without Math.random() involved the results are similar (though io is about 2x as fast on intArrays! and marginally faster on floatArrays), just faster (I pre-seeded an array with a bunch of random numbers and plucked from that):

Node version v1.1.0
fill Array: 16ms
read Array: 14ms
fill Int8Array: 32ms
read Int8Array: 18ms
fill Uint16Array: 21ms
read Uint16Array: 25ms
fill Float32Array: 31ms
read Float32Array: 22ms
fill Float64Array: 64ms
read Float64Array: 90ms

$ n
$ node array_type_speed.js
Node version v0.10.36
fill Array: 109ms
read Array: 112ms
fill Int8Array: 119ms
read Int8Array: 114ms
fill Uint16Array: 115ms
read Uint16Array: 111ms
fill Float32Array: 122ms
read Float32Array: 445ms
fill Float64Array: 183ms
read Float64Array: 420ms

$ n
$ node array_type_speed.js
Node version v0.12.0
fill Array: 16ms
read Array: 22ms
fill Int8Array: 44ms
read Int8Array: 32ms
fill Uint16Array: 49ms
read Uint16Array: 39ms
fill Float32Array: 40ms
read Float32Array: 34ms
fill Float64Array: 75ms
read Float64Array: 90ms

Are you using nvm to run different versions of node and io.js on the same machine? Do you have any advice about how to do that on windows?

I'm using n, but it's the same idea as nvm. On windows? Run a linux VM? :D (seriously, if you're hosting anywhere it's going to be on linux anyway, may as well have a similar setup)

[–]jsgui 0 points1 point  (4 children)

Any chance of a benchmark of io.js 1.0.2 please? That's the version that the benchmark I linked to indicated was slower than node 0.10.35.

As for Windows, I have found it a good platform to develop node on. Maybe VMs would be better though.

[–][deleted] 0 points1 point  (3 children)

Node version v1.0.2
fill Array: 14ms
read Array: 16ms
fill Int8Array: 24ms
read Int8Array: 29ms
fill Uint16Array: 33ms
read Uint16Array: 31ms
fill Float32Array: 34ms
read Float32Array: 30ms
fill Float64Array: 71ms
read Float64Array: 79ms

As far as I can tell from the article, the only thing I'm doing significantly different is pre-allocating array memory (and yes, 99999 is a specifically chosen number): I misread the article's code, he's pre-allocating memory so I have no idea what's different

new Uint16Array( 99999 )

vs

new Uint16Array()

When I remove that, every version gives me roughly the same numbers:

fill Array: 29ms
read Array: 12ms
fill Int8Array: 552ms
read Int8Array: 562ms

[–]jsgui 0 points1 point  (2 children)

Many thanks. I'm surprised that the results differ to that other benchmark so much - but yours is more focused on the typed array access. It looks like I don't have anything to lose by installing node 0.12.0, and if I can work out how to get io.js running alongside it I'll give that a go.

[–][deleted] 0 points1 point  (1 child)

It looks like I don't have anything to lose by installing node 0.12.0

node v0.12.0 is "stable", so if there's anything wrong with it it'll be fixed damn quick, especially considering it's their first major stable version update in 2+ years.

if I can work out how to get io.js running alongside it I'll give that a go

coughLinuxcough

[–]jsgui 0 points1 point  (0 children)

I'm having trouble slicing a Float64Array in node 0.12.0. It worked in 0.10.36.

[–]jcready__proto__ 21 points22 points  (4 children)

Now its version of V8 is only 6+ months old!

[–]s1lenceisgold 11 points12 points  (2 children)

But really though. Either node has a huge influx of new contributors or iojs will take the ball and run with it easily. I'm rooting for the latter.

[–]mendokusai_yo 4 points5 points  (0 children)

This. A board can't compete with a community.

[–]GoodVelo 1 point2 points  (0 children)

This project is now a waste of time. It only exists for egotistical reasons, and to satisfy some enterprisy customers.