New G2 HP Prime

[Claudio L.]

(08-30-2018 10:56 PM)Anders Wrote:  Yes and you can be sure that I understand that. However,
1. the code is different for every platform, (since they use different languages to implement the same basic algorithm)
2. therefore the implementation is different for every platform (allowing for optimizations)
3. it's not clear how each benchmark was measured and how many times in each test

In other words it is already difficult to compare platforms without understanding this.

If x0% of the time in a benchmark running one loop is due to malloc's or what other stuff the OS is doing just to set up the process/tread of the program before it executes the main algorithm, are we measuring what we want to measure? (speed at which it solves a problem executing a particular algorithm - which is the same on all platforms). I think not.

I didn't read all of the implementations, but they look pretty similar, saving language differences. Perhaps the only really different ones are the RPL and sysRPL ones because of the heavy stack use, but the algorithm is 100% identical.
I get your point, C code can allocate all local variables including an 8-element vector with a single assembler instruction, the HP Prime takes its sweet time doing the MAKELIST(), the RPL machines don't need to create the list in advance, they use the values in the stack and create the vector at the end. These are very subtle differences, but I think they are "part of the beast". If a particular machine is slow to handle lists, so be it. The RPL code could leave the 8 values on the stack, doesn't really need to create the list either, but it was left there to make it comparable (RPL machines are also quite slow to handle lists).
It's hard to do benchmarks, and highly subjective, Xerxes has done a great job for many years collecting these results.
The results are very clear in my opinion: You can see the code that was executed, listed right there. For machines that are too fast, that code as-listed was executed multiple times and the total running time divided by the number of loops.
Let me give you another example: newRPL has extremely fast local variables, so perhaps it would be faster to re-code the algorithm using local variables rather than stackrobatics. However, it was benchmarked using the same code as the HP28,48,49g,49g+ and 50g. It may seem a bad idea to you, but I think it's more useful to have a comparable value than the fastest possible.