I replaced 2 instance of using `Math.sqrt.to_u32|64`

with `Math.isqrt`

in a program and the (stripped) binary was 4KB larger (1.3.1).

Does that code take up that much more space, or is it a compiler inefficiency?

I replaced 2 instance of using `Math.sqrt.to_u32|64`

with `Math.isqrt`

in a program and the (stripped) binary was 4KB larger (1.3.1).

Does that code take up that much more space, or is it a compiler inefficiency?

Is this accounting for 4KB filesystem node sizes? That could make a difference of anywhere from 1–8191 bytes *look* like a 4KB size increase.

And not only that, upon further testing, using `Math.isqrt`

takes more memory (about 600MB for same inputs) at runtime compared to using `Math.sqrt`

which really boggles my mind!

Are you using `BigInt`

? A basic benchmark is showing that `Math.isqrt`

shouldn’t allocate any memory for any of the primitive integer types, but `Math.isqrt(BigInt)`

does allocate memory. I’m not sure there’s anything we can do about that, since the implementation calls LibGMP directly, unless there’s something weird going on with blocks.

All the numbers are 64-bit.

Are you able to share any of the code?

Here’s the code you can test.

`Math.isqrt`

is used on these 2 loc.

1st use loc 126, inside `sozpg`

2nd use loc 243, inside `twinprimes_ssoz()`

Byte size of stripped binary for different use cases with 1.3.2

Without Math.isqrt: 496040

With just 1st use::: 496040

With just 2nd use:: 500136

With both using it:: 500136

1 Like