![[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:
72: * In includes/vdi.h set MAX_VDI_WIDTH and MAX_VDI_HEIGHT from 1024 and
1.1.1.2 ! root 73: 768 to 640 and 400 respectively. This decreases memory usage from 1.5MB
! 74: to 0.5MB as Hatari allocates 2*2 framebuffers for page flipping in
! 75: Screen_Init().
! 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.