How powerful is the Open Pandora?

[Mr_Loon]

On a real world scale how powerful is my rebirth edition Open Pandora PC? I wanna hear from the pros.

My 3Ghz Quad core desktop PC takes just over 4 seconds to display the shortcut icons associated with 'all programs' via the start menu after a clean boot. On my 256MB CC Pandora the display of said icons is to all intents and purpose instantaneous. So on that real world scale the Pandora is much more powerful than a quad core x86 windows desktop. 

Alternative answer : powerful enough to give a pleasant user experience when using the default OS & powerful enough to flawlessly emulate classic game systems up to PS1. 

 

[_wb_]

Hey _wb_

With Notaz's improved SDL can you quickly test bubbman2? 

If that's running fullspeed with the improved SDL then it means PyGames will work a lot quicker. 

http://repo.openpandora.org/?page=detail&app=bubbman2

I don't know what speed it is supposed to run at, and I couldn't find an easy way to get an FPS count, but you can speed it up noticeably by doing the scaling in hardware instead of in software like it does now: in retrogamelib/display.py, set the scale to 1 and removes the line in update() that call pygame.transform.scale().

Then make a run script that sets up SDL to use notaz' tweaks, e.g. in this case it could be like this:


#!/bin/bash
export SDL_VIDEODRIVER=omapdss
export SDL_OMAP_LAYER_SIZE=scaled
./run_game.py
That seems to help quite a bit already. I don't know if it's enough to make this game "full speed". Python is inherently quite slow because it's interpreted, so during execution it's spending most of its time in a bytecode evaluation loop (which is basically a huge switch() in a while loop) and doing stuff like dynamic type checking.

 

[Rockthesmurf]

I find my Pandora is generally faster than my old HTC Touch HD phone, and generally slower than my newer HTC Desire phone. That's quite a blanket statement, but to me covers the general 'feel' of the device, including navigating menus, launching programs and so on. Compared to more recent phones I own (Samsung S3, BlackBerry Z10) the Pandora is a lot slower (in terms of OS, launching, web browsing, games, everything really).

In terms of software, it has been a while since I used my HTC Desire, but when I last did and tried a PSX emulator it didn't run very well, and DS was certainly out of the question. Drawing a single full screen sprite ran at less than 60 FPS, games generally felt pretty laggy. So in this respect, I'd say the Pandora is better as it has faster emulators, games running at 60 FPS. Part of the reason for this Exophase has covered nicely.

So all in all, I'd say a Rebirth Pandora is somewhat similar to a HTC Desire. For reference the HTC Desire has a 1 GHz CPU, 576 MB RAM and an Adreno 200 GPU and came out in mid 2010.

Finally, in comparison to a desktop PC, I think the last time I had a PC that felt slower than the Pandora was when I had a AMD II 400 MHz (128MB RAM, Vodoo 1) back in 1999. When I upgraded to an Athlon 700 in 2000/2001 (?? RAM, Voodoo 3) that felt faster then my Pandora.

Probably nonsense but my Pandora is like a PC from around the year 2000 or a phone from around the year 2010.

 

[Ziz]

You seem to forget the "power per pixel" (again).

Maybe the caanoo or even the gcw zero is not as powerful as the pandora, but you forget, that the lower resolution has the big advantage, that you have more available power per pixel! So e.g. you could calculate more effects. I ran into this effect, when I compiled my software renderer sparrow3d for the pandora and other handhelds and compared the frames per second:

Of course the pandora has at least five times the power of my gp2x, but because of the also five times bigger screen the test application ran not much faster on the pandora compared to the gp2x. Furthermore, it ran MUCH faster on wiz and caanoo - and on the gcw it will ran even faster!

So, the pandora is the fastest open handheld. Seen absolutely. But not relative per pixel. Why or when does this matter? This matters in post processing like smoothing the output of an emulator or having more fancy effects in a scene.

 

[Asiyura]

[…]


Of course the pandora has at least five times the power of my gp2x, but because of the also five times bigger screen the test application ran not much faster on the pandora compared to the gp2x. Furthermore, it ran MUCH faster on wiz and caanoo - and on the gcw it will ran even faster!


