HP Forums

Full Version: What makes the Prime so fast?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Is it a result of the processor used? Clock speed? Firmware? I'm just curious to know why it smokes every other calculator in benchmarks. (Not that I'm complaining!)

Tom L
Prime is slow compared with free42 on Galaxy Samsung S5, the same goes for paridroid on the same phone.
(02-18-2016 06:55 PM)Gerald H Wrote: [ -> ]Prime is slow compared with free42 on Galaxy Samsung S5, the same goes for paridroid on the same phone.

Yeah but those aren't dedicated calculators. I was comparing it to other calculator hardware. Still, that's good to know. Thanks.

Tom L
The prime hardware is amazing, there is no other calculator similar in specs for the moment.
It's the elves. They push hard and run fast on the little wheel inside.
(02-19-2016 04:48 AM)Tim Wessman Wrote: [ -> ]It's the elves. They push hard and run fast on the little wheel inside.

Hee hee! Is that an official HP statement? Smile
(02-19-2016 04:48 AM)Tim Wessman Wrote: [ -> ]It's the elves. They push hard and run fast on the little wheel inside.

Greetings Tim Smile

What about the new firmware for the HP Prime Confused We are waiting since September 2015 Sad

And please, don't get angry for my question Sad ...
The primary factor in the Prime's speed is indeed the raw CPU speed. Secondary factors are probably that Bernard Parisse and HP didn't screw up the implementation too much.

Now if only the Prime had 64 MB of RAM or more, instead of having no more RAM than a '2007 Nspire Clickpad... that would give it a lot more headroom for 1) complex user programs and 2) more OS features before out of memory issues strike Smile
(02-20-2016 03:11 PM)debrouxl Wrote: [ -> ]The primary factor in the Prime's speed is indeed the raw CPU speed. Secondary factors are probably that Bernard Parisse and HP didn't screw up the implementation too much. …
While I usually think, for some comments, it's better for me to make like a duck and let them slide like water off a duck's back, occasionally the duck has to rearrange his feathers.

There's a whole host of issues in getting a working product out to market. The HP team and Bernard are doing a good job. It's very easy to underestimate the amount of issues that can arise, and the size of the beast. To put it in perspective: I help out here and there, and a quick look at the code base turns up >40,000 lines of code in a handful-ish of files I'm the author of. Some implementation bugs have been discussed on this list: if I recall correctly, a grand total of one (1) of these bugs was in code I've put in. (A few+ more have slipped by me, and found elsewhere, but the parts I work on typically aren't popular topics on this board.) This might give a hint at the complexity of the code base: the % of lines with bugs in them has to be incredibly low to get the bug count down. (Some design decisions that should, ideally, eventually, be re-visited / addressed have also been touched on here.)

A fair amount of the code is pretty tight (in some ways) as it was designed with the limits of the 39gII in mind. For example: the Function app currently doesn't employ any offscreen buffers of note in standard plotting / scrolling etc. Things like the signed area display, the tangent line, the marching ants, etc. all rely on colour permutations that can be undone without using any additional memory beyond the screen buffer itself. Changing some of this code to better utilize the increased resources of the Prime is an obvious thing to do, (it would allow for increased speed at the cost of greater memory use) but it takes time and effort… (I mention the Function app view as that's what I'm familiar with, but other parts are similarly parsimonious with resource consumption as it all had to work within the 39gII's limits.)
The HP Prime has amazing modern design/hardware, super thin, solid build quality, a very impressive graphing calculator. It seems to have good battery life, moderate to minimal usage, still 100% after a few weeks (I know the gauge probably goes by 25% increments). I'm no expert, but I feel the CAS is closest to a full PC implementation and seems more powerful than Nspire CAS.
We're probably spoiled, but I'll just mention a couple of possible areas of improvement for what it's worth.
1) Although I've come to appreciate the UI's clarity and ease of use, it seems to lack the kind of top notch graphics design (fonts, GUI elements) that seems to be in the Nspire.
2) I would have preferred that the HP Prime evolved from the HP48/49/50 OS rather than the HP 38/39/40. However, HP did an excellent job incorporating all the useful features in the HP50g like the EQW, a concise RPN entry method, and all the feature rich math apps that incorporated what would have been different environments and input forms in the HP50. Also, for me there's something good to be said about the HP Prime's UI improvements when after using the Prime for a while, going back to the HP50 for me seems a bit clunky (Not criticizing the HP50) because the HP Prime seems more organized.
Just my two cents.
Hello,

