![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to memory-usage.txt CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [HATARI the Atari ST Emulator] / hatari / doc|
Return to memory-usage.txt CVS log | Up to [HATARI the Atari ST Emulator] / hatari / doc |
1.1 root 1:
2: HATARI MEMORY USAGE
3:
1.1.1.2 root 4: Here are some stats on Hatari v1.2+ memory usage (on Linux) and what
5: could be done to decrease it.
1.1 root 6:
7: First the binary size from "size ./hatari":
8: text data bss dec
1.1.1.2 root 9: 1489120 12828 18799688 20301636
10:
11: I.e. the Hatari binary size is 1.4MB, it has 12KB of non-const/pre-defined
12: arrays and 18MB of uninitialized (at build-time) fixed size arrays.
13: The names of latter are listed below.
14:
15: To decrease the binary size slightly, disable DSP from src/Makefile,
16: don't enabled tracing in config.h (latter may have trivial improvement
17: on speed too). You may also try the gcc "-Os" or "-O3 -finline-limit=..."
18: options, their effect depends on the architecture for which Hatari is
19: being compiled.
20:
21:
22: To see the objects in the Hatari 18MB BSS section, get the datadump
23: script from here:
24: http://live.gnome.org/MemoryReduction_2fTools
25:
26: Compile Hatari without stripping, and use:
27: datadump.py -n -s .bss -r ./hatari
1.1 root 28:
1.1.1.2 root 29: As a result you see these array variables:
30: 16777216 STRam hatari
31: 404400 dsp_core hatari
32: 324048 CyclePalettes hatari
33: 262144 mem_banks hatari
34: 262144 cpufunctbl hatari
35: 176612 ConfigureParams hatari
36: 131072 pInterceptWriteTable hatari
37: 131072 pInterceptReadTable hatari
38: 69632 InternalDTAs hatari
39: 65536 ymout5_u16 hatari
40: 32768 MixBuffer hatari
41: 32768 DspOutBuffer hatari
42: ...
43:
44: These empty arrays aren't an issue unless Hatari actually writes to
45: them, but that will happen as Hatari uses them. Here are some ways
46: to minimize dirtying of the related memory i.e. use of the arrays
47: in Hatari:
48:
49: * Enabling only required amount of memory for the emulation.
50: Hatari doesn't dirty (zero) all of STRam, just the part of the ST ram
51: that user has configured (accessible as ST ram, 0.5-14MB) and 2MB
52: at the top (used as IO-memory, TOS and cartridge memory).
53:
54: * Disabling DSP from build gets rid of dsp_core
55:
56: * Modifying Video_ClearOnVBL() and Video_ColorReg_WriteWord()
57: to call Spec512 functions only when nSpec512Threshold configuration
58: value is non-zero and run Hatari with spec512 support disabled.
59: This gets rid of CyclePalettes dirtying
60:
61: * ConfigureParams size can be decreased 22*4KB by setting
62: MAX_HARDDRIVES in configuration.h to one (or by removing
63: memset from Configuration_SetDefault() as static variables in .bss
64: are zeroed already by kernel, memset()ting them just makes them
65: dirty and Configuration_SetDefault() is called only at Hatari startup).
1.1 root 66:
67:
68: When I profiled Hatari with Valgrind (valgrind.kde.org) Massif plugin,
1.1.1.2 root 69: it tells that Hatari does about 3MB of memory worth of dynamic
70: allocations. The allocations and ways to make them smaller are:
1.1 root 71:
1.1.1.3 root 72: * In includes/vdi.h decrease MAX_VDI_WIDTH and MAX_VDI_HEIGHT
73: to 640 and 400. As Hatari allocates 2*2 framebuffers (of size
74: width*height/8) for page flipping in Screen_Init(), decreasing
75: their size can have have a large effect.
1.1 root 76:
77: * Do not load bigfont in gui-sdl/sdlgui.c, especially if the device
78: screen is smaller than VGA. Both fonts together take about 1/3 MB.
79:
80: * Change uncompressed file read to use mmap() instead, currently
81: memory is allocated for the whole disk image before reading it.
82: - With normal DD floppy image Hatari would use that amount which
83: might be acceptable, but with e.g. 2MB disk needed for running
84: Wolf3D v0.8, mmap() sounds much better
85: - For compressed disk images memory needs to be allocated for
86: uncompressed image data, i.e. there we cannot save memory.
87:
88: * Check whether the m86k instruction table could be made smaller:
89: #include "uae-cpu/readcpu.h"
90: printf("%d -> %d\n", sizeof(struct instr), sizeof(struct instr) * 65536);
91: On x86 it's slightly over 1MB.
92:
93: You can also Massif Hatari yourself, its allocation calltrees
1.1.1.2 root 94: are very short & the allocations are easy to find in the Hatari
95: source code.
1.1 root 96:
97:
98: From /proc/sysvipc/shm one can see how much shared memory Hatari/libSDL
99: has allocated and that it shares it with the X server:
100: - >100KB in lowrez
101: - ~200KB in lowrez with borders
102: - ~500KB in monochrome or zoomed lowrez
103: - >800KB in zoomed lowrez with borders
1.1.1.2 root 104:
105: I don't think these could be made smaller from the code. Besides,
106: user can just use a the smaller Hatari screen mode in fullscreen and
107: let the display scale it to fullscreen.
108:
1.1 root 109:
110: According to Xrestop, Hatari doesn't keep any Pixmap resources
111: at the X server side.
112:
113:
114: Finally when looking at the Hatari process with "pmap", you can
1.1.1.2 root 115: see that the libraries Hatari links don't use so much private
116: (writable) memory, only couple of hundred KB:
117: pmap $(pidof hatari) | grep / | grep rw
118:
119: To see how much from the memory pmap tells Hatari to have allocated is
120: actually used/dirtied, take a peek at: /proc/$(pidof hatari)/smaps.
121:
122: Of the rest of the 40MB Hatari VMSIZE you see in "top" (about 16MB),
123: half is unused/clean 8MB memory (allocated by kernel for the SDL sound
124: thread stack) and half goes to shared library code (their .text
125: sections with "r-x" rights) that Hatari links against. The libraries
126: are most likely used also by other programs and even if they aren't,
127: it's memory mapped read-only / read in on-demand pages & pagable back
128: to disk so it's shouldn't be much of a problem either.
129:
130:
131: Unmodified Hatari runs on (Linux) systems having about 20MB of _free_
132: memory (e.g. according to /proc/meminfo free+buffers+cached fields)
133: and more RAM in total than the Hatari VMSIZE.
1.1 root 134:
135: Using low-rez without borders nor zooming, setting emulated ST memory
1.1.1.2 root 136: amount to <=1MB, limiting the VDI screen size, disabling DSP and
137: removing bigfont (discussed with Massif findings above) should enable
138: running Hatari well on a system with only 10MB free memory, if it's
139: otherwise fast enough.
1.1 root 140:
141:
142: - Eero Tamminen
143:
1.1.1.2 root 144: PS. Any device fast enough to run Hatari at reasonable speed
145: should already have enough memory for it...
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.