1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Dismiss Notice

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

Discussion in 'Pyra News' started by EvilDragon, Aug 13, 2017.

  1. sebt3

    sebt3 homebrew player (P. & C.)

    Joined:
    Sep 9, 2008
    Messages:
    4,678
    Location:
    France
    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
     
    spud42 and Swordfish II like this.
  2. klapse

    klapse Central Scrutinizer

    Joined:
    Aug 30, 2012
    Messages:
    1,638
    Location:
    Germany
    That's like setting fire to your house and claiming you need lots of champagne to douse it.
     
    rygD and tarator like this.
  3. tarator

    tarator Member

    Joined:
    Jun 4, 2016
    Messages:
    114
    Location:
    Vienna
    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.
     
  4. Mr_Loon

    Mr_Loon Can't Remember

    Joined:
    Aug 30, 2010
    Messages:
    2,297
    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.

    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 :
    @EvilDragon : Is this different Ram Chip the mobile / low voltage version as mentioned by @pimaster ?
     
    rygD, lukey and ClockworkCoder like this.
  5. slaeshjag

    slaeshjag ¯\_(ツ)_/¯

    Joined:
    Apr 8, 2010
    Messages:
    2,673
    Location:
    ~Stockholm, Sweden
    No, it was ED misreading the chip number. It was the DDR3L version they got.
     
    sebt3 likes this.
  6. sebt3

    sebt3 homebrew player (P. & C.)

    Joined:
    Sep 9, 2008
    Messages:
    4,678
    Location:
    France
    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
     
    tarator and Swordfish II like this.
  7. tarator

    tarator Member

    Joined:
    Jun 4, 2016
    Messages:
    114
    Location:
    Vienna
    @sebt3 makes sense... Maybe I will try to run the programm on a raspberry Pi. I'm getting curious how big the difference is...
     
  8. Letalis Sonus

    Letalis Sonus Very Active Member

    Joined:
    Mar 5, 2009
    Messages:
    886
    ...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.
     
    Haraldur and tarator like this.
  9. Pyramancer

    Pyramancer Active Member

    Joined:
    Feb 4, 2017
    Messages:
    130
    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.
     
  10. Grench

    Grench Forum Addict!

    Joined:
    Oct 3, 2008
    Messages:
    5,198
    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?
     
    rygD likes this.
  11. tarator

    tarator Member

    Joined:
    Jun 4, 2016
    Messages:
    114
    Location:
    Vienna
    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
    
    
     
  12. pimaster

    pimaster Still Fresh

    Joined:
    Oct 19, 2015
    Messages:
    16
    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.
     
    Swordfish II and Pyramancer like this.

Share This Page

Loading...