+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: HP Calculators (and very old HP Computers) (/forum-3.html)
+--- Forum: General Forum (/forum-4.html)
+--- Thread: Update of Emu28 to v1.30 (/thread-6470.html)
Update of Emu28 to v1.30 - Christoph Giesselink - 06-28-2016 06:56 PM
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.
Christoph
RE: Update of Emu28 to v1.30 - RPL Calcs - 06-29-2016 11:59 AM
Cheers, Mr. Giesselink.
Thank you for your wonderful contributions
to the HP calculators users.
Best regards.
RE: Update of Emu28 to v1.30 - Christoph Giesselink - 06-30-2016 04:52 PM
(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
vs.
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
vs.
2) m * m > nNumber