Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Well, presumably you could implement a language with bignums in PNaCL with reasonable efficiency, something which is evidently not possible in JS.


Why is that evidently not possible? :) Serious question, I would guess anything that can be done in C - and bignums can - could be done well in JS, because typically C code compiled to JS runs at about half the speed of native.

If you have results showing otherwise for bignums, I would be very interested. Anything special about that particular problem?


> Why is that evidently not possible? :)

Because Mozilla assured us that it was not. Central to Mozilla's case against Dart was the assertion that parts of it - including bignums - could not be implemented efficiently by compiling to JS, leaving native Dart runtimes at a strong advantage.


Link?



Thanks, reading that it says that native bignum support can speed things up. That's probably true - the only question is how much. If it's 25% vs 2,500% then that's what matters. I don't see an actual debate about numbers in that thread there, just generalities?

As I said above, I would expect JS to reach about half of the speed of C. It's possible that having native bignums would have removed some of that difference.

More importantly, the context here is PNaCl. Do you see a reason bignums could be emulated better in PNaCl vs JS? I assumed that's what you were implying, but perhaps I misunderstood you? Sorry if so.


I'm not sure the poster meant "bignum" as in huge numbers like GnuMP handles, or if he meant exact 64-bit integers, which JS doesn't have (natively).


I think true arbitrary-size bignums, because that's what Dart has?


The former - afaik, in computing 'bignums' has always been taken to mean arbitrary-precision integers.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: