HP Forums

Full Version: Update of Emu28 to v1.30
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
After a long period of time Emu28 v1.30 is available at http://hp.giesselink.com.

This is a maintenance update fixing a nasty bug introduced in the last version or bugs have been inside for a very long time.

A complete list of bugfixes and changes is available here.

Cheers, Mr. Giesselink.

Thank you for your wonderful contributions
to the HP calculators users.

Best regards.
(06-28-2016 06:56 PM)Christoph Giesselink Wrote: [ -> ]...
A complete list of bugfixes and changes is available here.

In this list I find
- changed function iSqrt(), changed implementation to Heron's method
  for speed optimization
How much does this speed optimization effekt affect the UI?

Well, this is not a too serious question. Actually I would be interested in the formerly used method (Newton–Raphson, I assume) and the reason of the speed up, as I am looking for some time for a fast method to compute many-many digits (1000 and more) of a square root.

(06-29-2016 12:40 PM)Mike (Stgt) Wrote: [ -> ]How much does this speed optimization effekt affect the UI?

Hi Mike, we are talking about a function I wrote ~15 years ago. The old integer square root implementation used a half step iteration comparing the square of the guess with the input number. A typical drawing of the circle button style needed 1953 square root iterations overall.

The same drawing using the Heron's method need 1461 iterations, that's 25% less.

What about the complexity of each iteration?

half step iteration = 1 multiplication + 1 addition + conditional jump

Heron's method = 1 division + 1 addition

So the complexity of each iteration is less in the Heron's method than in the half step iteration. So each iteration at the Heron's method should be faster. The major difference is not the additional conditional jump instruction itself, the problem is the opcode prefetch of the CPU. Each wrong jump prediction of the CPU costs many additional CPU cycles filling the prefetch buffers with the correct opcodes, so it's sometimes best to eliminate the conditional jumps. In result changing the method results in a faster execution with less code.

So back to the major question, how much does this speed optimization effect affect the UI?

At actual host platforms not noticeable, so no reason from speed aspects. Change was made during code refactoring, 1st I refactored the half step iteration method code from signed integer to unsigned integer input (signed integer was necessary from internal design aspects) and after reading some literature I changed the method.

We have two effects here, in the last 15 years of Emu development an actual host CPU has a 10 times higher clock rate plus many internal improvements resulting in a CPU speed much more than the 10 times from clock rate.

The second effect comes from the operating system. Until Windows XP the drawing routine has been called at the entire drawing and at each redraw of the window. A redraw condition for example was, that the application window was hidden complete or in parts by another application window.

With Windows Vista MS introduced the Desktop Window Manager service, here most window redrawings are done by the manager and not by the application any more.

But what are the "internal design aspects" I mentioned above:

1) t - b > 1


2) t > 1 + b

Superficial both boolean equations return the same result, but for the 1st equation both numbers must be a signed data type, whereas the 2nd equation works with signed and unsigned data types.

Another change because of same reason:

1) m * m - nNumber > 0


2) m * m > nNumber
Aha. Thank you!
Reference URL's