jakobkummerow

V8 developer here. We would be thrilled to see d8 added to the Compiler Explorer; however for JavaScript the difficulty is that what the optimizing compiler does depends heavily on...

Using faster algorithms (Karatsuba and others) is certainly possible. Currently, JSBI uses naive/"schoolbook" algorithms for all operations. I'm not very enthusiastic about it because JSBI is intended to be compiled...

Indeed, V8's built-in BigInts now(*) use Karatsuba multiplication (when they're large enough). And there's more to come, stay tuned :-) (*) As of today: on Chrome Canary; will be in...

As I said: "more to come" :-) If you want to stay up to date, you can follow/star [crbug.com/v8/11515](https://crbug.com/v8/11515).

Thanks for these contributions, I appreciate the eagerness to help! I must admit that I'm not a huge fan of this particular approach though. For example, testing that `a &...

After a bit of digging, it looks like [this patch](https://github.com/GoogleChromeLabs/jsbi/commit/2b9ba13513d294c523a22b726f47c6db30588b6a), which was meant to make accidental uses of `+JSBI.BigInt(42)` throw an error, has a side effect of also making `new...

Generally speaking, the key difference is access to wide machine instructions. A JS engine on x64 hardware can use 64bit×64bit→128bit multiplications. In JavaScript, you can use either `Math.imul()` for a...

> even WebAssembly has no access to 64x64->128 bit multiplication 64×64→128 bit multiplications are not portable. x86_64 has them, many other architectures don't. > calls from JS to WebAssembly still...

> could someone explain how this differs / interacts with the interface types proposal The primary focus of Interface Types is passing around data by copying it (and allowing engines,...

> there seems to be no way to create a field that cannot be read except by the creating module I don't think I understand this concern? The idea is...