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


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.
 
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.

I have 48GB of RAM on my home desktop computer running Debian Stretch. It is fairly common for it to show 30-40GB RAM in use during simple file copies (running backups for example). RAM used on a modern Linux or Windows desktop does NOT equal the RAM required for the applications running. Both use any and all available RAM for caching - storage included.

I am not discounting that your 64bit Linux desktop is using that much RAM during the operations you are performing.

However, if you strip the system down to 32bit & 2GB, then what does it do? Does it still run? Is it fluid enough to use?
 
I have 48GB of RAM on my home desktop computer running Debian Stretch. It is fairly common for it to show 30-40GB RAM in use during simple file copies (running backups for example). RAM used on a modern Linux or Windows desktop does NOT equal the RAM required for the applications running. Both use any and all available RAM for caching - storage included.

I am not discounting that your 64bit Linux desktop is using that much RAM during the operations you are performing.

However, if you strip the system down to 32bit & 2GB, then what does it do? Does it still run? Is it fluid enough to use?

I'm aware of the fact, that linux always fills the ram with buffer and caching. But here is my output of `free -h`. As you can see, there is not much left for buffer and cache...
Code:
              gesamt       benutzt     frei      gemns.  Puffer/Cache verfügbar
Speicher:        3,7G        3,1G        127M        111M        517M        233M
Auslagerungsspeicher:        3,8G        607M        3,2G
 
No, it was ED misreading the chip number. It was the DDR3L version they got.

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.

Well. That's a problem with jumping in and out of IRC. You don't get the whole picture. Sorry for getting anyone's hopes up. Huge thanks to those that did get the whole story.
 
Back
Top