Thanks, it is always nice to hear such words (pun intended?) since most comments are negative (understandably, people mostly write because one thing is wrong).

Just rebounding on the battery life, I just picked up a unit that has been on my shelf for over 9 months (untouched), and the battery was still at 50%! I was amazed!

Cyrille
Quote:Just rebounding on the battery life, I just picked up a unit that has been on my shelf for over 9 months (untouched), and the battery was still at 50%! I was amazed!
Try that with a TI-Nspire CX (CAS) ^^

Every few months, I pick up my CX CAS for testing libti*/tilp, and its battery is usually at 0%, despite the automatic deep sleep mode, which I think I left enabled. Granted, it's a A hardware revision from 0411 (W from 1115 is the latest known one at the time of this writing), and I recently noticed that its battery swell, but it's always behaved that way, and my experience largely matches others'.
(02-23-2016 07:06 AM)cyrille de brébisson Wrote: [ -> ]"... since most comments are negative..."

I'm sorry you feel it that way. So, I can tell you I am very happy to have HP Prime on my android phone. Its capabilities are so far ahead from other competitors. But this doesn't mean HP Prime is perfect (for example COPY/PASTE as only method how to export/import things doesn't solve everything and it is really from stone era).
(02-22-2016 10:57 PM)David Wrote: [ -> ]I would have preferred that the HP Prime evolved from the HP48/49/50 OS
In addition to the CPU speed, another big reason that the Prime is fast is because it isn't based on the 48/49/50 OS. SysRPL is slower than machine code. User RPL is slower than SysRPL. By way of comparison, C code running on the 50G is typically about 100 times faster than UserRPL in my experience. I haven't compared it to SysRPL, but I suspect it's about 5 times faster. Much of the 48/49/50 OS is written in SysRPL.

Now it's true that Prime programs run as an interpreted byte code, but I suspect that code doesn't have to do all the parameter checking that UserRPL does.

Lastly, the memory management in the RPL calcs makes updating the OS really difficult. Garbage collection can happen at pretty much any time, which means that all of the data can move.
Hello,

48 was slow because it had a 4mhz, 4 bit CPU with an average instruction execution time of 8 cycles and a very slow memory sub-system.

On top of this, Rpl (sys or not) lead to a lot of memory allocations (and we just stated that memory accesses were expensive on the system).

50 series were slow because they emulated the above system. And, although they had a 70Mhz Arm CPU, emulating a 4 bit system with the ARM is not that easy (not optimal to say the least).

Rpl is actually pretty efficient from a structural standpoint (especially with the PC=(A) instruction!) think about it, it only took 3 instructions to move from one RPL entry point to the next (A=DAT0.A, D0=D0+5, PC=(A)). This is better than any interpreter/virtual machine can do to 'execute the next instruction'...


Prime is fast because it does not have great, modern HW (400Mhz, memory cache, 1 cycle per instruction) and because there is no extra emulation layer.

HPPL is actually not that fast, nor is it memory efficient. It has lots of checks, just like in RPL. It just benefits from a much better HW and memory allocation scheme.

Cyrille
I'm glad to be able to contribute some genuine hobbyist feedback that went through and to know that HP listens.
BTW, just like to mention the 3D graphing program and touch gestures are also amazing and am thankful for the work that went into it. I'm no computer scientist, so I can't really figure out the big picture about why RPL would be slow but efficient on the older calculators and what makes the Prime so fast; that's probably days worth of lecturing. But HPPL on the Prime seems to be much more powerful than User/SysRPL if they're able to make the 3D graphing program. But that achievement is likely due to modern Prime hardware. The HP49/50 also did have a 3D plotter with rotation. I have yet to try out every feature on the Prime.
Hello,

What really enabled the 3D plotter on Prime is a joint effort between Han and HP.

Han did all the app work. But his first version was "inefficient" because he had to do all the visual calculations in HPPL (rotation/transformation/projection/clipping...).

HP then updated the Triangle function to let it do natively all these operations. This saves a lot of arguments checking, bytecode interpreting, memory management... and allows the display to go much faster. Think of it as the equivalent of the first gen 'intelligent' 3D graphic card.

Such 3D was not possible on the 48g as calculations were much slower and drawing even slower. Plus, it only had a B&W screen.

Cyrille
Thanks for giving some insight into the 3D graphing app! It would be an interesting project to study the code to get a better grasp of the technical aspects you mentioned.
Reference URL's