![[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.1.2 root 76: - Change list of VDI modes in Hatari dialog accordingly!
1.1 root 77:
78: * Do not load bigfont in gui-sdl/sdlgui.c, especially if the device
79: screen is smaller than VGA. Both fonts together take about 1/3 MB.
80:
81: * Change uncompressed file read to use mmap() instead, currently
82: memory is allocated for the whole disk image before reading it.
83: - With normal DD floppy image Hatari would use that amount which
84: might be acceptable, but with e.g. 2MB disk needed for running
85: Wolf3D v0.8, mmap() sounds much better
86: - For compressed disk images memory needs to be allocated for
87: uncompressed image data, i.e. there we cannot save memory.
88:
89: * Check whether the m86k instruction table could be made smaller:
90: #include "uae-cpu/readcpu.h"
91: printf("%d -> %d\n", sizeof(struct instr), sizeof(struct instr) * 65536);
92: On x86 it's slightly over 1MB.
93:
94: You can also Massif Hatari yourself, its allocation calltrees
1.1.1.2 root 95: are very short & the allocations are easy to find in the Hatari
96: source code.
1.1 root 97:
98:
99: From /proc/sysvipc/shm one can see how much shared memory Hatari/libSDL
100: has allocated and that it shares it with the X server:
101: - >100KB in lowrez
102: - ~200KB in lowrez with borders
103: - ~500KB in monochrome or zoomed lowrez
104: - >800KB in zoomed lowrez with borders
1.1.1.2 root 105:
106: I don't think these could be made smaller from the code. Besides,
107: user can just use a the smaller Hatari screen mode in fullscreen and
108: let the display scale it to fullscreen.
109:
1.1 root 110:
111: According to Xrestop, Hatari doesn't keep any Pixmap resources
112: at the X server side.
113:
114:
115: Finally when looking at the Hatari process with "pmap", you can
1.1.1.2 root 116: see that the libraries Hatari links don't use so much private
117: (writable) memory, only couple of hundred KB:
118: pmap $(pidof hatari) | grep / | grep rw
119:
120: To see how much from the memory pmap tells Hatari to have allocated is
121: actually used/dirtied, take a peek at: /proc/$(pidof hatari)/smaps.
122:
123: Of the rest of the 40MB Hatari VMSIZE you see in "top" (about 16MB),
124: half is unused/clean 8MB memory (allocated by kernel for the SDL sound
125: thread stack) and half goes to shared library code (their .text
126: sections with "r-x" rights) that Hatari links against. The libraries
127: are most likely used also by other programs and even if they aren't,
128: it's memory mapped read-only / read in on-demand pages & pagable back
129: to disk so it's shouldn't be much of a problem either.
130:
131:
132: Unmodified Hatari runs on (Linux) systems having about 20MB of _free_
133: memory (e.g. according to /proc/meminfo free+buffers+cached fields)
134: and more RAM in total than the Hatari VMSIZE.
1.1 root 135:
136: Using low-rez without borders nor zooming, setting emulated ST memory
1.1.1.2 root 137: amount to <=1MB, limiting the VDI screen size, disabling DSP and
138: removing bigfont (discussed with Massif findings above) should enable
139: running Hatari well on a system with only 10MB free memory, if it's
140: otherwise fast enough.
1.1 root 141:
142:
143: - Eero Tamminen
144:
1.1.1.2 root 145: PS. Any device fast enough to run Hatari at reasonable speed
146: 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.