Added Memory=difference in speed
Hello,
I just upgraded my system with an extra 1 Gig of RAM. Now I have 1.5 Gig total. I just thought someone may be interested in the speed difference. My main system is: ECS KT-600A motherboard. AMD Sempron 2800 Kingston Value RAM PC3200 160 Gig Seagate HD 512 Meg Swap Nvidia BFG 256 Meg video Card Debian Sarge 2.4.27-2-k7 kernel My curiosity started after I ran a couple of tests against a dual processor Dell I recently purchased: Precision 410 2-750Mhz PIII 1 Gig RAM 27 Gig HD 1 Gig Swap Old ATI video Card (16 or 32 meg RAM) Debian Sarge 2.4.X smp kernel Live CD eLive 0.3 Just to boot to the first selection screen Dell 1:23.12 2800 1.5 Gig or 512 Meg same results 1:08.47 For firefox to start: Dell 23.16 sec 2800 1.5 Gig or 512 Meg same results 20.0 sec FreeBSIE 1.1 boot to first selection screen Dell 1:17.40 2800 1.5 Gig or 512 Meg same results 1:44.60 Firefox Dell 17.84 sec 2800 512 Meg 13.00 sec Didn't try with 1.5 Gig The main thing I do with my machine that takes time is using Gimp on maps and editing videos. I haven't had time to do any tests on videos yet. I'm still trying to learn the Linux way for videos. To open a 12.7 Meg map file with Gimp Dell 43.69 sec 2800 512 Meg 2:44.38 2800 1.5 Gig 23 seconds To scale that image to 10% Dell 28.65 sec 2800 512 Meg 1:37.44 2800 1.5 Gig 59.75 seconds To open a 24.9 Meg map with Gimp 2800 512 Meg 6:59.05 2800 1.5 Gig 1:07.60 I didn't try this on the Dell At least as important as the difference in speed in opening the maps is the delay. Even after they open to select something or change something causes a delay. I have not measured that delay but it is significantly shorter with the extra RAM. Anyway I though maybe someone would be interested. I can't believe how much snappier the 2800 feels with 1.5 Gig compared to 512 Meg RAM. I still can't believe how well that dual cpu does against a 2 Ghz chip (AMD 2800). Too bad it maxes out at 1 Gig RAM. Makes me drool over the dual core chips though. I hope someone gets some value out of these numbers. Steve |
I actually found this to be an interesting post. It's always nice to have evidence of things rather just saying something like. "it seems faster with more RAM".
|
This is interesting. It sounds like you're seeing a performance difference by avoiding swapping to disk (virtual memory).
However, I'm surprised you see such a difference, as the files you are working with are much smaller than 512MB. Maybe you are runnning very close to 512MB before opening the file, and opening the file pushes you over the edge? The output of the 'free' command might show some interesting data. Also running 'top', and then typing 'M' (capital) will show you your top memory-consuming processes. |
Hi,
Glad someone liked the numbers. I too like to see hard numnbers that's why I ran the tests. I find the difference hard to believe. Just 1 extra Gig of RAM and bang....... I'm also surprised at how well the smp Dell did. Someone asked me about my hard drive, which seems to be running fairly fast. hdparm -tT /dev/hdb /dev/hdb: Timing cached reads: 1288 MB in 2.00 seconds = 644.00 MB/sec Timing buffered disk reads: 156 MB in 3.03 seconds = 51.49 MB/sec hdparm /dev/hdb /dev/hdb: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 19457/255/63, sectors = 312581808, start = 0 Even when working with large files my swap file gets used very little. I ran top to verify this. Right now used memory is 318164. I'm running firefox, Kmail, Konqueror and one terminal. mem 1551968 Total 318164 used swap 498004 total 0 used When I open a 24.9 meg file with Gimp the numbers are mem 1520884 used swap 212 used top-M shows 35.4% Gimp. The next four down are all firefox at 2.6% each. A guy on usenet was good enough to send me these links. They explain swap size and memory usage. Good stuff. http://sourcefrog.net/weblog/softwar.../free-mem.html http://sourcefrog.net/weblog/softwar...rnel/swap.html Take care, Steve |
So, opening a 25MB file in Gimp uses a lot more then 25MB. Good decision buying more memory :D
Thanks for the memory numbers. |
Quote:
the issue is not swap or not swap the issue is cpu cache fault + page fault versus just cpu cache fault without the secondary page fault |
Quote:
|
Hi foo_bar_foo,
No intrusion. I'm here to learn things like everyone else. Would you mind explaining what you said. I'm lost. ;-) Steve |
Quote:
I see lots and lots of people here with notions of swap must be from windows 98 or something where virtual memory must have been just swap partition like indescriminate page dumping or like whole apps get swapped out or something. sorry again for implying you were one of them. |
Quote:
but basically the cpu looks for the data it needs first in it's own cache stuff already there runs really really fast i think there are a couple of level of cpu cache (L1, L2) (one smaller inside the core and a larger one outside) the cpu also has MMU that keeps track of these tables and maps or arrays or whatever they are that map out all the virtual memory pages allocated to different processes and how they map to physical memory. something like that anyway. the cpu always looks for the virtual page address and the MMU translates that into a spot on your harddrive or a spot in RAM or lke that (physical address). so when the cpu needs some data it looks in its cache and if it's not there you have time delay #1 because it has to get it from RAM. But when it looks in RAM and it's not there either oh boy now you got big time delay cause it has to do a hardware access to get the data and that involves harware interupts and drivers and endless array of slow junk. more RAM = more virtual addresses translate directly to actual addresses which is exactly what Skazi said which is why i should have left you guys alone :) i was afraid he was talking about swap like swap partition and we get so many people here confused about what swap partition is i freeked out like when a soldier just back from iraq hears a car backfire. I've got LQ shellshock and should take a vacation. |
Hi again,
I ran this on the Dell with a new Debian Testing install. I am using testing in sources.list. My main computer uses testing also but has not been upgraded since Sarge went stable so the versions are different. I didn't run this test on the Dell last install because I got busy. To open a 24.9 Meg map with Gimp 2800 512 Meg 6:59.05 2800 1.5 Gig 1:07.60 Dell 1Gig 4:41.61 Dell was very slow to select image or bring up image scaling box compared to the 2800 with 1.5Gig. I had to run it on the 2800 again just to see if it was that sluggish. Now I have to admit I wonder if the Dell would beat the 2800 if they both had 1Gig RAM? To scale 24.9 Meg image to 10% using Gimp Dell 1Gig 2:44.63 minutes 2800 1.5 Gig 57.58 seconds On the Dell top showed it used all 1Gig installed and just over 1 Gig of swap partition while scaling. On the 2800 top showed 1.5 Gig fully used. Max swap usage was 113284k while scaling. As I said, I am using testing. I ran this test again on the Dell just to see if the apps showed different results than my older ones did. To open a 12.7 Meg map file with Gimp Old apps Dell 43.69 sec New install Dell 50.52 seconds 2800 512 Meg 2:44.38 2800 1.5 Gig 23 seconds To scale that image to 10% Old apps Dell 28.65 sec New apps Dell 41.24 sec 2800 512 Meg 1:37.44 2800 1.5 Gig 59.75 seconds It seems the new apps may be slower than the older ones. Funny how the Dell beats the 2800 on scaling the smaller image but not the larger one. I wonder if I could put in 2 Gig, if it would better the 2800 again? Too bad 1 Gig is max.:( Someday I'll get a faster dual cpu machine that I can put in at least 2 Gigs of RAM in. Seems from my playing there is no substitute for RAM when dealing with larger files. The second cpu makes it more responsive when busy but only RAM really makes it faster on large files. Makes me drool for a dual core AMD chip now though. Ok, so maybe if I get one of those I'll post the numbers for that too. Take care, Steve |
All times are GMT -5. The time now is 12:49 AM. |