Für wen ändert sich was? Muss man dann um auf die jeweilige Plattform optimiert zu haben sein ganzes Programm umschreiben? Oder "nur" für die einzelnen Plattformen extra Builds erstellen? Oder muss man dann auf "Framework Sprachen" wie .net setzen, wo die Optimierung durch das Framework und erst auf der entsprechenden Plattform vorgenommen?

Am besten würde es mir ja gefallen wenn der ganze Aufwand auf einer so niedrig wie mögliche Ebene dirigiert wird. Also am besten sollen sich die Compiler, Assembler oder das Betriebssystem sich darum kümmern.

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.

Das sind ja gleich 2 Aspekte auf einmal. Ich geh mal auf die Bits ein: 128 werden nicht sooo schnell kommen, was Desktop-Rechner betrifft. Wenn die technische Entwicklung so wie in den letzten Jahrzehnten weitergeht, dann kannst Du Dir relativ leicht ausrechnen, wie lange Du brauchst, bis 64 Bit nicht mehr ausreichen, um Deinen Hauptspeicher handhaben zu können. ...in 50 Jahren oder so könnte da die Grenze erreicht werden.

...und das Moore'sche Gesetz wird seine Gültigkeit vermutlich bei weitem keine 50 Jahre mehr behalten.

Das 64 Bit bezieht sich ja nicht auf die Registerbreite (64 breite Register gibt's schon lange), sondern auf den Adressraum. Und 4 Milliarden mal 4GB (1,6 * 10^19) sind VIELE VIELE Bytes. Eben 4 Milliarden mal mehr als ein 32 Bit Rechner addressieren kann.
Der Unterschied ist 64000 mal grösser als der zwischen einem C64 und einem heutigen PC.

Also... bis es 128 Bit Systeme gibt (wenn überhaupt jemals) sind wir nimmer am Leben.

hmm... und wenn doch.. was könnte man mit 1024Bit addressiern^^

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.

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.

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

http://www.heise.de/newsticker/meldung/95180

Hmmm also 128 Bit-Befehle lassen jedenfalls nicht mehr sooo lange auf sich warten:

http://www.heise.de/newsticker/meldung/95180

Es geht in diesem Thread um die Adressierung

Nobody will ever need more than 640 kB RAM.

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.

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.

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

@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.

Nice. Fehlt nur noch ein ordentlicher Linux-Treiber, damit man kein Solaris verwenden muss.

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.

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.

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.

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...

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.

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?

Übrigens kann der gcc seit 4.2 auch OpenMP.

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.