UKBouldering.com

RAM (Read 11564 times)

slackline

Offline
  • *****
  • forum hero
  • Posts: 18863
  • Karma: +633/-26
    • Sheffield Boulder
#25 Re: RAM
September 15, 2011, 08:47:33 am
Very roughly £1/Gb at eBuyer give or take a bit (e.g. 96Gb for £82.99 (although not the fastest transfer rates))

Johnny Brown

Offline
  • *****
  • forum hero
  • Posts: 11481
  • Karma: +703/-22
#26 Re: RAM
September 20, 2011, 05:11:17 pm
Quote
do you need the extra RAM? probably better putting money towards ssd or new computer o recon

Well I've running Task Manager for the last few days to see if the RAM really is the limiting factor.
Been like this for the last two hours; a fucking joke. New RAM has been ordered.






dave

  • Guest
#27 Re: RAM
September 20, 2011, 05:16:55 pm
You sure you not got weird trojan shit chewing shit up? That ram usage looks crazy.

slackline

Offline
  • *****
  • forum hero
  • Posts: 18863
  • Karma: +633/-26
    • Sheffield Boulder
#28 Re: RAM
September 20, 2011, 05:32:02 pm
I don't know about M$, but just because RAM is showing as being used doesn't mean its a limiting factor.

This is the situation under Linux/Android and I would be amazed if M$ isn't different....

Quote from: slackline
Android is running a Linux kernel and the way Linux handles memory is to allow a program to have its memory space whilst its running, when the program ends it still sits in memory using up the space it used, so it may appear that you have no memory left and you think you'll improve performance by killing some of those programs that are sitting in RAM using it up but not being used by you.  But Linux has been designed to do this on purpose, if you restart a program, e.g. a web-browser, its already in memory and starts up quicker.  But what about when a new program is started and there isn't enough free RAM I hear you ask, well thats not a problem, because at that point the kernel glances at whats in RAM, checks to see whats actually being used and kicks out that program which is sat there and not being used, freeing up enough RAM for the new program.

 Thus you don't actually need to waste your time actively killing programs you've exited just to free up RAM, because it won't make any difference to performance as the kernel is very good at managing RAM.

 My Linux systems (one with 6Gb and one with 8Gb RAM) regularly have close to 0% of RAM free, but I never experience any delay/lag in opening up new programs or with general usability.

 And to get to the crux, stuff sat in memory doesn't use any power, stuff using the CPU will do.  If you've apps running that you don't want stop them from starting up in the first place, otherwise you'll be forever trying to kill them. (See under Settings somewhere, kind of depends on which app, some have settings within the app, I found ShopSavvy always started up on its own and sat there, never use it so deleted it).

 You can read an article on this specifically about Android task managers here.

To start trouble shooting look at CPU/RAM usage from a fresh boot (not suspend or hibernate), if its still high then I'd do what dave says and look at which processes are actually using the RAM.

