List Of Way To Get Total Memory On Each Kind Of Computer
I want to have a totally cross-platform way of getting what the maximum value a pointer could have on the computer the program is running on at that specific point in time when the program is running (which I am assuming, but don't know for certain, is equal to the total virtual memory) at run-time (not compile-time using macros to check CPU specs).
My plan for achieving this is by using macros to determine the target host platform, then including the correct headers and using the correct functions based on that.
What I am asking from you is that if you have any special information about this on a type of host platform that has not yet been listed in the comments, then please list your way of getting the max value of the pointer and which macrois will identify the host platform.
My plan for achieving this is by using macros to determine the target host platform, then including the correct headers and using the correct functions based on that.
What I am asking from you is that if you have any special information about this on a type of host platform that has not yet been listed in the comments, then please list your way of getting the max value of the pointer and which macrois will identify the host platform.
Last edited on
| (which I am assuming, but don't know for certain, is equal to the total virtual memory) |
Nope, sorry but it doesn't work that way. The addresses you see for your pointers aren't the absolute memory addresses in the machine. In addition to that, (on Windows for example) memory is partitioned into system memory and user space memory; so you could theoretically exhaust all of the allocatable memory in user space with your program and still have almost half of your RAM physically doing nothing. This allocation is done at boot time so you can't really do anything to shift it around arbitrarily to meet your goal.
| My plan for achieving this is by using macros to determine the target computer, then including the correct headers and using the correct functions based on that. |
But at the same time...
| ... at run-time (not compile-time). |
I looks like you mentally changed tracks half way through writing this. Which approach did you decide on?
| What I am asking from you is that if you have any special information about this on a type of computer that has not yet been listed in the comments, then please list your way of getting the max value of the pointer and which macrois will identify the computer. |
Even if your method weren't flawed from the start, you have to know that you doing this the hard way. P.S. macros are destroyed at compile time, they are pretty much just find and replace statements that you tell the compiler to sort out.
- Windows: GetPhysicallyInstalledSystemMemory(): https://msdn.microsoft.com/en-us/library/windows/desktop/cc300158(v=vs.85).aspx
- POSIX: sysinfo(): http://man7.org/linux/man-pages/man2/sysinfo.2.html
You'll have to ask someone else about how to do this on a Mac. Objective-C is for masochists and to build your OS's API around it proves that Apple is a sadistic corporation.
EDIT: By the way, given your list of objectives:
- Simplistic task
- Run time determination of host platform
- OS agnostic with out an intermediate library such as Boost ASIO
Believe it or not, Java, or one of its subsidiaries, will be the right tool for this task, not C or C++.
Last edited on
| You'll have to ask someone else about how to do this on a Mac. Objective-C is for masochists and to build your OS's API around it proves that Apple is a sadistic corporation. |
I have to ask, why do you need to know the size of available memory? This is often a red flag of bad design.
@Computergeek01
1. I didn't mentally change tracks half way through. What I meant by at run-time rather than at compile time is that the host platform will be selected at compile-time, not runtime, and the correct headers and functions will be selected based on that instead of determining the max value of a pointer at compile-time based on the maximum addressable memory of the CPU.
2. Even if apple is 'sadistic', microsoft is ten-hundred-percent evil, so I would gladly buy a MAC instead of a PC any day (though I would still prefer a linux with Wine installed on it than a mac). Thank you.
3. If you really do believe that java is the way to go then you ought to keep in mind that java was written in c++, so anything possible in java is 10 times easier in c++.
@helios
I am not exactly trying to get the total memory, but rather the max value the pointer could be at run-time. It just so happens that this involves getting the total memory. Thank you.
1. I didn't mentally change tracks half way through. What I meant by at run-time rather than at compile time is that the host platform will be selected at compile-time, not runtime, and the correct headers and functions will be selected based on that instead of determining the max value of a pointer at compile-time based on the maximum addressable memory of the CPU.
2. Even if apple is 'sadistic', microsoft is ten-hundred-percent evil, so I would gladly buy a MAC instead of a PC any day (though I would still prefer a linux with Wine installed on it than a mac). Thank you.
3. If you really do believe that java is the way to go then you ought to keep in mind that java was written in c++, so anything possible in java is 10 times easier in c++.
@helios
I am not exactly trying to get the total memory, but rather the max value the pointer could be at run-time. It just so happens that this involves getting the total memory. Thank you.
Last edited on
@ da peppester, the max value is probably a variable the size of a pointer's maximum value. In the case of a 32-bit pointer, I'd imagine it's conceptually 0xFFFFFFFF. In practice, that probably is always a junk value and the OS will probably not allow an allocation that hits such a border before telling the application its out of memory.
Still, there's no need to know this value... I can't help but worry you might try and put this into practical use.
Still, there's no need to know this value... I can't help but worry you might try and put this into practical use.
Last edited on
| I am not exactly trying to get the total memory, but rather the max value the pointer could be at run-time. |
| It just so happens that this involves getting the total memory. |
@ NoXzema
No, that is not what I mean. What I mean by pointers maximum value is this: what is the maximum value the pointer could have on the computer the program is running on at that specific point in time when the program is running. Thank you.
@ helios
The reason for it is undisclosed. You would call me a mad-man if I tried to explain. So, lets please try to stay on topic. Thank you.
No, that is not what I mean. What I mean by pointers maximum value is this: what is the maximum value the pointer could have on the computer the program is running on at that specific point in time when the program is running. Thank you.
@ helios
The reason for it is undisclosed. You would call me a mad-man if I tried to explain. So, lets please try to stay on topic. Thank you.
The reason that prompts the question is important to understand the context in which the question is being asked. Therefore asking about it is very much on topic, I'd say.
Can't you at leave give a general idea? I have a hard imagining how that value is useful in any way. And no, I won't call you a madman. At worst I'll say "that idea is silly because X".
Can't you at leave give a general idea? I have a hard imagining how that value is useful in any way. And no, I won't call you a madman. At worst I'll say "that idea is silly because X".
Last edited on
da peppester, my answer is the same.
The only other thing I can possibly think of you wanting is the size of the allocation that the pointer is pointing to.
The only other thing I can possibly think of you wanting is the size of the allocation that the pointer is pointing to.
Last edited on
I agree with Helios. This smells like bad design to me. Maybe you want to use pointer values greater than the maximum to store special values. Programmers did that in the old Macintoshes and the results were disastrous. As I recall, the original 68000 processor used a 32 bit address but only the least significant 24 bits were brought off the chip (because at the time, it would take the GDP of a small country to afford the 16MB of memory that are addressable in 24 bits). Programers started storing stuff in that top byte. When the processors appeared that that actually USED the top byte of addresses (68020?), all those programs broke.
Also, it sounds like you're assuming that whatever holes exist in the address space will be at the end of the space. There's no guarantee of that. What if you run on a computer that puts the code at the very end of the address space and grows the heap backwards towards zero?
Or puts the heap near address zero, the code at the end and grows the heap up towards the beginning of the code?
If you want to reserve part of the address space for something special, why not allocate a chunk that has enough space for what you intend? Then you can use the address space, even if you never actually store any data in the memory.
Also, it sounds like you're assuming that whatever holes exist in the address space will be at the end of the space. There's no guarantee of that. What if you run on a computer that puts the code at the very end of the address space and grows the heap backwards towards zero?
Or puts the heap near address zero, the code at the end and grows the heap up towards the beginning of the code?
If you want to reserve part of the address space for something special, why not allocate a chunk that has enough space for what you intend? Then you can use the address space, even if you never actually store any data in the memory.
dhayden, I believe you are confused on what I am attempting to do. What I am attempting to do is not have a fixed size pointer that would fit in well with current computers (like maybe 40 bits long for a max of 256 GB of RAM) because I totally agree with you that that would be an absolutely terrible idea. Rather, what I am trying to do is force 64 (it won't actually be 64 because I'm anti-cargo-cult-programming, but i'm saying 64 to avoid confusion) copies of main using templates where each template to detect what the maximum and minimum values the pointer could be not at compile time, but rather at runtime and then run the main with the smallest size pointer that can hold all of the possible values that a pointer could be. This would be very practical in 3d games as vast arrays of pointers are required for well, everything.
You don't need to do that at run time. The address space limitations of each system are well documented.
In the particular case of Windows, 32-bit user-mode processes may allocate any region in the lower half of the full address space, so the minimal pointer is 31 bits long, or 4 bytes. 64-bit user-mode processes may allocate any region in the lower 8 TiB of the full address space, translating to a minimal pointer 44 bits long, or 6 bytes.
Check the documentation of your target systems to learn other particular values.
Note that pointer compression is an unusual technique that sacrifices time efficiency to gain space efficiency. This isn't a trade-off that's particularly useful in game programming. Usually you'd want the exact opposite.
Actually, I've never heard of a game engine that uses pointer compression. It only really makes sense if you have really huge graph-like data structures where the pointers represent a significant overhead. If a game engine has structures like these, something has probably gone seriously wrong in the cache optimization aspect of the design.
You sure like that phrase, dontcha?
In the particular case of Windows, 32-bit user-mode processes may allocate any region in the lower half of the full address space, so the minimal pointer is 31 bits long, or 4 bytes. 64-bit user-mode processes may allocate any region in the lower 8 TiB of the full address space, translating to a minimal pointer 44 bits long, or 6 bytes.
Check the documentation of your target systems to learn other particular values.
Note that pointer compression is an unusual technique that sacrifices time efficiency to gain space efficiency. This isn't a trade-off that's particularly useful in game programming. Usually you'd want the exact opposite.
Actually, I've never heard of a game engine that uses pointer compression. It only really makes sense if you have really huge graph-like data structures where the pointers represent a significant overhead. If a game engine has structures like these, something has probably gone seriously wrong in the cache optimization aspect of the design.
| anti-cargo-cult-programming |
Thanks for explaining the problem. Rather than trying to compress the pointers, another option may be the careful use of offsets. So rather than having lots of 64 bit pointers to a data structure, use a single pointer and lots of 32 bit offsets.
I'm not sure I understand what you're saying. What do 32-bit offsets have to do with anything?
Last edited on
pointer_to_element = pointer_to_head + index_of_element
If index_of_element < 2^n is always true, index_of_element may be stored in an n-bit integer, effectively compressing the pointer.
The disadvantage is that this requires a multiplication and an addition, while ideally you want to at most need a shift or a zero extension.
If index_of_element < 2^n is always true, index_of_element may be stored in an n-bit integer, effectively compressing the pointer.
The disadvantage is that this requires a multiplication and an addition, while ideally you want to at most need a shift or a zero extension.
Last edited on
Topic archived. No new replies allowed.