Ist das kostenlose Mittagessen vorbei? [geschlossen]

Geschlossen . Diese Frage ist meinungsbasiert . Derzeit werden keine Antworten akzeptiert.

Möchten Sie diese Frage verbessern? Aktualisieren Sie die Frage, damit sie mit Fakten und Zitaten beantwortet werden kann, indem Sie diesen Beitrag bearbeiten .

Geschlossen vor 6 Jahren .

In seinem berühmten Artikel The Free Lunch Is Over aus dem Jahr 2005 sagte Herb Sutter eine Concurrent Programming Revolution voraus, die so groß wie die objektorientierte Revolution ist. Hat sich diese Revolution wirklich in den Jahren 2005 - 2013 zugetragen?

Wichtige Punkte im Artikel:

Bei den meisten traditionellen Ansätzen zur Steigerung der CPU-Leistung ist den Prozessorherstellern der Platz ausgegangen. Statt immer höhere Taktraten zu erzielen, setzen sie auf Hyperthreading- und Multicore-Architekturen.
Anwendungen müssen immer häufiger gleichzeitig ausgeführt werden, um den CPU-Durchsatz voll ausnutzen zu können.
"Oh, die Leistung ist nicht so wichtig, Computer werden immer schneller", wird die Aussage falsch sein.
Effizienz- und Leistungsoptimierung werden mehr und nicht weniger wichtig. Diejenigen Sprachen, die sich bereits für eine starke Optimierung eignen, werden neues Leben finden. diejenigen, die dies nicht tun, müssen Wege finden, um wettbewerbsfähig und effizienter und optimierbarer zu werden. Erwarten Sie langfristig eine erhöhte Nachfrage nach leistungsorientierten Sprachen und Systemen.
Programmiersprachen und -systeme werden zunehmend gezwungen sein, mit Parallelität gut umzugehen. Wir brauchen dringend ein übergeordnetes Programmiermodell für die Parallelität als die heutigen Sprachen.

concurrency

— cpp
quelle

Wie viele Kerne hat Ihr Telefon?

— Matt D

Mein Nokia 2700 hat einen Kern.

— cpp

@MattD Entschuldigung, aber warum ist es "Zeit für ein Upgrade" und was hat die Anzahl der Kerne in CPPS Telefon damit zu tun? Woher weißt du, dass ein Nokia 2700 für seine Bedürfnisse nicht ausreicht?

— Andres F.

Ich werde aufzeichnen, um durch eine völlig nicht wissenschaftliche Beobachtung zu sagen, dass es eine solche Revolution auf der Hardware-Seite der Dinge gegeben hat, aber die Software-Revolution war außerordentlich langsam. Gleichzeitige Tools für alle Programmierer zu erhalten, ist immer noch eine schwierige Aufgabe, und Parallelität ist auch für erfahrene Parallelentwickler ein Problem, das nur schwer reproduzierbar ist.

— Jesse C. Slicer

Ich möchte nur darauf hinweisen, dass die Voraussagen nicht unbedingt falsch sind, nur weil das Timing der Voraussagen falsch ist. Es ist ziemlich offensichtlich, dass die oben aufgeführten Schlüsselpunkte nicht die implizierte Wichtigkeit erlangt haben, aber es gab Schritte in Richtung jedes dieser Punkte. Daher würde ich sagen, dass die obigen Vorhersagen wahr werden, es ist nur eine Frage des Zeitpunkts. Das WANN wird sein, wenn es eine Anforderung und nicht nur ein Wunsch wird. Zu wissen, wann diese Schwelle überschritten wird, ist der Grund für die Vorhersage, wann dies so schwierig ist.

— Dunk

Antworten:

Ja, aber es kommt darauf an.

Sie können nicht damit rechnen, nicht- triviale Hochleistungssoftware zu schreiben , ohne sowohl die parallele Hardware als auch die Parallelität als Programmstrukturierungstechnik zu nutzen. Die meiste Software ist jedoch sowohl trivial als auch nicht leistungskritisch. Eine Web-App macht nicht viel mit Zahlen und CRUD-Apps haben nichts mit den harten Zeitlimits einiger Simulations- und medizinischer Software zu tun.

Insbesondere Spieleentwickler müssen sich darum kümmern, da Spiele die am häufigsten verwendete Art von Anwendungen mit weichen Echtzeitanforderungen sind. Das Problem tritt vor allem bei Mobiltelefonen auf, bei denen ein integrierter Chip mit zwei CPU-Kernen und einer GPU mit geringem Stromverbrauch so viel Rechenleistung und Renderleistung wie möglich liefern soll. Das ist ein weiterer Grund, warum so viele Entwickler auf Haskell schauen und darauf warten, dass Sprachen wie Rust ausgereift sind - wir wollen Sicherheit und Leistung auf moderner Hardware.

Seit 2005 haben wir neue und verbesserte Tools wie OpenCL-, CUDA-, OpenMP- und Vektoranweisungssätze für die Arbeit mit Parallelität und Datenparallelität in etablierten Sprachen erhalten. Die relativen Neulinge sind jedoch von Anfang an so konzipiert, dass sie noch viel mehr interessante Dinge gleichzeitig tun können.

