Assembler, but not at all

[komame]

(10-11-2023 10:41 PM)John Keith Wrote:  Later models use ARM processors to emulate the Saturn processor, but the emulation seems quite inefficient- the ARM processor in the 50g runs at 75 MHz but the 50 is not much faster than the 49.

For this reason, my choice for comparison was the 49G, because in the 50G the emulation layer is immeasurable.

(10-11-2023 10:41 PM)John Keith Wrote:  You are partly right, much of the relative slowness of RPL is due to implementation details. Many unfortunate choices were made in the early development of the language due to the small amount of memory available on the older calculators.

Unfortunately, with PPL, it doesn't seem to be much better.
When I discuss something, I like to support my statements with real results and measurements. Given that I no longer have the HP49G (I used it a few years ago), I'd like to refer to a benchmark that was published on the old forum by Gene Wright:
Calculator Benchmark
I know that such a benchmark doesn't measure everything, but it gives a preliminary picture. If something is drastically faster or slower, even such a general measurement will allow us to notice it. This benchmark increases the value by 1 in each loop cycle (counts cycles) for 60 seconds. If we search for the HP 49G here, we will see something like this:

Code:

HP 49G
Count: 12,351
Code: 1. << DO 1. + UNTIL 0. END >>

A value of 12351 for a minute of iterating seems very low (meaning it's very slow), right? This means that RPL needs as many as 19431 CPU cycles for 1 cycle of such a loop (here the CPU speed doesn't matter anymore, as we measure the number of CPU cycles per iteration in a given programming language). We calculate it as follows: [Processor speed in Hz] * [measurement time in seconds] / [number of loop iterations during the measurement]. So in this case: 4000000 Hz * 60 s / 12351 iterations = 19431 CPU cycles.

The same program implemented in PPL would look like this:

Code:

EXPORT LOOPS()
BEGIN
  LOCAL i;
  REPEAT
    i:=i+1;
  UNTIL 0;
END;

and after 60 seconds, the result is 2,950,000 (firmware 14730, tested just after soft reset). So, for one loop cycle, PPL requires 10738 CPU cycles.

At this point, we could say that PPL is about 2x faster than RPL. However, note that we've only considered CPU clocking so far. If we include the RISC architecture used in ARM and the cache (L1) that ARM processors have, which Saturn did not have, plus the memory that is certainly faster in Prime than in HP 49G, then PPL doesn't seem so efficient. I'd even venture to say that considering all these factors, PPL would fare worse than RPL in this benchmark (if it were run on inferior hardware, like the HP49G, even with a large amount of RAM, etc.).

After all, one doesn't have to look far. Python is also an interpreted language, but when we run both PPL and Python on HP Prime, Python clearly wins. For the aforementioned benchmark, Python on HP Prime performs 54,000,000 iterations, which results in only 586 CPU cycles per one loop iteration, and with such a result, we can already speak of a good implementation of interpreted language.

In conclusion:
I completely agree that RPL is inefficient and was designed from the outset with certain hardware limitations in mind. However, despite all this, PPL doesn't seem to be any better, even though it wasn't subject to such limitations when it was designed.
PPL is considered fast just because it operates on an incredibly fast machine, and if we were to run RPL on such a machine, looking at the above results, I think it would perform comparably to PPL (or even better).

EDIT: I forgot that I still have the G1, which primarily differs from the G2 in its CPU architecture (ARMv5 vs ARMv7) and the actual processor clock speed is just a little over 20% difference. In this test, the G1 [400MHz] scores as follows: 845,000 iterations / 28402 CPU cycles per one loop iteration (so it is worse than RPL on HP49G), which unfortunately confirms that under such conditions, RPL would probably take the lead (but this doesn't reflect well on RPL, it just reflects poorly on PPL). Therefore, having any language on the HP Prime with the ability to compile to machine code, it might turn out that it operates even thousands of times faster than PPL (e.g. compiled Forth-ish language, which could be used only in performance-critical spots, wouldn't need to be a sophisticated language; basic commands would suffice, while the rest of the program could operate in PPL or Python).