Open... and close... and open...


The Pyra doesn't have a 64 bit CPU.
Right, but I was saying that there was a 64-bit version of Minecraft, so if a 64-bit CPU comes out eventually for the Pyra, it'd be fully possible for it to run the 64-bit version of Minecraft.

(Maybe a Cortex-A57? Granted, we'd probably have to move away from OMAP for those... there hasn't been a new OMAP product since 2013. With Tegra out, Atom and Snapdragon are the two most likely candidates, but obviously Atom isn't ARM... at this point, an updated CPU board is sounding more like it'd be a full-on system rewrite to support it, ack.)
 
Right, but I was saying that there was a 64-bit version of Minecraft, so if a 64-bit CPU comes out eventually for the Pyra, it'd be fully possible for it to run the 64-bit version of Minecraft.
Yes, but that has no bearing on the current discussion of whether 4GB in the Pyra would benefit Minecraft or not.
 
Yes, but that has no bearing on the current discussion of whether 4GB in the Pyra would benefit Minecraft or not.
Yes, and that's the trickier question to answer.

Cortex-A15s do support LPAE. Virtual address space, however, remains 32-bit. So while it can use more RAM than 4 GB, an individual process still caps at 4 GB of space.

My guess would be that 3-3.5 GB would thus be the practical limit it could use, and possibly less than that, owing to the Pyra's 4 GB of RAM on 4 GB models - you'd have to swap all other programs to a swapfile if you wanted to use the full 4 GB, and even then you'd end up a bit short due to the OS's needs.

Worse comes to worse, Minecraft will be limited to 2 GB. Granted, on a 2 GB Pyra, that'd be unattainable for the same reason 4 GB on a 4 GB Pyra won't work - the OS needs some RAM and so do other running programs.

Either way, it's something to keep an eye on for if a future Pyra CPU comes with a 64-bit CPU, especially if it comes with 6-8 GB of RAM.
 
Last edited:
(Maybe a Cortex-A57? Granted, we'd probably have to move away from OMAP for those... there hasn't been a new OMAP product since 2013. With Tegra out, Atom and Snapdragon are the two most likely candidates, but obviously Atom isn't ARM... at this point, an updated CPU board is sounding more like it'd be a full-on system rewrite to support it, ack.)
I agree, and over time I have seen several reasons why I feel ARM was the right choice. A couple that really bother me personally are this feeling I get that we wouldn't get optimized software because people would say why bother (I hope this is all in my head), and that it would be compared even more than it currently is to x86 devices with a similar form factor. For me the Pyra is greater than the specs and being a clamshell with a keyboard, just as the Pandora is, and the DOS based palmtops have been for their hardcore fans (because they still have a place in the world today, and it is on the frontlines, not sitting in the back of a drawer).

Anyway, before my passion takes me more away from my point, the more I think about it the less likely an upgrade board seems, although I am still hoping that whatever company it was that said they would only allow their SoCs to be used if a company they picked designs the product will go for the idea that all they are designing is the CPU board for a pre-existing device as an upgrade. As long as it would be an improvement, I might accept it being extremely underclocked (and with less than half the maximum RAM it can support :P) for practical reasons. We will see. Maybe things will change and work out for us when the time comes. Or maybe the main board will need to be redesigned so that we can use the next generation of the RaspberryPi or whatever.
 
As a quiet member:
When the preorders first when up (https://pyra-handheld.com/boards/th...d-previously-named-starts-in-two-hours.77328/) in May 2016, we were told:
"As many were asking for a 4GB unit, we added that one as well - for 30 EUR more.
However, we do not yet know if that works well, so in case it doesn't, you will get a 2GB unit (and of course won't have to pay the 30 EUR more in the end)."​
It is interesting that we have moved to a point where the 4GB is so close to working that abandoning feels bad. Sunk cost is a terrible thing to deal with.
If I end up with 2GB unit by Christmas, I'd be happy. If a 4GB board is available 6-12 months after that. I'd be upgrading.
I would be getting what I signed up for.

