Bad Sector
Arcane
- Joined
- Mar 25, 2012
- Messages
- 2,224
Thanks, your response clearly demonstrates I’m asking questions for which answers are over my head. One point tho regarding your comment:
“Regardless these numbers are tiny and it pointless to even try and think about them - a single texture is most likely going to use more memory than all these tiny pieces of unused memory all over the engine combined.”
Isn’t this the sloppy thinking that gives us computationally inefficiency code such as Unity which merely takes computing power increases and translates them to a lower and lower programming standard such that mouth breathers such as myself can code, without concern for how code is compiled to assembly and executed on bare metal?
Not really, i mentioned it is pointless because they wont make much of a difference in terms of unused memory. These are all over the place in the OS, memory allocator, etc and they are often needed to make things faster (aside from other uses like ensuring the values stay disk compatible): the CPU does not access memory byte-by-byte but actually in chunks of memory and alignment allows it to avoid having data that "span chunks" (ie. some piece of data would otherwise fit in one chunk is placed in memory so that it crosses two chunks, causing the CPU to read more memory than necessary just to access it).
for example, in searching uint32 for C++ enumeration, I stumbled upon a description of cache efficiency and branch predictor accuracy during run time as a function of “wasted” bits for enumeration. If you call a list a lot in a piece or code and it’s assembled poorly such that there’s a lot of wasted computation in simply parsing the enum, it’s size (32 bit) isn’t really relevant vs the size of a texture. It’s relevant in how it impacts the execution of code at an instructions per cycle (IPC) level, ie on bare metal.
Yes but that is something that is orthogonal, the aligned memory enables faster speed so unaligned memory accesses aren't going to be a bottleneck but that doesn't mean they are going to be your bottleneck in a specific case.
(also FWIW aligned memory is enforced by the C++ standard anyway so it isn't like you can avoid it - you can configure compilers to use minimum alignment, but this will slow down your program, especially in non-x86 CPUs which are incredibly bad at accessing unaligned memory... actually some CPUs may even cause the program to crash :-P)
EDIT: also this is really moot for the vast majority of software anyway, a scripting language (like used in most games and a lot of software) is going to shit all over your memory accesses and I/O (like in most game streaming) is going to shit all over your scripting languages performance. In terms of performance that stuff is only relevant in "hot loops", ie. code that is executed very frequently in a loop (e.g. physics calculations) which are only a very tiny part of an game's codebase. Usually performance issues come from algorithmic and architectural issues, not microoptimizations like that.
Last edited: