Ram Poll.


Tenka said:
I like this fantasy.  Of course I imagine Mrs Cake to be a talking cake with arms and legs.
Mrs Cake is a well-known psychic with rather excellent precognition abilities. If she's being taken roughly down a dark alley, it's because she bloody well wants to be there.
D.
Nice catch.

... perhaps her seeming helplessness was just a ploy...

and her desperate cries but a seed of manipulation.
 
Let me guess... you have 8G of RAM on this machine ? :p
If I do the same, it will use nearly 4G of RAM... but hey I have 4G

Yes, actually. I've commented on this before as well but was told it doesn't do that anymore, I just hadn't gotten around to actually testing it.  I'd need to shut down, pull a stick, boot up again... so much hassle.  Hence why I'm curios as to how well the dev board handles it with only 2GB.
 
Is there a major difference in power consumption (let's say, 1/2 hour or greater in loss of battery life during average use) between 2GB and 4GB? In whatever decent armchair theory someone can provide.
 

During normal use (screen active, cpu somewhat active), I don't expect there to be a big difference in power consumption between 2GB RAM and 4GB.
During standby (lid closed, cpu idle), I expect a quite noticeable difference in power consumption, since RAM is pretty much the only thing that stays powered in that case (except maybe wifi/3G, which could also be power drains), and since it's not going to be low-power RAM and RAM power consumption is pretty much proportional to its size. Suppose 50% of the power consumption during standby is spent on RAM refreshes, then having twice as much RAM would mean adding 50% to the standby power consumption, which means that if it would be 9 days with 2GB RAM, it would be reduced to 6 days with 4GB RAM.

Unless of course there's a way to power down part of the RAM, and let the kernel do this automatically using some kind of heuristics (e.g. if it's idle for some time, it could sacrifice some caches and reorganize the memory layout in order to be able to temporarily power down half of the RAM). I have no idea if such a thing is possible and/or implemented in Linux.
 
I'm curious.  You're normally a relatively rational individual.  You know as well as anyone the difference in ram consumption between Linux on ARM and Windows on X86.  Why do YOU want 4GB?