Now, I love hanging out on the IRC channel.
I was so amused when I got to read that the wrong memory chip had been used in the 4GB samples. We got the usual version, not the mobile/low voltage version. There was checking that needed to be done to find out if we ordered the wrong model number or whether the wrong one was delivered. I was surprised that a post wasn't made to update the crowd regarding the issue. I hope that I'm not breaking any unwritten (or written) guideline by forwarding this information. I hope that I don't take any thunder away from an ED post.

I'm still behind ED and his choices. Huge respect for his patience and management of the hoard. I think we all share his frustration that it would be nice to have it all done already so we can start working on the software en masse.
 
I hope no one gets upset by me being off-topic:
How has the opening and closing been going? I am still available to help out with that testing if a prototype gets sent my way. :P
 
If the boards have to be reduced to 2GB, I don't know if I'd be still willing to keep up with the pre-order to be completely honest.
As I would be paying a premium for postage and the device that would be kinda underpowered to something like a GPD-Win which is quite a bit cheaper.
The absolute main reason I pre-ordered the pyra was for 3G web browsing which takes quite a chunk of the ram out.

I wouldn't mind the extra voltage for the extra 2GB but hopefully there will be a better solution.

Ah well, that's Windows for you.

Here is a screenshot of my current desktop:

Screenshot.jpg

As you can see, it runs Plasma (KDE5), FreeCad, Gimp, Evolution Mail (with calendar, task and contacts sync running), MoneyPlex, some smaller tools (like Kate, Speedcrunch, Konsole), and Nextcloud (can't be seen in the picture though).
All at the same time. And the memory usage is still under 2GB RAM, and that's a 1920x1080-resolution.

Plasma alone uses 600MB of RAM, Evolution about 200MB (it really eats a lot of memory).
The browser (with all the tabs you can see here) uses around 300MB of RAM.

This is certainly a lot more that I ever want to run on a Pyra at the same time (FreeCAD and Gimp...? :))

If I switched to something like LXDE on my laptop, the full memory usage would be around 1.3GB for all of that.

So yeah... 2GB is plenty, as long as you don't use anything that simply hogs the memory for some reason :)

I still want to get the 4GB Pyra working though :D
 
Nope it was not you. This person we later found out hasn't preordered.. Come to think of it I havent seen them around in a while.
That was a guy called m@t, I think he got banned
Ah well, that's Windows for you.

Here is a screenshot of my current desktop:

As you can see, it runs Plasma (KDE5), FreeCad, Gimp, Evolution Mail (with calendar, task and contacts sync running), MoneyPlex, some smaller tools (like Kate, Speedcrunch, Konsole), and Nextcloud (can't be seen in the picture though).
All at the same time. And the memory usage is still under 2GB RAM, and that's a 1920x1080-resolution.

Plasma alone uses 600MB of RAM, Evolution about 200MB (it really eats a lot of memory).
The browser (with all the tabs you can see here) uses around 300MB of RAM.

This is certainly a lot more that I ever want to run on a Pyra at the same time (FreeCAD and Gimp...? :))

If I switched to something like LXDE on my laptop, the full memory usage would be around 1.3GB for all of that.

So yeah... 2GB is plenty, as long as you don't use anything that simply hogs the memory for some reason :)

I still want to get the 4GB Pyra working though :D
Oh wow, maybe I should use Linux more!
 
This is my desktop PC running Eclipse and starting a Java-Software for Debugging.
Firefox is running with only some essential Tabs.
This is on Kubuntu 16.04.

As you can see it already needs more than 2GB of RAM right after starting. The memory usage will get up while Programming/Debugging.
So: This is a real-life example where 2GB of RAM is clearly not sufficient....

This is my every-day setup on my working-laptop.
Of course I don't plan to do all my programming work on the Pyra, but it would be nice if it's at least possible in case I need to fix something, while I'm on holidays...

download
 
As you can see it already needs more than 2GB of RAM right after starting. The memory usage will get up while Programming/Debugging.
So: This is a real-life example where 2GB of RAM is clearly not sufficient....
So you compare x86-64 memory usage to armhf (32) and expect the same behaviour :D
Also screen size make a huge difference in memory usage. FullHD double the memory consomption compared to 720p.
But yeah 4GB can be nice for that kind of usage though
 
