Cpu`s mit mehren Kernen, 32/64/128 bit für wen ändert sich was?
-
128bit 4 Milliareden mal 4 GB = 16 000 000 000 000 MB = 16 Billionen MB RAM;)
hmm... und wenn doch.. was könnte man mit 1024Bit addressiern^^
-
sap schrieb:
Bald wird sicher nicht mehr die Frage sein "wie schnell sie die Cpu", sondern "wie viele Kerne hat die". Momentan schient noch 32 bit der Standard zu sein aber langsam kommt ja auch 64. 128 und größer wird bestimmt auch nicht lange auf sich warten lassen.
Dir ist schon klar dass "32 Bit" nicht bedeutet "32 Kerne"? Ad Bit: 64 Bit sind wohl in naechster Zeit leicht genug.
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. Auf 32-Bittigem Windows laufen keine 64-Bit Progamme, auch wennn's deine CPU unterstuetzt). Bei Java, C# und anderen VM-Sprachen macht das die VM fuer dich.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.
-
BorisDieKlinge schrieb:
128bit 4 Milliareden mal 4 GB = 16 000 000 000 000 MB = 16 Billionen MB RAM;)
hmm... und wenn doch.. was könnte man mit 1024Bit addressiern^^
OK, sollten wir irgendwann mal 128Bit Addressen verwenden, haben wir ein Problem, weil dann die Begriffe ausgehen. Klar, Giga, Tera, Peta, Exa, aber weiter gehts dann AFAIK nicht. Und 295147905179352825856 Exa Byte kann sich doch kein Arsch merken.
---
@sap: die Breite der Adrresse (32Bit, 64Bit, 128Bit, ...) hat nichts mit der Anzahl der CPU-Kernen zu tun, sondern damit wieviel Arbeitsspeicher addressiert werden kann.
32Bit beschränkt sich auf 4 GigaByte, was inzwischen ein bischen wenig ist. 64Bit Erlaubt immerhin 16 ExaByte (16384 PetaByte oder 16777216 TeraByte), was die nächste Zeit vermutlich ausreicht.Dei Anzahl der Kerne ist eine davon komplett unabhängige Größe. Je mehr kerne, desto mehr Dinge können Parallel gemacht werden, wenn es denn etwas gibt, was man auch parallel machen kann, da sich nicht jede Aufgabe in mehrere Parallel ausführbare Aufgaben zerlegen lässt. Üblich sind derzeit bis zu vier Kernen (Quadcore). Es existieren aber bereits erste experimentelle Designs von Intel mit 80 Kernen. Suns neuer Ultrasparc-Prozessor "T2" hat 8Kerne mit jeweils einer Art Hyperthreading, so dass pro Kern 8 Threads laufen können, was 64 Threads pro T2 bedeutet.
-
Helium schrieb:
BorisDieKlinge schrieb:
128bit 4 Milliareden mal 4 GB = 16 000 000 000 000 MB = 16 Billionen MB RAM;)
hmm... und wenn doch.. was könnte man mit 1024Bit addressiern^^
OK, sollten wir irgendwann mal 128Bit Addressen verwenden, haben wir ein Problem, weil dann die Begriffe ausgehen. Klar, Giga, Tera, Peta, Exa, aber weiter gehts dann AFAIK nicht. Und 295147905179352825856 Exa Byte kann sich doch kein ***** merken.
---
@sap: die Breite der Adrresse (32Bit, 64Bit, 128Bit, ...) hat nichts mit der Anzahl der CPU-Kernen zu tun, sondern damit wieviel Arbeitsspeicher addressiert werden kann.
32Bit beschränkt sich auf 4 GigaByte, was inzwischen ein bischen wenig ist. 64Bit Erlaubt immerhin 16 ExaByte (16384 PetaByte oder 16777216 GigaByte), was die nächste Zeit vermutlich ausreicht.Dei Anzahl der Kerne ist eine davon komplett unabhängige Größe. Je mehr kerne, desto mehr Dinge können Parallel gemacht werden, wenn es denn etwas gibt, was man auch parallel machen kann, da sich nicht jede Aufgabe in mehrere Parallel ausführbare Aufgaben zerlegen lässt. Üblich sind derzeit bis zu vier Kernen (Quadcore). Es existieren aber bereits erste experimentelle Designs von Intel mit 80 Kernen. Suns neuer Ultrasparc-Prozessor "T2" hat 8Kerne mit jeweils einer Art Hyperthreading, so dass pro Kern 8 Threads laufen können, was 64 Threads pro T2 bedeutet.
Du solltest dazu sagen, dass du dich auf den Desktop-PC beziehst
-
Hmmm also 128 Bit-Befehle lassen jedenfalls nicht mehr sooo lange auf sich warten:
-
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.