Cpu`s mit mehren Kernen, 32/64/128 bit für wen ändert sich was?
-
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?
-
Keine speziellen Fallstricke, zumindest keine von denen ich wüsste (was nicht viel heisst, hab nur kurz drübergesehen).
Ich meine nur da man selbst als Programmierer sagen muss was wie parallelisiert werden soll, kommt schnell blödsinn raus wenn man dabei Fehler macht.
Und AFAIK prüfen die Compiler nicht ob die OpenMP Angaben stimmen können, sondern verlassen sich einfach darauf.----
Zur "FORTRAN" Frage: einige Sprachen können grundsätzlich parallelisiert werden, z.B. funktionale Sprachen.
Da es keinen (oder kaum) mutable State gibt ist das relativ einfach.
Wenn ich in einer funktionalen Sprache etwas wie "return a(x) + b(y) + c(z)" habe kann ich das sofort in 3 threads aufspalten.Und dann gibt es Sprachen die es zwar nicht selbst machen, es dafür aber dem Programmieren sehr einfach machen. Wie z.B. CILK.
-
hustbaer schrieb:
Zur "FORTRAN" Frage: einige Sprachen können grundsätzlich parallelisiert werden, z.B. funktionale Sprachen.
Da es keinen (oder kaum) mutable State gibt ist das relativ einfach.
Wenn ich in einer funktionalen Sprache etwas wie "return a(x) + b(y) + c(z)" habe kann ich das sofort in 3 threads aufspalten.Und dann gibt es Sprachen die es zwar nicht selbst machen, es dafür aber dem Programmieren sehr einfach machen. Wie z.B. CILK.
Wieviele Sprachen kennst du eigentlich?..^^
-
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...
Man kann, wie bereits gesagt, automatisch ein bisschen was parallel machen. Aber einen seriell geschriebenen Code automatisch für einen Parallelrechner fähig zu machen ist ein Ding der Unmöglichkeit möchte ich mal behaupten. Es gibt zusätzlich zu den üblichen Frameworks wie OpenMP und MPI dann noch HPF, aber das ist auch eher ein Aufsatz auf Fortran.
-
so ein delete schreiben kostet doch nicht viel zeit..
gibt es irgendwas, das der compiler des borland c++ builder 6 in der richtung kann ?
kann man in c++ auch aufteilen ?
wie kann man da für 64 bit systeme kompilieren ?
-
ich glaube als 10jahre vor 64 bit die 32bit kamen und man sich gerade mit 40MB Harddisk im olymp fuehlte (wenn ich mich richtig entsinne), hat auch niemand zu glauben gewagt dass in kurzer zeit der 4GB addressspace ausgeht. das wird bei 64bit auch recht flott passieren.
zum multicore, intel sagt man soll so langsam paradigmen wechseln und nicht mehr in dual oder quadcore denken und programmieren, sondern seine software so designen, dass sie auf beliebig vielen cores laeuft und damit skaliert, weil es in zukunft rapide mehr cores geben wird. ende dieses jahres soll ja schon 8core rauskommen (ich glaube das las ich bei heise) und dann dauert es wie beim MHz-rennen nicht lange bis dann 128cores, 2048cores etc. in einem rechner stecken.
hilfslibs wie openMP oder Intels codeblocks sind da auch nur kleine hilfen fuer jetzt um ein paar schleifen zu parallelisieren. am ende wird man unmengen an aufgaben erstellen muessen die unabhaengig (ohne sync) ablaufen koennen und sich die cores aus einer work-queue rausnehmen sobald sie fertig sind mit dem aktuellen job.
-
Helium schrieb:
Bill Gates (1983) schrieb:
Nobody will ever need more than 640 kB RAM.
Quatsch... das "ever" kannst Du streichen. Die Aussage war eher "640 kByte should be enough for everybody", und zwar auf den damaligen Zeitpunkt bezogen und nicht auf "solange die Menschheit existiert und die Kühe grasen, wird niemals irgendjemand auf die dämliche Idee kommen, mehr als 640 kByte zu benötigen"
-
Rock Lobster schrieb:
Helium schrieb:
Bill Gates (1983) schrieb:
Nobody will ever need more than 640 kB RAM.
Quatsch... das "ever" kannst Du streichen. Die Aussage war eher "640 kByte should be enough for everybody", und zwar auf den damaligen Zeitpunkt bezogen und nicht auf "solange die Menschheit existiert und die Kühe grasen, wird niemals irgendjemand auf die dämliche Idee kommen, mehr als 640 kByte zu benötigen"
Also im Netz finde ich beide Zitate deins von '81 meins von '83.
-
rapso schrieb:
ich glaube als 10jahre vor 64 bit die 32bit kamen und man sich gerade mit 40MB Harddisk im olymp fuehlte (wenn ich mich richtig entsinne), hat auch niemand zu glauben gewagt dass in kurzer zeit der 4GB addressspace ausgeht. das wird bei 64bit auch recht flott passieren.
Von 32 Bit auf 64 Bit kannst Du 32 weitere Bits "füllen". Von 16 Bit auf 32 Bit nur 16. Das heißt, dass bei gleichbleibender technischer Entwicklung die 64 Bit Epoche doppelt so lange anhalten sollte wie die 32 Bit Epoche.
-
Gregor schrieb:
rapso schrieb:
ich glaube als 10jahre vor 64 bit die 32bit kamen und man sich gerade mit 40MB Harddisk im olymp fuehlte (wenn ich mich richtig entsinne), hat auch niemand zu glauben gewagt dass in kurzer zeit der 4GB addressspace ausgeht. das wird bei 64bit auch recht flott passieren.
Von 32 Bit auf 64 Bit kannst Du 32 weitere Bits "füllen". Von 16 Bit auf 32 Bit nur 16. Das heißt, dass bei gleichbleibender technischer Entwicklung die 64 Bit Epoche doppelt so lange anhalten sollte wie die 32 Bit Epoche.
man muss auch noch mit einbeziehen, dass die technische entwicklung auch immer schneller voran geht.
MfG borgolte
-
borgolte schrieb:
man muss auch noch mit einbeziehen, dass die technische entwicklung auch immer schneller voran geht.
Das Gegenteil ist eher der Fall: Am Anfang hat man beim Moore'schen Gesetz noch von 12 Monaten gesprochen, bis sich die Transistoranzahl verdoppelt. Dann waren es 18 Monate und inzwischen spricht man von 24 Monaten.
-
Gregor schrieb:
borgolte schrieb:
man muss auch noch mit einbeziehen, dass die technische entwicklung auch immer schneller voran geht.
Das Gegenteil ist eher der Fall: Am Anfang hat man beim Moore'schen Gesetz noch von 12 Monaten gesprochen, bis sich die Transistoranzahl verdoppelt. Dann waren es 18 Monate und inzwischen spricht man von 24 Monaten.
Ist trotzdem noch eine exponentielle Entwickelung, egal ob man jetzt 12 oder 24 Monate nimmt. Eine Verdoppelung einer großen Zahl ist immer ein größeres Wachstum als die Verdoppelung einer kleinen. Heute geht es schneller als damals, wenn auch nicht so schnell wie damals voraus gesagt wurde.
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.
Wie wäre es mit Kiloexa's ? (Das Apostroph wurde bis dahin in die Sprache aufgenommen :p
)Autoparallelisierung könnte ich mir aber für C++ vorstellen. Der Compiler muss halt Abhängigkeiten für alle Funktionen feststellen und zwischen speichern aber sonst sehe ich da keine großen Probleme. Schleifen kann man auch parallelisieren wenn der Compiler feststellen kann, dass nur lesend auf die Schleifenvariable zugegriffen wird.
-
Ben04 schrieb:
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.
Wie wäre es mit Kiloexa's ? (Das Apostroph wurde bis dahin in die Sprache aufgenommen :p
)Wie wärs denn mit Zetta und Yotta?!
-
Ich glaube nicht, dass der 64bit Adressraum so schnell ausgeht. Einfach in anbetracht der Tatsache, wie lange man braucht um beispielsweise jedes Byte einmal anzufassen... und das selbst dann, wenn man sich superschnelle Zugriffsgeschwindigkeiten gönnt. Natürlich werden die auch schneller, aber eben nicht so schnell.
