Cpu`s mit mehren Kernen, 32/64/128 bit für wen ändert sich was?
-
MathiasTemp schrieb:
Hmmm also 128 Bit-Befehle lassen jedenfalls nicht mehr sooo lange auf sich warten:
Es geht in diesem Thread um die Adressierung
-
naja 16 Billion MB RAM bzw. 16 Exa Byte (16 EB RAM) Arbeitspeicher... dann scheiss auf memory managment und delete XX; ^^ Der Speicher wird ja dann in 100 jahren nich voll wenn er immer an bleibt;)
-
Bill Gates (1983) schrieb:
Nobody will ever need more than 640 kB RAM.
-
Helium schrieb:
Klar, Giga, Tera, Peta, Exa, aber weiter gehts dann AFAIK nicht.
Es geht mit Zetta und Yotta weiter: http://de.wikipedia.org/wiki/Vorsätze_für_Maßeinheiten
@Helium: Ich glaube, Das Wachstum der RAM-Kapazität in Desktoprechnern hat sich in den letzten Jahren etwas verlangsamt. ...wobei das natürlich auch an der 32-64-Bit Schwelle liegen könnte.
-
BorisDieKlinge schrieb:
naja 16 Billion MB RAM bzw. 16 Exa Byte (16 EB RAM) Arbeitspeicher... dann scheiss auf memory managment und delete XX; ^^ Der Speicher wird ja dann in 100 jahren nich voll wenn er immer an bleibt;)
Genau. Wer schaft es denn schon nur 1 Milliarden Bytes zu verbruachen, da braucht man sicher Tage.
-
Gregor schrieb:
Helium schrieb:
Klar, Giga, Tera, Peta, Exa, aber weiter gehts dann AFAIK nicht.
Es geht mit Zetta und Yotta weiter: http://de.wikipedia.org/wiki/Vorsätze_für_Maßeinheiten
Danke. Ein Blick in Wikipedia wäre eigentlich nicht schwer gewesen
-
Gregor schrieb:
@Helium: Ich glaube, Das Wachstum der RAM-Kapazität in Desktoprechnern hat sich in den letzten Jahren etwas verlangsamt. ...wobei das natürlich auch an der 32-64-Bit Schwelle liegen könnte.
Ja, glaube ich auch, wenn man gleichzeitig sieht wie sehr das Zeug billiger wird. Aber ein normales Vista kann halt nur ~3 GB. Und selbst so mancher Linuxer glaubt, er müsse sich unbedingt auf 32-bit beschränken, weil es da neuere Treiber gäbe und sowieso 64-bit unnötig wäre...
(Nach meinen höchst unwissenschaftlichen Messungen lohnt sich der 64-Bit-Modus von x86-64-Prozessoren durchaus. Wobei es mir schwer fällt, zu erraten, warum. Eine Vermutung ist, dass eben die zusätzlichen Register helfen.)
-
Übrigens sagen die ZFS-Entwickler, dass dieses Dateisystem (das mit 128-Bit Adressierung arbeitet) tatsächlich ewig reicht, weil seine maximale Kapazität über dem (nach heutigen Erkenntnissen) quantenmechanisch Möglichen liegt.
-
.filmor schrieb:
Übrigens sagen die ZFS-Entwickler, dass dieses Dateisystem (das mit 128-Bit Adressierung arbeitet) tatsächlich ewig reicht, weil seine maximale Kapazität über dem (nach heutigen Erkenntnissen) quantenmechanisch Möglichen liegt.
Nice. Fehlt nur noch ein ordentlicher Linux-Treiber, damit man kein Solaris verwenden muss.
-
Es gibt eine FUSE-Implementierung.
-
sap schrieb:
Bald wird sicher nicht mehr die Frage sein "wie schnell sie die Cpu", sondern "wie viele Kerne hat die".
Äh, man hat doch mehr Kerne damit das System schneller wird. Du verwechselst wohl "schnell" mit Taktrate. Fataler Fehler!
.filmor schrieb:
Es gibt eine FUSE-Implementierung.
ordentlicher Linux-Treiber :p
BorisDieKlinge schrieb:
naja 16 Billion MB RAM bzw. 16 Exa Byte (16 EB RAM) Arbeitspeicher... dann scheiss auf memory managment und delete XX; ^^ Der Speicher wird ja dann in 100 jahren nich voll wenn er immer an bleibt;)
Sagt man regelmäßig. Das hätten dir vor 15-20 Jahren wohl auch noch die Mehrheit der Leute für 1GB unterschrieben.
-
Gregor schrieb:
Das sind ja gleich 2 Aspekte auf einmal.
Ja war wohl keine gute Idee das gleichzeitig anzusprechen. Mir ging es um den möglichen Mehraufwand für Softwaremacher.
Blue-Tiger schrieb:
Dir ist schon klar dass "32 Bit" nicht bedeutet "32 Kerne"?
Ja klar. Aber wenn ich meinen Post jetzt selbst noch mal lese sehe ich ein das er ungünstig formuliert war. Wir sind ja erst bei 2-8 Kernen was bald für Normalsterbliche erschwinglich sein wird.
Blue-Tiger schrieb:
Um die Vorteile von 64-Bit CPUs gegenueber 32-Bit CPUs zu nutzen, muesstest du ein neues Build erstellen, zumindest bei kompilierten Sprachen (und vorausgesetzt das Betriebssystem unterstuetzt das.
Das ist natürlich unpraktisch.
Blue-Tiger schrieb:
Auf 32-Bittigem Windows laufen keine 64-Bit Progamme, auch wennn's deine CPU unterstuetzt).
Sehr häßlich.
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Ich dachte das Betriebssystem macht das wenigstens so das es die verschiedenen Programme auf die Kerne verteilt.
-
sap schrieb:
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Ich dachte das Betriebssystem macht das wenigstens so das es die verschiedenen Programme auf die Kerne verteilt.
Macht es auch.
-
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Für Fortran gibt es zum Beispiel Compiler die automatisch parallelisieren können...
-
rüdiger schrieb:
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Für Fortran gibt es zum Beispiel Compiler die automatisch parallelisieren können...
OpenMP gibts aber auch für C/C++ der VC8 kanns zum Beispiel.
-
lolz schrieb:
rüdiger schrieb:
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Für Fortran gibt es zum Beispiel Compiler die automatisch parallelisieren können...
OpenMP gibts aber auch für C/C++ der VC8 kanns zum Beispiel.
OpenMP? Hat das was mit MPI zu tun?
-
Frag doch die Wikipedia ;). Die sagt dir, dass MPI mehr für das „Grobe“ ist, während OpenMP für solchen Kram wie Schleifenparallelisierung und generell Parallelisierungen innerhalb eines Prozesses gedacht ist.
Übrigens kann der gcc seit 4.2 auch OpenMP.
-
sap schrieb:
Ich dachte das Betriebssystem macht das wenigstens so das es die verschiedenen Programme auf die Kerne verteilt.
macht es ja auch, zumindest sollte es dafür sorgen, dass alle CPUs gleichmässig ausgelastet sind.
-
OpenMP kann _NICHT_ automatisch parallelisieren.
Das ist ja gerade das Problem.
Das, und dass man sich SO leicht selbst in den Fuss schiessen kann mit OpenMP.
-
sap schrieb:
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Ich dachte das Betriebssystem macht das wenigstens so das es die verschiedenen Programme auf die Kerne verteilt.
Klar, VERSCHIEDENE Programme werden auf die Kerne vom OS aufgeteilt. Aber wenn du ein Programm schreibst, wird dein Programm nur auf einem Kern laufen (wenn du nichts dagegen tust). Sprich dein Programm hat nichts davon das Zig verschiedene CPUs im Rechner stecken, weil es fuer dein Programm so ausschaut, als gaebe es nur eine.
rüdiger schrieb:
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Für Fortran gibt es zum Beispiel Compiler die automatisch parallelisieren können...
In wie weit geht das? Auto-Vectorisation kann der GCC ja z. B. auch, aber das laeuft ja selten auf mehr als auf das schlichte Verwenden von SIMD-Befehlen (SSE & Co) raus. Das ist fuer mich noch nicht wirkliches "Parallelisieren" eines Programmes (ich denk da eher an MIMD, also z. B. sinnvolle Aufteilung unabhaengiger Anweisungen auf Threads). Koennen Fortran-Compiler da mehr? Und falls ja: hast du Links oder Buzzwords fuer mich?
lolz schrieb:
rüdiger schrieb:
Blue-Tiger schrieb:
Was die Kerne angeht: du musst dein Programm eben Multithreaded designen. Das geht in C++ genauso schwer wie in .NET-Sprachen. Die Arbeit kann dir in absehbarer Zeit auch kein Compiler oder gar das Betriebssystem abnehmen.
Für Fortran gibt es zum Beispiel Compiler die automatisch parallelisieren können...
OpenMP gibts aber auch für C/C++ der VC8 kanns zum Beispiel.
Die OpenMP-Befehle muss aber der Programmierer setzen, also keine Automatisierung.
hustbaer schrieb:
OpenMP kann _NICHT_ automatisch parallelisieren.
Das ist ja gerade das Problem.
Das, und dass man sich SO leicht selbst in den Fuss schiessen kann mit OpenMP.Hmm... ich hab grad angefangen ein Programm zu schreiben, das OpenMP verwendet. Was sind denn so die "groessten" Fallstricke mit OpenMP? Haettest du evlt. Links fuer mich?
