Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
Which makes it more a 're-imagining' than a re-implementation, but still useful in the vast majority of cases, of course.
Show HN: Fast.js – faster reimplementations of native JavaScript functions
11–20 of 168 posts
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#12Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
They're non compliant - it's a meaningless comparison as the two implementations do different things.
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 :)
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#13Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
They're non compliant - it's a meaningless comparison as the two implementations do different things.
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.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#14I'm interested in what those edge cases are, to say it works in 99% of the cases but provide no caveats makes me think that I might be surprised by something if I use it.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#15I'm interested in what those edge cases are, to say it works in 99% of the cases but provide no caveats makes me think that I might be surprised by something if I use it.
As well as the example of "sparse arrays" shown in the README, there are some additional slight gotchas around `.bind()`, e.g. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
These fall outside of the common uses of these methods, and most people don't even know they exist.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#16Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
>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.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#17Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
They're non compliant - it's a meaningless comparison as the two implementations do different things.
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).
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#18Some V8 people here ? how can a JS re-implementation be faster than the native implementation of a function ?
They're non compliant - it's a meaningless comparison as the two implementations do different things.
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.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#19Javascript. The language where you can reimplement basic functions such as map, each, reduce (which by the way are still available for objects in 2014) and have them be faster than their native counterparts.
It might be that I don't particularly like the language. but it's kind of frightening that we're building the world on that stuff.
Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions
#20Javascript. The language where you can reimplement basic functions such as map, each, reduce (which by the way are still available for objects in 2014) and have them be faster than their native counterparts. It might be that I don't particularly like the language. but it's kind of frightening that we're building the world on that stuff.
An alternative interpretation might be - JavaScript, the high level language language that's so awesome that it can out perform native code*
* as long as you make it do less work