Okay, I have to ask because I'm starting to feel I've missed something. I understand the difference in RAM consumption between Linux and Windows. They're separate OSs and do things differently. What, on the other hand, is the difference in memory consumption between ARM and x86? Most of the data in memory in most applications does not depend on what architecture it's being run on. Sure, the binary sizes could be different, but those are typically a miniscule part of the memory consumption in total. You could also argue that the platform-dependent types like int are smaller, but many a software defines those in specific bit sizes and for those that do not still typically have most of their data in platform-agnostic formats. Also you could argue on ARM platforms programs are typically optimized better because they tend to be more restricted in terms of resources, but for any given generic trivally recompiled C application without any platform-specific optimizations, how is the memory consumption in any meaningful way different?
I would guess that 64-bit architectures tend to consume more memory than 32-bit architectures because of those platform-dependent types, not so much the ints (they don't even need to be bigger) but mostly the size of pointers.

Another difference between ARM and x86 is that ARM does not have long double (extended precision floating point numbers, with 80 bits instead of the usual 64 bits for a normal double). Even though they only need to take 10 bytes, they will typically take 12 or 16 bytes for alignment reasons.

Also, ARM has 16-bit thumb instructions, which can make binaries quite a bit more compact. You're probably right that binary sizes don't matter that much anymore, at least not for application programs that manipulate large amounts of data (e.g. multimedia stuff). But it still matters, especially for the footprint of the base system and the non-graphical stuff.

But other than those things, I don't think there's a huge difference between ARM and x86. The difference between Linux and Windows though...
 
Yeah, I can understand small gains from stuff like that, but not any meaningful differences in most high-memory applications. I'd be interested to see identical configurations with a desktop environment and a few popular applications, games and such running to fill at least a couple of gigs of memory on one platform on both ARM and x86 to see how big the difference actually is. My guess is at maximum around 1-2%.
 
If you do that, though, aren't you also halving the available bus speed?  I.e. 2 memory controllers running flat out on 2GB will have 8.5GB/s of bus Vs 1 memory controller addressing 2GB running at 4.25GB/s.

So - to my understanding, if you're willing to accept the overall device running substantially slower, that may be an option.
 
For Standby you could Swap the Pages that are in the upper half of the Memory to Flash memory or to an zram Swapdisk, power down the upper half of the Memory and then go to Standby. But from the Datasheet it looks like the Chips also Need some Power in the "power down" mode.
 
I have made a video yesterday evening, but need time to upload it as I'm at work now.... I pegged out the CPU way before using up 2GB...  Had 10 PDFs open ~8200 pages total, 8 different documents in Libreoffice including presentations with sound, 16 browser tabs in Iceweasel on some heavy sites, HexChat IRC client talking to people, OpenTyrian running HQ3X and Blood running fullspeed on DOSBOX.  CPU was pretty bogged down, only used about 1.2GB of RAM. I don't perceive this as remotely a typical use case. 

VMs would take a bit of time to setup, plus I'm playing with getting Notaz's Starcraft and Diablo armhf ports working on the devboard at the moment and that is taking my attention.   
 
Last edited by a moderator:
Seems like a fine use test based on average users, but it's important to note that 4GB isn't therefore useless. Been awhile but I'm fairly sure I could come up with some recording/mixing uses in Audacity that would stress it the other way, i.e. short on RAM but plenty of cycles available.
 
Seems like a fine use test based on average users, but it's important to note that 4GB isn't therefore useless. Been awhile but I'm fairly sure I could come up with some recording/mixing uses in Audacity that would stress it the other way, i.e. short on RAM but plenty of cycles available.

Then you can use a zram Swap disk, which more or less Compresses the contents in the RAM so you have nearly double the Amount of RAM, but its very CPU intensive.
 
I have made a video yesterday evening, but need time to upload it as I'm at work now.... I pegged out the CPU way before using up 2GB...  Had 10 PDFs open ~8200 pages total, 8 different documents in Libreoffice including presentations with sound, 16 browser tabs in Iceweasel on some heavy sites, HexChat IRC client talking to people, OpenTyrian running HQ3X and Blood running fullspeed on DOSBOX.  CPU was pretty bogged down, only used about 1.2GB of RAM. I don't perceive this as remotely a typical use case. 

VMs would take a bit of time to setup, plus I'm playing with getting Notaz's Starcraft and Diablo armhf ports working on the devboard at the moment and that is taking my attention.   

Wow - looking forward to the video.  Hopefully this will let reality catch up to the RAM hype.  I'm glad you have that dev board.  It has helped a lot with getting an idea of how the Pyra will perform.
 
Starcraft port?? :blink:

How is it running?

The Pandora version works great... The armhf version I got from Notaz, I need to patch some gcc compiler issues with the ARM version of wine to get it working on the devboard. Another thing I need the time to play with.
 
Last edited by a moderator:
I have made a video yesterday evening, but need time to upload it as I'm at work now.... I pegged out the CPU way before using up 2GB...  Had 10 PDFs open ~8200 pages total, 8 different documents in Libreoffice including presentations with sound, 16 browser tabs in Iceweasel on some heavy sites, HexChat IRC client talking to people, OpenTyrian running HQ3X and Blood running fullspeed on DOSBOX.  CPU was pretty bogged down, only used about 1.2GB of RAM. I don't perceive this as remotely a typical use case. VMs would take a bit of time to setup, plus I'm playing with getting Notaz's Starcraft and Diablo armhf ports working on the devboard at the moment and that is taking my attention.   

Wow - looking forward to the video.  Hopefully this will let reality catch up to the RAM hype.  I'm glad you have that dev board.  It has helped a lot with getting an idea of how the Pyra will perform.
I'm going to remake the video tomorrow (IE today as it's past midnight here, after I get some sleep). The video was a poorly done, I was holding my phone and trying to type and navigate, Watching it on a monitor made me motion sick from all the swaying and it went out of focus a bit. I also didn't do as good of a job showing every program running, mostly showed just the task list and a bit of the games... I can do better.
 
Last edited by a moderator:
I am in the 4GB is nicer camp ..there is no substitue for RAM when you really need it, like editing 24bit sound files, loading large datasets from simulations - I am not convinced by tests on the devboards multiplying the things you do on the pandora, you gotta think about new things that are inconceivable with the pandora

 I would be completely ok with 2GB though because I can see the battery life drawbacks...
(don't care about cost so much)
 
 
Well if you guys want to see me rambling on for almost 20 minutes opening programs here you go: 

EDIT: Sorry for the poor video quality, I should get an HDMI recorder or something.
EDIT2: And the rambling...
 
Last edited by a moderator:
There is. 4 chips is the minimum for full bandwidth.

EDIT: Unless you're talking about poulating one of the channels with higher density and the other with lower density. That may work if the controller supports it, but it could cause performance issues if most of the accesses goes to one of the channels.
 
Last edited by a moderator:
Back
Top