Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Fast.js – faster reimplementations of native JavaScript functions

github.com

Post reply on HN
Print view View original

21–30 of 168 posts

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#21

Post by kosinus »

coldtea wrote: post #16
aikah wrote: post #2

Some 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' 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.j...

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#22

Post by thegeomaster »

VeejayRampay wrote: post #19

Javascript. 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.

The number of uses we put Javascript to is indeed frightening, given its "fragile" nature and heavy criticism it attracts every now and then.

There is a great, amusing, borderline sci-fi talk by Gary Bernhardt about the future of Javascript and traditional languages compiled to Javascript. My recommendations: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#24

Post by sp332 »

cristiantincu wrote: post #23

> In fact, native functions often have to cover complicated edge cases from the ECMAScript specification, which put them at a performance disadvantage. What. Is. This. I don’t even.

So if you simplify the implementation, it gets faster but more fragile. Why is that confusing?

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#25

Post by sp332 »

phpnode wrote: post #9
aikah wrote: post #2

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

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…

Do you have documentation on the differences in behavior?

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#27

Post by nathanb »

I'm a bit concerned about this...

On one hand, I'm a big proponent of "know your tools". I'll gladly use a fast sort function that falls apart when sorting arrays near UINT32_MAX size if I'm aware of that caveat ahead of time and I use it only in domains where the size of the array is logically limited to something much less than that, for example.

But on the other hand, I write operating system code in C. I need to know that the library functions I call are going to protect me against edge cases so I don't inadvertently introduce security holes or attack vectors.

If I know that some JS I'm interacting with is using fast.js, maybe there will be some input I can craft in order to force the system into a 1% edge case.

The lesson here is probably "don't use this for your shopping cart", but we need to be careful deriding Javascript's builtins for being slow when really they're just being safe.

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#28

Post by jaredmcateer »

VeejayRampay wrote: post #19

Javascript. 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.

That's not really fair, the author of this implementation is non-complainant with the spec by dropping edge cases in order to achieve these improvements.

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#29

Post by VeejayRampay »

phpnode wrote: post #20
VeejayRampay wrote: post #19

Javascript. 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

Why isn't the native version doing less work? Isn't that what you expect from a language design, that the native version will be as close to optimal as possible in the first place?

Re: Show HN: Fast.js – faster reimplementations of native JavaScript functions

#30

Post by kristiandupont »

VeejayRampay wrote: post #29
phpnode wrote: post #20

Earlier quoted context omitted.

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

Why isn't the native version doing less work? Isn't that what you expect from a language design, that the native version will be as close to optimal as possible in the first place?

Did you read the article? These functions are not 100% equivalent.
Post reply on HN