Dank der gleichzeitigen Laufzeit von Haskell bietet die Sprache umfassende Unterstützung für Lightweight-Parallelität (Funken) und Parallelitätsabstraktionen (Threads, Kanäle und gemeinsam genutzte veränderbare Referenzen). Go and Rust bietet auch leichte Aufgaben, Go using channels und Rust using message passing.

Diese Systeme bieten Speichersicherheit, leistungsfähige Laufzeiten und statischen Schutz gegen bestimmte Arten von Rennen. Die standardmäßige Unveränderlichkeit von Haskell und Rust erleichtert die Verwaltung der Parallelität erheblich. Erlang wurde tun dies bereits in den 80er Jahren, aber die Bedürfnisse der Software und unser Wissen darüber , wie Programmiersysteme zu entwerfen , haben sich ebenfalls verbessert Güte da-danken.

Schließlich sind viele existierende Sprachen - ich werde keine Namen nennen - bereit, als glaubwürdige Entscheidungen für das Schreiben neuer Software abzulehnen. Aufgrund ihrer Komplexität und schlechten Nebenläufigkeit sind sie für die Überlegungen moderner Anwendungen ungeeignet. Wir warten einfach auf ausgereifte Alternativen.

— Jon Purdy
quelle

Ich bin mir nicht so sicher, ob bestimmte Sprachen abgelehnt werden. Ich hoffe, dass der Code mehr auf die Minimierung von Abhängigkeiten als auf alles andere ausgerichtet ist. Schließlich ist es nicht wirklich die Sprache, die schuld ist, sondern wie Sie sie verwenden. Und die "niedrig hängenden Früchte" ihrer Verwendung stimmen nicht mehr mit Multithreading / Parallelität überein.

— Matt D

@MattD: Sowohl die Verwendung einer Sprache als auch die Sprache selbst können fehlerhaft sein. Sagen Sie, Ihr Programm ist falsch. Du bist derjenige, der es falsch geschrieben hat, aber die Sprache hat dir nicht unbedingt geholfen, es richtig zu schreiben , und das ist genauso wichtig.

— Jon Purdy

Hier sind einige Datenpunkte; Entscheide selbst, ob es sich um eine Revolution handelt.

Parallelisierte Hardware

Um 2005 starten Intel und AMD die Massenproduktion von 2-Kern-Desktop-x86-CPUs (Pentium D und Athlon 64) mit Taktraten um 3 GHz.

2006 erscheint PlayStation 3 mit dem Cell-Prozessor mit 8 + 1-Kernen bei 3,2 GHz.

Im Jahr 2006 wird die GeForce 8-Serie veröffentlicht. Es besteht aus einer großen Anzahl (~ 100) von allgemeinen "Stream-Prozessoren" im Gegensatz zu grafikspezifischen Einheiten. Um 2007 wird die CUDA 1.0-Spezifikation veröffentlicht, die einige allgemeine Berechnungen auf massiv paralleler NVidia-Hardware ermöglicht.

Seitdem haben sich die Tendenzen fortgesetzt.

Nehmen wir an, Intel und AMD bieten 2013 CPUs mit 4, 8 und 16 Kernen mit Taktraten, die etwas über lediglich 4 GHz liegen. Dual-Core- und Quad-Core-Designs sind für Geräte mit geringerem Stromverbrauch wie Laptops und Smartphones üblich.

All dies ist massenproduzierte Computerhardware für den täglichen Gebrauch.

Software

CUDA wird im Jahr 2007 und OpenCL im Jahr 2008 veröffentlicht und ermöglicht die Verwendung von massiv parallelen GPUs für allgemeine (nicht-grafische) Berechnungen. Das Modell wird populär; Viele Hosting-Unternehmen (z. B. Amazon) bieten GPUs für allgemeine Computeraufgaben an.

Go wird 2009 veröffentlicht und bietet sehr günstige Preemptive-Threads ("Goroutines"), mit denen sich hochkonkurrierende Algorithmen effizient ausdrücken lassen.

Das Akka-Toolkit wird 2009 für Java und Scala veröffentlicht und ermöglicht akteurbasierte Parallelität.

Erlang (eine sehr konkurrierende Sprache) sieht eine gewisse Zunahme der Nutzung.

Parallelität vs. Parallelität

Beachten Sie, dass für die Verwendung paralleler Hardware nicht unbedingt die gleichzeitige Verwendung von Software erforderlich ist, dh das Jonglieren mit Ausführungsthreads innerhalb einer Berechnung. Viele Probleme werden durch parallele , nicht interagierende Prozesse gelöst , wobei jeder Prozess ein traditionelles sequentielles Programm ist.

Bei der parallelen Verarbeitung werden möglicherweise traditionellere Sprachen und parallele Frameworks verwendet, z. B. Kartenreduzierung, MPC oder OpenMP. Bei solchen Frameworks unterscheidet sich das Vorhandensein mehrerer Kerne auf demselben CPU-Kristall konzeptionell nicht wesentlich davon, nur mehr CPUs im Cluster zu haben. Der Unterschied liegt hauptsächlich in der Geschwindigkeit.

Bisher kein kostenloses Mittagessen

Die CPU-Geschwindigkeit liegt im oberen Bereich noch bei rund 5 GHz. Mit besseren Technologien in Sicht, wie Graphen-Transistoren, könnten die Frequenzen in Zukunft wieder ansteigen, aber wahrscheinlich nicht sehr bald.

— 9000
quelle