RAM und CPU herausfinden
-
Hallo,
ich möchte mittels C++ die gesamt Größe des RAMs (z.B. 8GB) herausfinden, sowie genaueres über den Prozessor, sprich: GHz, 32-Bit oder 64-Bit?, Hersteller, ... Hab gegoogelt und hab CPUID gefunden, das geht aber nur unter Assembler, richtig? Ich würde gerne mit C++ arbeiten, finde dazu aber nicht wirklich was abgesehen von der WindowsAPI die ich aber nicht nutzen will, weil das ganze auch auf Linux,OS X, ... funktionieren soll.LG
-
Dann wirst du entweder eine lib finden müssen die cross platform ist, oder die verschiedenen Systemfunktionen in Präprozessordirektiven packen (für jedes zu unterstützende System).
Was auch so unabhängig geht:
Ob deine Anwendung 32 oder 64 bit ist kannst du über die Größe eines Zeigers feststellen.
Wie viele Kerne kann man mit "hardware_concurrency" rausfinden (siehe <thread>)
-
Tim06TR schrieb:
Ob deine Anwendung 32 oder 64 bit ist kannst du über die Größe eines Zeigers feststellen.
Da waere ich mir gar nicht so sicher. Es gibt Optimierungen, bei denen 32-Bit Zeiger in 64-Bit Anwendungen benutzt werden, wenn der Compiler beweisen kann, dass in dem Codeabschnitt 32 Bit reichen und das dann irgendwie flotter ist. Man kann natuerlich in der Regel zur Compilezeit ueber Makros der ueblichen Compiler herausfinden, welche Zielplattform die Anwendung hat. Aber der TE will das ja gar nicht wissen, er will wissen was die Hardware kann. Was die Hardware kann, kann schliesslich ganz was anderes sein, als das was das OS unterstuetzt und nochmal was anderes als das fuer was die Anwendung compiliert wurde.
Wie viele Kerne kann man mit "hardware_concurrency" rausfinden (siehe <thread>)
Hat im Endeffekt die gleichen Probleme wie der erste Punkt. Die unterliegende Hardware und die Implementierung der Runtime oder die vom OS der Runtime zur Verfuegung stehenden Ressourcen koennen voneinander abweichen.
Die ganze Frage ist im Endeffekt sehr stark systemabhaengig, daher helfen im Endeffekt nur systemabhaengige Sachen, um diese Informationen zu besorgen, also eben Assembler oder Systemcalls. In beiden Faellen macht man natuerlich schon einige Annahmen, wie die Systeme grob aussehen. Anders geht es wohl auch kaum, denn auf so manchen Rechnern, die ich kenne, ist nicht unbedingt klar, was mit der CPU oder dem verbauten RAM ueberhaupt gemeint ist. Computer sind schliesslich nicht alle mehr so aufgebaut wie Desktoprechner aus den 1990ern und selbst Handys haben heutzutage mehrere Prozessoren, es gibt Geraete mit nicht-von-Neumann-Architekturen (wird gerne bei Routern gemacht) und Hardwarevirtualisierung ist gang und gaebe.
-
kann schliesslich ganz was anderes sein, als das was das OS unterstuetzt und nochmal was anderes als das fuer was die Anwendung compiliert wurde.
Das hätte ich dazuschreiben sollen / Das das nicht die direkte Antwort war dachte ich war relativ klar.
Aber ich nehme an, die Unterstützung des Prozessors herauszufinden ist, wenn überhaupt, nur schwierig zu ermitteln (oder mit Umwegen (soll heißen: mit Tabellen aus der Bezeichnung o.ä.)).Wie viele Kerne kann man mit "hardware_concurrency" rausfinden (siehe <thread>)
Hat im Endeffekt die gleichen Probleme wie der erste Punkt. Die unterliegende Hardware und die Implementierung der Runtime oder die vom OS der Runtime zur Verfuegung stehenden Ressourcen koennen voneinander abweichen.
Kleine Ergänzung: Man hat auch die Möglichkeit hier eine 0 zu bekommen.
-
SeppJ schrieb:
Da waere ich mir gar nicht so sicher. Es gibt Optimierungen, bei denen 32-Bit Zeiger in 64-Bit Anwendungen benutzt werden, wenn der Compiler beweisen kann, dass in dem Codeabschnitt 32 Bit reichen und das dann irgendwie flotter ist.
Das will ich sehen, glaube ich nicht.
-
Tim06TR schrieb:
Ob deine Anwendung 32 oder 64 bit ist kannst du über die Größe eines Zeigers feststellen.
Das hängt allerdings auch davon ab, was genau hier mit 32 bzw. 64 bit gemeint ist.
Die x32-ABI (für x86_64) beispielsweise verwendet 32bit für int,long und Zeiger (ILP32), während der Prozessor tatsächlich im Long-Modus läuft und somit u.a. auf den größeren Registersatz zugreifen kann.cooky451 schrieb:
SeppJ schrieb:
Da waere ich mir gar nicht so sicher. Es gibt Optimierungen, bei denen 32-Bit Zeiger in 64-Bit Anwendungen benutzt werden, wenn der Compiler beweisen kann, dass in dem Codeabschnitt 32 Bit reichen und das dann irgendwie flotter ist.
Das will ich sehen, glaube ich nicht.
Da bin ich auch skeptisch.
-
cooky451 schrieb:
SeppJ schrieb:
Da waere ich mir gar nicht so sicher. Es gibt Optimierungen, bei denen 32-Bit Zeiger in 64-Bit Anwendungen benutzt werden, wenn der Compiler beweisen kann, dass in dem Codeabschnitt 32 Bit reichen und das dann irgendwie flotter ist.
Das will ich sehen, glaube ich nicht.
http://stackoverflow.com/questions/14550626/64-bit-gcc-mixing-32-bit-and-64-bit-pointers
-
Das ist auch nur ein kreativer Weg ein Register zu beschreiben, aber nichts wird tatsächlich so im RAM gespeichert. In der Realität ist es natürlich auch relativ unmöglich diese Optimierung durchzuführen, weil so gut wie alles was tatsächlich in reservierten Speicher gelegt wird in einem struct/array ist deren Größe man nicht ändern kann. Da sizeof(void*) allerdings eh zur Compilezeit ausgeführt wird, dürfte das relativ irrelevant sein, sizeof(void*) funktioniert immer.
-
Darueber hinaus kennt der GCC fuer x86-64 noch die Option -mx32, welche x86-64 Code erzeugt, aber 32 Bit Pointer benutzt.
-
Um vielleicht mal aufs eigentliche Problem zurückzukommen: Was genau hast du mit diesen Informationen vor? Ich frage das, um alternative Lösungswege vorzuschlagen, denn: Architekturen gibt es wie Sand am Meer, und auf alle vorbereitet zu sein, schafft man am sinnvollsten, indem man sich nicht auf ihre Details verlässt. Die Information, dass du gerade auf einem Sitara AM335x Cortex-A8 läufst, ist allenfalls für statistische Zwecke interessant, wohingegen die Information, wieviele Prozessorkerne dir zur Verfügung stehen, praktisch verwendbar ist. Was ist es, das du eigentlich von der Maschine wissen willst?
-
Ob deine Anwendung 32 oder 64 bit ist kannst du über die Größe eines Zeigers feststellen.
Darauf würde ich nicht wetten.
Auf meinem 16Bit Mikrokontroller kann ich mittels char _far* p; einen 24 Bit Zeiger erzeugen.
@Problemi:
Ohne Rücksprache mit dem Betriebssystem sehe ich keine Chance das festzustellen.Vielleicht hast du Glück und eine Lib wie QT hat das schon implementiert.
-
@Bitte ein Bit
Ja.Mit
sizeof(void*)bekommt man die Grösse "normaler" ("near") Zeiger. Die muss natürlich nicht mit der Registerbreite übereinstimmen, und auch keinen Rückschluss auf die Grösse des insgesamt adressierbaren Bereichs zulassen. (16 Bit DOS Compiler hatten ja oft ein "huge" Modell, in dem alle Zeiger 32 Bit waren, konnten dabei aber trotzdem nur 1 MB adressieren (16 Bit Segment << 4 + 16 Bit Offset))Davon abgesehen ist
sizeof(void*)bei einem 32 Bit Windows Programm das unter WoW64 läuft trotzdem 4. Wenn wissen möchte ob man eine 64 Bit CPU hat, kann mansizeof(void*)sowie sämtliche Präprozessor-Makros also sowieso vergessen. Da hilft nur das OS fragen, oder CPU- und compilerabhängige Funktionen bzw. Inline-Assembler verwenden.
-
Davon abgesehen ist sizeof(void*) bei einem 32 Bit Windows Programm das unter WoW64 läuft trotzdem 4.
Es war ja auch die Rede festzustellen, ob das eigene Program unter 32 oder 64 bit läuft.
Was im Nachhinein auch etwas widersinnig ist...
-
Bitte ein Bit schrieb:
Davon abgesehen ist sizeof(void*) bei einem 32 Bit Windows Programm das unter WoW64 läuft trotzdem 4.
Es war ja auch die Rede festzustellen, ob das eigene Program unter 32 oder 64 bit läuft.
Deswegen hab ich ja auch "Ja." geschrieben, und nicht "Nein." oder "Nicht ganz."
War als Ergänzung gedacht, nicht als Korrektur.