So, the pandora is the fastest open handheld. Seen absolutely. But not relative per pixel. Why or when does this matter? This matters in post processing like smoothing the output of an emulator or having more fancy effects in a scene.

True, but you forget that we have a really nice hardware scaler

So you can run a software at GCW resolution and have better speed.

EDIT : (I forgot the important part) and you'll still have a full screen image.

(The GCW has a 320x240 screen. The best way would be to render at 400x240 and scale it up to pandora's fullscreen 800x480. Even with 60X240 more pixels to render, I guess pandora would be far faster )

 

[origimbo]

That seems to help quite a bit already. I don't know if it's enough to make this game "full speed". Python is inherently quite slow because it's interpreted, so during execution it's spending most of its time in a bytecode evaluation loop (which is basically a huge switch() in a while loop) and doing stuff like dynamic type checking.

How much of that is still true if you're accessing shared objects written in a compiled typed language to do the heavy lifting? Most of my programming experience is in scientific computation, where python seems to be gaining popularity as "glue" for other languages, and the (heavily massaged I assume) benchmarks I've seen didn't have python + C++/Fortran down as all that slow (and a heck of a lot easier to maintain than pure, unreadable, FORTRAN 77). 

 

[Ziz]

[…]

Of course the pandora has at least five times the power of my gp2x, but because of the also five times bigger screen the test application ran not much faster on the pandora compared to the gp2x. Furthermore, it ran MUCH faster on wiz and caanoo - and on the gcw it will ran even faster!

So, the pandora is the fastest open handheld. Seen absolutely. But not relative per pixel. Why or when does this matter? This matters in post processing like smoothing the output of an emulator or having more fancy effects in a scene.

True, but you forget that we have a really nice hardware scaler So you can run a software at GCW resolution and have better speed.

Great. You have a high resolution screen with a very good dpi to... scale up! Because the cpu is too slow to calculate directly for a 800x480 screen? That doesn't argue for the pandora beeing quite fast.

 

[Asiyura]

Well, you were the one saying the pandora is slower (taking in account the per pixel power) than other consoles, not me. So I gave you a solution. 

To be honest, I never felt that the pandora was slow. All the games I've played are fast and responsive and most of them are fullscreen (or near fullscreen). Many of those games would be totally unplayable on lower resolution screens (Baldur's Gate, Freespace :wub:  , Homeworld, …).

 

[A2000]

And that's what long life gaming consoles are for: Squeezing out the last bit of power by optimized software. Remember when that was the normal way of development back when the C64 was aging? Colored borders, 8 way scrolling in split screens, speech output... All on the same computer you bought years ago. Oh, I really like my Pandora! And I cannot praise enough all of you developing this software making such experience possible!


And I also appreciate this kind of discussion where the not-so-techi are offered a look behind the curtain.

 

[fusion_power]