So you compare x86-64 memory usage to armhf (32) and expect the same behaviour :D
Also screen size make a huge difference in memory usage. FullHD double the memory consomption compared to 720p.
But yeah 4GB can be nice for that kind of usage though

Yes I compare x86-64 and armhf. You're right, that the memory footprint might be different on these architectures. But I think it will be similar...
Screen size and using another Desktop-Environment might give me back 300MB of RAM. Java-Development is not really affected by this. The running Java-Programm has no IDE.

I will also be happy 2GB but if possible I would prefer the 4GB version for stated reasons.
 
Yes inadequately researched and ill-conceived. Seems to have been offered as a result of irrational community pressures before it could be properly researched.

Doubt all you want. Read the history and the piles of posts from @Mr_Loon pushing for it
This distinction may be a little subtle for some (one?) but what I was (and still am) pushing for was for a 2GB Pyra and a 4GB to be tested side by side to see how much benefit is gained from the additional 2GB of Ram. So when people pre ordered a Pyra they would know whether the extra cost of a 4GB unit was worthwhile expenditure.

I fully admit I don't know if 4GB is necessary or worthwhile, without such testing i.e. knowing swap performance / impact on battery life etc. it's very hard to say.

What I also know is that logic tells me that under my personal usage scenario for a Pyra (running an Android VM with 1GB dedicated Ram & Multi Tab Browsing / Multi Layer high resolution image editing) it would seem likely that 4GB would provide some benefits.

Now, I love hanging out on the IRC channel.
I was so amused when I got to read that the wrong memory chip had been used in the 4GB samples. We got the usual version, not the mobile/low voltage version. There was checking that needed to be done to find out if we ordered the wrong model number or whether the wrong one was delivered. I was surprised that a post wasn't made to update the crowd regarding the issue. I hope that I'm not breaking any unwritten (or written) guideline by forwarding this information. I hope that I don't take any thunder away from an ED post.
Sounds like a test with a board running the mobile / low voltage version would be a sensible way to proceed.

In the out of ideas for news titles post ED mentions :
We already ordered samples of a different RAM Chip (also 4GB in total size) by a different manufacturer.
We'll populate one PCB with those. If that chip works, we can pretty much rule out 1.

@EvilDragon : Is this different Ram Chip the mobile / low voltage version as mentioned by @pimaster ?
 
But I think it will be similar...
Err nope, not at all. A 64b OS have all its instructions coded on 64b while a 32b OS have all it's instructions coded on 32b. That mean the binary size on 32b is half the size of on 64b systems (not exactly but you now have an idea). Beside, Pointers and some other datatypes doesnt have the same size. So the same code compiled as 32b and as 64b will not consume the same memory... at all... then you have the difference between the 2 architectures where the compiler does not produce that same optimisations (SSE vs NEON etc).

Then memory hog process like a J2EE instance or a browser on facebook will be memory hog no matter the plateform
 
@sebt3 makes sense... Maybe I will try to run the programm on a raspberry Pi. I'm getting curious how big the difference is...
 
A 64b OS have all its instructions coded on 64b while a 32b OS have all it's instructions coded on 32b.
...except that it's hard to find a fixed length ISA nowadays (and even on those a 64bit architecture does not have to use 64bit instructions), x86 always used variable length instructions. And you don't stuff your RAM full of assembly, you make it burst with data.

The biggest difference can be found within the software itself, it all starts with compile time switches. A lot of heavy duty programs like Firefox recognize ARM => embedded system => low ressources and avoid e.g. memory-heavy optimizations and use entirely different codepaths for other highly optimized parts.
 
I was so amused when I got to read that the wrong memory chip had been used in the 4GB samples. We got the usual version, not the mobile/low voltage version. There was checking that needed to be done to find out if we ordered the wrong model number or whether the wrong one was delivered. I was surprised that a post wasn't made to update the crowd regarding the issue.

Right, but it turned out to be a false alarm. They did have the memory chip they intended to have, there was just a momentary confusion. It is inevitable really, when double checking everything to nail down a problem, that occasionally you make a mistake and think you found a dicrepancy when in fact there was none. Then you check again and find your mistake, and then proceed with your search for the real problem.
 
Back
Top