(More fundamentally though I can't see a scale on the x-axis to indicate whether that is usage over the last few minutes or the full few days you've been monitoring things, the up-time is quoted but I don't see whether this is reflected in the graph, could just be the last few minutes for all I know, but I'm guessing you've been glancing at this perodically over the past few days :shrug:  :geek:).

Jim

Offline
  • *****
  • Trusted Users
  • forum hero
  • Mostly Injured
  • Posts: 8629
  • Karma: +234/-18
  • Pregnant Horse
    • Bouldering POI's for tomtom
#29 Re: RAM
September 20, 2011, 05:37:43 pm
click on the applications tab in task manager and sort by memory usage to see whats eating it all up.
New Ram might help the situation but it won't solve your problem

Johnny Brown

Offline
  • *****
  • forum hero
  • Posts: 11481
  • Karma: +703/-22
#30 Re: RAM
September 20, 2011, 05:44:41 pm
Nothing wierd going on, Photoshop is using 2.5GB, Lightroom 1Gb, with Firefox, Thunderbird and OS fighting it out for the rest.

Quote
New Ram might help the situation but it won't solve your problem

Why not? I'm guessing most of you aren't flipping big files between LR and PS like I am. PS is famous for chewing RAM, as soon as I exit it things are fine, and RAM useage drops down to 1.3GB/ 32%.

Only annoying thing is a lot of the time LR will export a big file, I'll downsize it in PS significantly, but purging PS cache doesn't seem to do owt and I have to exit PS to free up RAM.

Lund

Offline
  • ***
  • obsessive maniac
  • Posts: 442
  • Karma: +85/-12
#31 Re: RAM
September 20, 2011, 06:12:55 pm
Nothing wierd going on, Photoshop is using 2.5GB, Lightroom 1Gb, with Firefox, Thunderbird and OS fighting it out for the rest.

Quote
New Ram might help the situation but it won't solve your problem

Why not? I'm guessing most of you aren't flipping big files between LR and PS like I am. PS is famous for chewing RAM, as soon as I exit it things are fine, and RAM useage drops down to 1.3GB/ 32%.

Only annoying thing is a lot of the time LR will export a big file, I'll downsize it in PS significantly, but purging PS cache doesn't seem to do owt and I have to exit PS to free up RAM.

The linux post is irrelevant.

You need more RAM.

Note that a lot of applications do what PS does: once they've grabbed memory, they won't release it back - just hang on to it so they don't need to compete with other stuff to get it back from the OS if they do want it.

tomtom

Offline
  • *****
  • forum hero
  • Posts: 20293
  • Karma: +643/-11
#32 Re: RAM
September 20, 2011, 06:42:07 pm
Photoshop must be written by a room of lazy bastard slugs on valium then... I code in .net and it manages memory really well.. I can write some code 'reserving' a 100 million element array and the program will be titchy memory wise until you load up the array and sizes memory according to how much of this array I'm using... So sounds like PS is written without any dynamic memory allocation, which is in one word Turd.

Unless youre keeping huoouge images loaded up all the time.. Maybe it's a case of bad porting from mac many moons ago?

Don't think that's any help.. Sorry..

Jim

Offline
  • *****
  • Trusted Users
  • forum hero
  • Mostly Injured
  • Posts: 8629
  • Karma: +234/-18
  • Pregnant Horse
    • Bouldering POI's for tomtom
#33 Re: RAM
September 20, 2011, 07:11:47 pm
so photoshop & lightroom constantly uses 3.5 gig when open even when not doing anything?
in that case what tomtom said, piss-poor programming, either that or you've got your computer set up badly.
speaking of valium, i'm just off to have some more

Johnny Brown

Offline
  • *****
  • forum hero
  • Posts: 11481
  • Karma: +703/-22
#34 Re: RAM
September 20, 2011, 07:45:43 pm
Its a case of massive files I think, that's all.

Tom de Gay

Offline
  • ***
  • stalker
  • Posts: 258
  • Karma: +40/-0
#35 Re: RAM
September 20, 2011, 10:44:43 pm
That RAM usage seems entirely normal for Photoshop/Lightroom combo (with big files). With 8GB installed Photoshop sometimes gets up to 5GB. It does free it up again though.


The other thing which made things run a little more smoothly was the disallow flate compression plugin - no more epic saves!


Edit: quitting browser, mail and non-essential background applications makes a difference too.

Jim

Offline
  • *****
  • Trusted Users
  • forum hero
  • Mostly Injured
  • Posts: 8629
  • Karma: +234/-18
  • Pregnant Horse
    • Bouldering POI's for tomtom

slackline

Offline
  • *****
  • forum hero
  • Posts: 18863
  • Karma: +633/-26
    • Sheffield Boulder
#37 Re: RAM
September 20, 2011, 11:16:01 pm

The linux post is irrelevant.

You need more RAM.

Note that a lot of applications do what PS does: once they've grabbed memory, they won't release it back - just hang on to it so they don't need to compete with other stuff to get it back from the OS if they do want it.

Is this true even when applications have been shut down?

How is memory managed under Win7?

You can't possibly have applications grabbing memory and not releasing it in some fashion when the program is formally exited.  It would seem sensible that they either release it immediately by vacating the memory address or sit there waiting to be recalled (affording marginally faster start up times as is the case under *NIX, but being scrapped if there isn't enough free RAM for a new application).  If they hold onto it all the the time and never release it then RAM would get filled up pretty damn quickly, and people would have to reboot regularly non?