Pandora may be powerful but it also can be very SLOW, or to be more precise, the Software often feels slow, especialy the Desktop. Slow starttmenu, slow menus in general, slow program starts, slow loadings, slow webpage rendering (all browsers I've tested, not only Firefox ) nearly no Multitasking capabilities of the CPU (loading a webpage and scrolling through another one is nearly impossible, again, all tested browsers).

It just feels so slow and not fluid at all. Look at an average smartphone of your choise, it can be the cheapest one, but mostly, it just feels faster in OS, Menus, navigation, handling... Pandora (OS) is far, far away from this and I don't know why, the "rough power" should be there, even in old CC Classic Pandoras. Angström was choosen because it is so small and agile (on paper) but even this seems to not help.

Even my old Windows 3.11 feelt better back then imho. And this was on a 40MHz 386 PC, can you imagine that today? FORTY MHz and Windows ran fluidly.

 

[_wb_]

That seems to help quite a bit already. I don't know if it's enough to make this game "full speed". Python is inherently quite slow because it's interpreted, so during execution it's spending most of its time in a bytecode evaluation loop (which is basically a huge switch() in a while loop) and doing stuff like dynamic type checking.

How much of that is still true if you're accessing shared objects written in a compiled typed language to do the heavy lifting? Most of my programming experience is in scientific computation, where python seems to be gaining popularity as "glue" for other languages, and the (heavily massaged I assume) benchmarks I've seen didn't have python + C++/Fortran down as all that slow (and a heck of a lot easier to maintain than pure, unreadable, FORTRAN 77). 

Sure, if you're just using it as a glue language then it does not matter that it is slow. But in the example of that Python game, I did a quick check with "perf top" and that game is only spending 5% or so of its time in SDL (which is supposed to do the "heavy lifting" since it has the blitting routines etc), another 5% or so in music and sound playback libraries (libasound and libmikmod), and all the rest was spent in libpython, e.g. 21% in PyEval_EvalFrameEx() alone, and the rest in functions like PyObject_GenericGetAttr(), PyDict_GetItem(), PyType_IsSubtype() and so on.

 

[_wb_]

[…]


Of course the pandora has at least five times the power of my gp2x, but because of the also five times bigger screen the test application ran not much faster on the pandora compared to the gp2x. Furthermore, it ran MUCH faster on wiz and caanoo - and on the gcw it will ran even faster!


So, the pandora is the fastest open handheld. Seen absolutely. But not relative per pixel. Why or when does this matter? This matters in post processing like smoothing the output of an emulator or having more fancy effects in a scene.

True, but you forget that we have a really nice hardware scaler
So you can run a software at GCW resolution and have better speed.

Great. You have a high resolution screen with a very good dpi to... scale up! Because the cpu is too slow to calculate directly for a 800x480 screen? That doesn't argue for the pandora beeing quite fast.

This is one of the reasons why I'm arguing against full HD for a potential Pandora successor.

Pandora may be powerful but it also can be very SLOW, or to be more precise, the Software often feels slow, especialy the Desktop. Slow starttmenu, slow menus in general, slow program starts, slow loadings, slow webpage rendering (all browsers I've tested, not only Firefox ) nearly no Multitasking capabilities of the CPU (loading a webpage and scrolling through another one is nearly impossible, again, all tested browsers).

It just feels so slow and not fluid at all. Look at an average smartphone of your choise, it can be the cheapest one, but mostly, it just feels faster in OS, Menus, navigation, handling... Pandora (OS) is far, far away from this and I don't know why, the "rough power" should be there, even in old CC Classic Pandoras. Angström was choosen because it is so small and agile (on paper) but even this seems to not help.

Even my old Windows 3.11 feelt better back then imho. And this was on a 40MHz 386 PC, can you imagine that today? FORTY MHz and Windows ran fluidly.

The speed of the menus is something that can be optimized more I guess, although OpenBox has pretty fast menus already. If you compare with your old Windows 3.11, keep in mind that 1) it did not have a Start menu and 2) it did not have to take into account that you can eject your "C:\Program Files" at all times and replace it with a completely different set of programs

Slow webpage rendering: this can be very true, depending on the website design and how well your wifi happens to work. With slow wifi, no amount of software optimization will help to make pages load faster. Websites have also become more complex in recent years, not just in terms of the amount of bandwidth they use, but also in terms of the amount of client-side computation that has to be done: neat CSS effects, JavaScript, etc. basically means that websites are more and more becoming interpreted programs than just data to be displayed. And website designers tend to assume that CPU power will not be a problem, because either you have a modern PC with a modern browser and there is no problem, or you have a crappy old PC with a crappy old browser that does not support those modern features so you fall back to some basic html version, or you have a phone and you get the mobile version of the website, etc. They don't tend to take the Pandora into account , and it is a bit of a one-of-a-kind device: if it were a Desktop PC, it would be at least 10 years old, but yet it is running the most recent versions of browsers!

It is also true that some of the Pandora software is taking a long time to load. For example PNDManager. To some extent this is unavoidable: if you want to load something large from a relatively slow (14MB/s) storage medium, it's going to take a while. Also, in the case of PNDManager it is actually doing a lot of stuff during loading: e.g. it checks all your PNDs to see if you installed or removed something since the last run. But on the other hand, this is something that could be improved, at least by giving more UI feedback about what is happening. For example, in my games, I try to display something as early as possible (first a notification, then a splash screen) so that it is immediately clear that you actually launched the game. I try to keep loading times low, but if it would be unavoidable to have some loading time, I would display a progress bar.

