Category: macos, year: 2023
Apple Silicon Macs (M-series CPUs) have “unified memory”, where the the CPU and GPU can share the same core memory.
By default however (at least on MacOS 13 and 14), the amount of memory that can be “wired” or allocated to the GPU is only around 66-75%
of the total system memory (the ratio depends on the amount of system memory), but it’s possible to change this and increase the amount of memory the GPU can access.
On MacOS 14 - Sonoma:
sudo sysctl iogpu.wired_limit_mb=27700
On MacOS 13 - Ventura:
sudo sysctl debug.iogpu.wired_limit=27700
Will allocate just over 27 GB of memory to the GPU, while still leaving a bit left dedicated to the CPU.
Category: linux, year: 2020
Valgrind is a tool on Linux (it might work on some other UNIX platforms as well?) that allows validating and debugging memory accesses of applications (in addition to other things like profiling cache accesses and validating some thread locking correctness), which can be very useful for debugging issues in applications written in non-‘safe’ programming languages like C and C++. It can help identify issues like use-after-free, buffer overruns and other similar issues which conventional debuggers (gdb, lldb) might not always catch until is too late (i.e. you just see the segfault, not the original root cause event).
It can also track down memory leaks as well - although other more specialised applications like heaptrack and bytehound can in some cases be better tools to use for just profiling memory usage (as opposed to memory correctness as well), as these other applications just concentrate on that and are in some cases much faster when debugging your application compared to fully running through valgrind. However in some cases I have found both heaptrack and bytehound have produced non-existant (effectively not possible) stacktraces for memory allocations, whereas valgrind doesn’t seem to have this issue.
Additional args:
--track-origins=yes will track the origin of all memory allocations which can be helpful to work out what memory was causing any particular issue.
--leak-check=full will perform full memory leak checking.
--max-threads=2000 or similar is needed if the application being profiled/debugged uses more than the default of 500 threads valgrind can cope with.
--log-file=/tmp/valgrind_run1.txt will tell valgrind to write the output (which can be incredibly verbose) to a file instead of stdout which is often a good idea.