[jrochkind1]

His demo page, in my Chrome, if I enter 10000, it takes about 2 seconds to finish with 10k digits.

But if I enter 100k, it takes 30 seconds to get to reporting 10k digits worth of progress.

Hmm. Have to think about that one. Just cause it's asking JS to do comparisons of much larger numbers?

[ska]

Any numeric representation bigger than your CPU register will not have a fixed operation cost.

[simonbw]

It's not just the comparisons, it's the additions, multiplications and divisions too. When you enter 10,000, each iteration of the loop is working with numbers 10,000 digits long. When you enter 100,000, each iteration is working with numbers 100,000 digits long, which I imagine makes every operation slower.

[soulofmischief]

A number fills the same space in your registers regardless of size, up until the max size, at which point it must be split into multiple operations, and that's when it takes longer.

[nemetroid]

The script uses BigInts to implement (sort of) fixed point arithmetic. So with 100k as input, each operation works at a much higher precision.

[zamadatix]

I'd bet a good portion of the difference is between rendering the additional digits as it goes.

[ajennings]

I didn't note timing numbers, but rendering digits in hex was basically instantaneous, even when doing a million (decimal) digits.

Rendering the digits in decimal was significant delay (like 40 seconds for a million digits). That's why it just shows the hex until the very end, and it shows how long the decimal conversion takes.

[zamadatix]

You sure you don't mean converting digits to hex instead of rendering? The constant rendering of the hex digits as the work progresses results in a ~3x slowdown for 100k digits in my testing (see my other comment in this tree).

[ajennings]

Maybe you're right. I know displaying in hex was way faster than displaying in decimal and seemed fast enough, so I stopped there. I didn't test rendering speed specifically.

Doing a million digits in the console (with no status updates) took about an hour and doing it in that page took just over two hours.

[jrochkind1]

What do you mean, doesn't it do that either way?

[zamadatix]

Sure but one has 10x more digits than the other so takes a heck of a lot longer to convert and display the string for the same number of iterations.

As a quick test of my theory the majority of the time is being spent trying to display the progress: - Default 100,000 = 58.276 - CSS display: none; = 22.359 - Display when done = 20.057

[jrochkind1]

> Sure but one has 10x more digits than the other so takes a heck of a lot longer to convert and display the string for the same number of iterations.

Hm, I was comparing the same number of digits displayed on screen though. One takes 2s to compute and display 10k digits of information on screen, one takes 30s to compute and display 10k digits of information on screen. same number of digits. At least according to the "progress" output that reads "Digits done".

I may be confused. But you have looked at the demo, right?

[zamadatix]

> I may be confused. But you have looked at the demo, right?

I have run the demo multiple times, how else would I have generated the time it took for me to run it in the comment above :).

> Hm, I was comparing the same number of digits displayed on screen though. One takes 2s to compute and display 10k digits of information on screen, one takes 30s to compute and display 10k digits of information on screen. same number of digits. At least according to the "progress" output that reads "Digits done".

"Digits done" is the number of correct digits, not the number of displayed digits. It's possible your screen area is too small to notice the difference.

Here is an in progress shot of 10k at 2088 "Digits done" https://i.imgur.com/Fbuw2sc.png

Here is an in progress shot of 100k at 1849 "Digits done" https://i.imgur.com/O1gTogQ.png

As you can see "Digits done" ~= "Digits displayed" in this demo by any means. It simply represents the number of digits that will no longer change as the calculation continues, it is still displaying all the digits every update regardless if they are "done" or not which is where the inefficiencies in rendering come in (and based on the above benchmarks outweigh any other inefficiencies with number size substantially).

[jrochkind1]

Aha, I see, thanks!