4 ms·

Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?

by aikah 12y ago

GvS 12y ago
It's explained on linked page under 'How?' section.
ajanuary 12y ago
From TFA: native functions often have to cover complicated edge cases from the ECMAScript specification [...] By optimising for the 99% use case, fast.js methods can be up to 5x faster than their native equivalents.
fyolnish 12y ago
By being naive implementations that don't follow the ECMAScript standard.
netcraft 12y ago
This is mentioned in the readme: https://github.com/codemix/fast.js#how https://github.com/codemix/fast.js#how The two functions do not necessarily work the same way - the native implementation handles edge cases that the fast version drops.
phpnode 12y ago
author of the library here. The native implementations have to follow the spec exactly, which means that they have to guard against specific edge cases. The reimplementations in fast.js do not follow the spec exactly, they optimise for 99.9% of use cases and totally ignore the 0.1%. This, combined with the fact that the JS is JITed straight into machine code anyway gives fast.js a significant advantage - it does less work and so is faster.
- sp332 12y ago
  Do you have documentation on the differences in behavior?
chrisseaton 12y ago
They're non compliant - it's a meaningless comparison as the two implementations do different things.
- basicallydan 12y ago
  It's not meaningless, they're just demonstrating how using the library may be more efficient in "99%" of cases. It's not mean to be a competition :)
- nixarn 12y ago
  Why would it be meaningless? The comparison shows that fast.js works for what it was intended to do, it's doing stuff faster than it's native counterparts.
- dspillett 12y ago
  To say the comparison is meaningless is a little unfair. Generally yes, the results are not expected to be 100% equivalent as these routines do not produce the same results for some inputs. But as the range of inputs for which the results are expected to be the same is defined, the comparison is meaningful within those bounds (which covers quite a lot of the cases those functions will be thrown at).
- coldtea 12y ago
  Nothing "meaningless" about it. It's not like they do apples and oranges. They do slightly different varieties of apples -- ignore some BS edge cases that few ever use in the real world. If I rewrite project X into X v2 and throw away 2-3 seldom used features in the process, it doesn't mean that comparing v1 and v2 is meaningless. You compare for what people actually use it for -- the main use cases. Not for everything nobody cares about.
  - coldnebo 12y ago
    From a computer science perspective it is formally 'meaningless' because the performance improvement was made by changing the requirements, not by a novel algorithm or data structure. This is always possible, but it ignores the original constraints of the problem and hence doesn't shed any additional meaning on how to solve the original problem. From a programmer perspective, that might not change the fact that it's useful. It has 'meaning' to the programmer in that it helps us solve a particular problem. Typically, app programmers are not as concerned with how the problem was solved. I like the library, but to avoid this kind of criticism, don't call it a reimplementation. Call it what it is, an alternative library of functions.
oneeyedpigeon 12y ago
Which makes it more a 're-imagining' than a re-implementation, but still useful in the vast majority of cases, of course.
coldtea 12y ago
>Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ? They say some in their readme. Because the native versions have some extra baggage (sparse array checks, etc). But to answer in general: 1) JS functions also get compiled to native code for often used code paths. That's what the JIT does after all. 2) A JS function might use a better algorithm compared to a native function. 3) Native is not some magic spell that is always speedier than non-native. Native code can also be slow if it carries too much baggage.
- kosinus 12y ago
  'Native' in V8 also does not always mean 'implemented in C++'. The readme mentions `Array#forEach`. This is the V8 implementation: https://code.google.com/p/v8/source/browse/trunk/src/array.js?r=21951#1147 https://code.google.com/p/v8/source/browse/trunk/src/array.j...

Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?

by aikah 12y ago

Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?

GvS 12y ago

It's explained on linked page under 'How?' section.

ajanuary 12y ago

From TFA: native functions often have to cover complicated edge cases from the ECMAScript specification [...] By optimising for the 99% use case, fast.js methods can be up to 5x faster than their native equivalents.

fyolnish 12y ago

By being naive implementations that don't follow the ECMAScript standard.

netcraft 12y ago

This is mentioned in the readme: https://github.com/codemix/fast.js#how https://github.com/codemix/fast.js#how The two functions do not necessarily work the same way - the native implementation handles edge cases that the fast version drops.

phpnode 12y ago

author of the library here. The native implementations have to follow the spec exactly, which means that they have to guard against specific edge cases. The reimplementations in fast.js do not follow the spec exactly, they optimise for 99.9% of use cases and totally ignore the 0.1%. This, combined with the fact that the JS is JITed straight into machine code anyway gives fast.js a significant advantage - it does less work and so is faster.

sp332 12y ago
Do you have documentation on the differences in behavior?

chrisseaton 12y ago

They're non compliant - it's a meaningless comparison as the two implementations do different things.

basicallydan 12y ago
It's not meaningless, they're just demonstrating how using the library may be more efficient in "99%" of cases. It's not mean to be a competition :)
nixarn 12y ago
Why would it be meaningless? The comparison shows that fast.js works for what it was intended to do, it's doing stuff faster than it's native counterparts.
dspillett 12y ago
To say the comparison is meaningless is a little unfair. Generally yes, the results are not expected to be 100% equivalent as these routines do not produce the same results for some inputs. But as the range of inputs for which the results are expected to be the same is defined, the comparison is meaningful within those bounds (which covers quite a lot of the cases those functions will be thrown at).
coldtea 12y ago
Nothing "meaningless" about it. It's not like they do apples and oranges. They do slightly different varieties of apples -- ignore some BS edge cases that few ever use in the real world. If I rewrite project X into X v2 and throw away 2-3 seldom used features in the process, it doesn't mean that comparing v1 and v2 is meaningless. You compare for what people actually use it for -- the main use cases. Not for everything nobody cares about.
- coldnebo 12y ago
  From a computer science perspective it is formally 'meaningless' because the performance improvement was made by changing the requirements, not by a novel algorithm or data structure. This is always possible, but it ignores the original constraints of the problem and hence doesn't shed any additional meaning on how to solve the original problem. From a programmer perspective, that might not change the fact that it's useful. It has 'meaning' to the programmer in that it helps us solve a particular problem. Typically, app programmers are not as concerned with how the problem was solved. I like the library, but to avoid this kind of criticism, don't call it a reimplementation. Call it what it is, an alternative library of functions.

oneeyedpigeon 12y ago

Which makes it more a 're-imagining' than a re-implementation, but still useful in the vast majority of cases, of course.

coldtea 12y ago

>Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ? They say some in their readme. Because the native versions have some extra baggage (sparse array checks, etc). But to answer in general: 1) JS functions also get compiled to native code for often used code paths. That's what the JIT does after all. 2) A JS function might use a better algorithm compared to a native function. 3) Native is not some magic spell that is always speedier than non-native. Native code can also be slow if it carries too much baggage.

kosinus 12y ago
'Native' in V8 also does not always mean 'implemented in C++'. The readme mentions `Array#forEach`. This is the V8 implementation: https://code.google.com/p/v8/source/browse/trunk/src/array.js?r=21951#1147 https://code.google.com/p/v8/source/browse/trunk/src/array.j...