Had a cursory search but neither M$ pages nor Wikipedia are enlightening in this regard (EDIT : Found this but it still doesn't really answer my question, but may be useful to check out alternative ways of measuring RAM usage than the one thats been tried so far).

It does sound like PS isn't very efficient in its use of RAM though.
« Last Edit: September 20, 2011, 11:45:40 pm by slack---line »

tomtom

Offline
  • *****
  • forum hero
  • Posts: 20293
  • Karma: +643/-11
#38 Re: RAM
September 21, 2011, 07:33:55 am
Iirc, (it's 8years since I researched this) then how a program manages memory is down it the language coded in and how it is coded rather than the OS etc..

In normal C and C++ memory is reserved for the size of the variables you declare when the prig starts to run - you then have to use malloc or similar commands (they're grim to use iirc) to dynamcically assign the memory from inside the program duping it's operation.
The .net languages are slower and have other performance overheads, but deal with this memory management automatically - dynamic memory allocation - which can be a real advantage. Anyway, I'm no pro programmer so happy to be corrected but that's my understanding..

slackline

Offline
  • *****
  • forum hero
  • Posts: 18863
  • Karma: +633/-26
    • Sheffield Boulder
#39 Re: RAM
September 21, 2011, 07:38:52 am
I've a vague recollection of that stuff from when I did some rudimentary C programming (and also remember malloc being a pain to understand).

But regardless the OS will still have to handle which programs are using which bits of memory and when to invoke swap(/page-file under M$) if physical RAM requirements are exceeded, and thats what I'm hazy about under Win7 (and indeed other incarnations of Win).

tomtom

Offline
  • *****
  • forum hero
  • Posts: 20293
  • Karma: +643/-11
#40 Re: RAM
September 21, 2011, 07:42:27 am
I've a vague recollection of that stuff from when I did some rudimentary C programming (and also remember malloc being a pain to understand).

But regardless the OS will still have to handle which programs are using which bits of memory and when to invoke swap(/page-file under M$) if physical RAM requirements are exceeded, and thats what I'm hazy about under Win7 (and indeed other incarnations of Win).

Hmm you have a point there, from memory if unix apps were too large it would swap a load out to the swap file which would make it bloody slow but it wouldn't crash.. N idea about ms..

slackline

Offline
  • *****
  • forum hero
  • Posts: 18863
  • Karma: +633/-26
    • Sheffield Boulder
#41 Re: RAM
September 21, 2011, 07:47:22 am
I've a vague recollection of that stuff from when I did some rudimentary C programming (and also remember malloc being a pain to understand).

But regardless the OS will still have to handle which programs are using which bits of memory and when to invoke swap(/page-file under M$) if physical RAM requirements are exceeded, and thats what I'm hazy about under Win7 (and indeed other incarnations of Win).

Hmm you have a point there, from memory if unix apps were too large it would swap a load out to the swap file which would make it bloody slow but it wouldn't crash.. N idea about ms..

Thats what page-file is for (i.e. paging)  They're essentially the same concept except under *NIX it tends to be a separate partition called swap, whilst under M$ its a file on the hard-drive (often hidden).

mr__j5

Offline
  • **
  • menacing presence
  • Peter J
  • Posts: 246
  • Karma: +9/-0
  • tall, bendy and weak
#42 Re: RAM
September 21, 2011, 10:52:30 am
You can see from the posted image that the OS only has 482MB in cached memory and it normally only uses this for caching file I/O.

There is then a generally fixed amount of memory used by the OS (kernel) to run stuff, most of that these days is for graphics resources. After that, it is all down to what the applications ask for and whether they give it back in a hurry.

But yes, all OS's use paging to a swap file to avoid running out of memory, but you never want to get to this state as your machine will be running so much slower by then.

and yes, memory allocation in C/C++ (native) applications is a manual process that requires you to hand it back explicitly when done where as in .NET there is a garbage collector that detects when you have finished with memory and takes it back off you, making it much harder to walking off with GBs of memory.

Lund

Offline
  • ***
  • obsessive maniac
  • Posts: 442
  • Karma: +85/-12
#43 Re: RAM
September 21, 2011, 12:45:27 pm
.NET is a special case yes - as is Java.  The programs you write with these run within a framework - the JDK, or the massively annoying .NET framework you had to download updates for every ten seconds with win 2K.  The framework manages your heap for you, and does "garbage collection".

What that means in a nutshell is that the framework is configured to have a minimum and maximum heap size.  These can be the same.  When it starts, it grabs a "heap" of that size from the operating system - and this will be what appears as the memory usage for the OS.  Say 1Gb.  The minimum will be reserved from the OS when it starts up.

When the program actually needs to use that, it will try to grab something from the framework (not the OS), use it etc., and then when it's done the framework marks it as unused.  It'll then free it up - but not necessarily back to the OS, just ready to be used again by the program running within the framework.

If you need more than the 1Gb, then the framework will progressively grab more up the limit... and when the limit is hit your program will crash.  Even though you might still have plenty left on your machine.

The advantage of this approach is simply the management: it makes it harder to write programs that leak memory.  Remember early versions of firefox?  They had a memory leak where the program's memory footprint just got bigger and bigger and bigger slowly.  This is a memory leak.

For unmanaged heaps, you can do either.  You can either just grab memory when you need it and release it back to the operating system, and this is what small, simple apps will do.

Things like photoshop will do something inbetween.  They'll grab a huge chunk at the start of day, and then apportion bits of it internally when they need it.  There isn't a framework per se that manages it - the programmer writes that function themselves as they see fit.  They do this because, basically, it means that they can get large contiguous chunks of memory by grabbing it in one go - and manage their own memory better than the OS can.  It also makes it easier to write portable applications with varying memory management requirements.

As to the difference between swap and not swap, and cached and the like... this is a big subject.  Fundamentally though, 4Gb is a LOT of memory.  If you had to page in and out even a quarter of that, although your application won't run out of memory, it'll run like a dog as moving stuff between actual real memory where the CPU can get at it and the disk is slow.  Even with an SSD.

Fundamentally, everything you do with your computer will be gated, performance wise, by one of three things.
- CPU speed
- memory (either total usage, or the way it's used and how fast the CPU can get at it)
- disk access.

For photoshop, it seems like the total memory footprint is the problem.

 

SimplePortal 2.3.7 © 2008-2024, SimplePortal