Cpu`s mit mehren Kernen, 32/64/128 bit für wen ändert sich was?
-
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?
-
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.