Multitasking is not a problem at all on the Pandora: I regularly alt-tab (actually ctrl-down) between e.g. LibreOffice, coding and other terminals, sysinfo, etc. It could be that web browsers are not very responsive when you're working with multiple tabs, but every now and then that even happens to me on quad-core desktop PCs with 8GB of RAM so I think the problem is not with the hardware.

 

[Gausen]

Pandora may be powerful but it also can be very SLOW, or to be more precise, the Software often feels slow, especialy the Desktop. Slow starttmenu, slow menus in general, slow program starts, slow loadings, slow webpage rendering (all browsers I've tested, not only Firefox ) nearly no Multitasking capabilities of the CPU (loading a webpage and scrolling through another one is nearly impossible, again, all tested browsers).

I have experienced this with web browsers. Placing the web browsers pnd's and their appdata folders in a fat32 partition seems to help (of course, swap space also helps). 

 

[ExquisiteCorpse]

Hey _wb_

With Notaz's improved SDL can you quickly test bubbman2? 

If that's running fullspeed with the improved SDL then it means PyGames will work a lot quicker. 

http://repo.openpandora.org/?page=detail&app=bubbman2

I don't know what speed it is supposed to run at, and I couldn't find an easy way to get an FPS count, but you can speed it up noticeably by doing the scaling in hardware instead of in software like it does now: in retrogamelib/display.py, set the scale to 1 and removes the line in update() that call pygame.transform.scale().

Then make a run script that sets up SDL to use notaz' tweaks, e.g. in this case it could be like this:


#!/bin/bash
export SDL_VIDEODRIVER=omapdss
export SDL_OMAP_LAYER_SIZE=scaled
./run_game.py
That seems to help quite a bit already. I don't know if it's enough to make this game "full speed". Python is inherently quite slow because it's interpreted, so during execution it's spending most of its time in a bytecode evaluation loop (which is basically a huge switch() in a while loop) and doing stuff like dynamic type checking.

Sorry to be a newb - could you advise how to do this in more broken down way? 

 

[sswam]

To be honest, the Pandora's CPU and RAM are much less powerful than the latest and greatest phones, maybe 25% to 50% as powerful.

Pandora is perhaps 2% as powerful as a new, powerful gaming PC or laptop.  These numbers are not correct, just my estimates.

However Pandora does perform very well for most tasks.  I have more complaints about performance with PCs than with my Pandora.

Slow web browsers... this is because they are very poorly written, and many web pages are over-complicated. My evidence: both firefox and chrome typically use up to a gigabyte of RAM on my PC, for a dozen or so web pages in tabs. It is ridiculous that they use so much memory.

I ported the browser Dillo, it gives very good performance.  It does not do javascript, and many pages look a bit messed up, but for most sensible browsing it works very well.

As for the menus being a bit slow, it's the same story.  Both the xfce menus and our pnd monitor are unnecessarily slow, and could be much improved with a little work.

Also, it's important to have fast SD cards, formatted correctly.

 

[fusion_power]

It is also true that some of the Pandora software is taking a long time to load. For example PNDManager. To some extent this is unavoidable: if you want to load something large from a relatively slow (14MB/s) storage medium, it's going to take a while. Also, in the case of PNDManager it is actually doing a lot of stuff during loading: e.g. it checks all your PNDs to see if you installed or removed something since the last run. But on the other hand, this is something that could be improved, at least by giving more UI feedback about what is happening. For example, in my games, I try to display something as early as possible (first a notification, then a splash screen) so that it is immediately clear that you actually launched the game. I try to keep loading times low, but if it would be unavoidable to have some loading time, I would display a progress bar.


Multitasking is not a problem at all on the Pandora: I regularly alt-tab (actually ctrl-down) between e.g. LibreOffice, coding and other terminals, sysinfo, etc. It could be that web browsers are not very responsive when you're working with multiple tabs, but every now and then that even happens to me on quad-core desktop PCs with 8GB of RAM so I think the problem is not with the hardware.

Why does PND Manager always loads and checks the whole Repo content? Shouldn't it be much much faster if the system only checks for last changes and does some kind of "incremental updates"? So it logs what have changed on Pandora and Repo and compares only that or so, should be only some KB of data files. At least I would do it this way if I could code. ^^""

I have experienced this with web browsers. Placing the web browsers pnd's and their appdata folders in a fat32 partition seems to help (of course, swap space also helps).

I only use FAT32 cards but it doesn't seem to speed up things that much.


The Pandora just needs more optimized mobile browsers, an up-to-date version of Mobile Firefox (wasn't the name "Fennec"?) and especialy finaly Opera mobile, it runs fast under Android on Pandora, imagine how fast a dedicated port could run. Maybe it's not open source but we could just ask Opera foundation, maybe they know a a solution.


At the moment it seems we only have slow PC Desktop Browsers that at least render webpages like they should be, or stripped strange thin exotic browsers that are fast but render the wabpages more like in "text only mode" and miss basic modern bwoser functions.


My CC Pandora is to slow for Android, so I would like to see more optimized dedicated mobile browsers for the Pandora. Until then I have to use Firefox because it renders the webpages like I want, means 100% like on the PC, no compromise, no errors (unlike Aurora), no missing plugins etc...

 

[Gausen]

I only use FAT32 cards but it doesn't seem to speed up things that much.

I was just mentioning my experience. For me using browsers on ext2, 3 or 4 partitions was noticeable slower than on fat32. Maybe others are having some unnecessary slowness too that can be reduced by the use of a fat32 partition for web browsers. I think that there are at least two non mutually exclusive roads, getting the best out of what we currently have and develop solutions better fitting the pandora system. My previous advice belongs to the first. Of course I agree with you that having a solution tailored for the Pandora will always be better.

 

[WizardStan]

Why does PND Manager always loads and checks the whole Repo content? Shouldn't it be much much faster if the system only checks for last changes and does some kind of "incremental updates"? So it logs what have changed on Pandora and Repo and compares only that or so, should be only some KB of data files. At least I would do it this way if I could code. ^^""

It's possible but it's not a trivial thing to do. There's a lot of decisions that need to be made, you don't want to start a system and then find out you've painted yourself into a corner on the standard. It was only recently, 3 weeks ago I think, that it was even determined to be theoretically possible. Someone still needs to code up a prototype to prove it is practically possible, Milkshake needs to come up with a storage system for easily tracking diffs between multiple versions (from one version to the next is easy, what's the best way to track differences between 5 different versions when you can request going from any one to any other?), bzar needs to implement the unpacking/patching system into PNDManager, and finally a good way of requesting a diff (if one exists) needs to be added to the repo standard in such a way that it can support many possible conditions. There's a lot of ways of doing any of these things, but which is the best? It's not as easy as it seems.

 

[thatgui]

Why does PND Manager always loads and checks the whole Repo content? Shouldn't it be much much faster if the system only checks for last changes and does some kind of "incremental updates"? So it logs what have changed on Pandora and Repo and compares only that or so, should be only some KB of data files. At least I would do it this way if I could code. ^^"" 

Are you sure PNDManager always loads the whole repo content ? At least in theory it shouldn't as the repo supports to only return you a list of changes since a certain date you define. But even if it does, the list is not that big that it should take that long. My guess is that indexing all the pnds on two SD-Cards is taking a lot of time - and I can only see any improvements there If you would better tie PndManager and the pnd deamon into each other. But that needs a lot of effort.

 

[fusion_power]

Are you sure PNDManager always loads the whole repo content ? At least in theory it shouldn't as the repo supports to only return you a list of changes since a certain date you define. But even if it does, the list is not that big that it should take that long. My guess is that indexing all the pnds on two SD-Cards is taking a lot of time - and I can only see any improvements there If you would better tie PndManager and the pnd deamon into each other. But that needs a lot of effort.Why does PND Manager always loads and checks the whole Repo content? Shouldn't it be much much faster if the system only checks for last changes and does some kind of "incremental updates"? So it logs what have changed on Pandora and Repo and compares only that or so, should be only some KB of data files. At least I would do it this way if I could code. ^^"" 

It loads all of the "lists" completly afaik but I can be wrong there. But like already mentioned, it may be just to complex to introduce an faster update behaviour of the repo. I like, that the repo just works, that's the more important part. ^^