Gibt es Ursachen für die limitierte Skalierbarkeit von Rechenarchitekturen die prinzipieller Natur sind? Oder kann es eine Rechenarchitektur geben die in der Praxis theoretisch unendlich skalierbar ist? Die Frage die mich interessiert ist ob die Limitierungen rein technischer Natur sind oder ob man da eher so was wie einen Naturgesetz hat? z.B. mit zunehmender Größe wachsen die Leitungswege, was irgendwann zu immer längeren Wartezeiten der Recheneinheiten führt. Oder das anwachsen der Datenmenge für die Kommunikation zwischen den Recheneinheiten, die irgendwann so groß wird dass es nicht genug Bandbreite gibt. Es ist ja z.B. klar dass Recheneinheiten nicht beliebig kleiner werden können. Folglich können die Datenleitungen zwischen den Recheneinheiten nicht immer kürzer werden. Wenn die kleinste mögliche Recheneinheit gebaut ist und man fängt an diese Recheneinheiten nebeneinander und übereinander zu stappeln fangen die Datenleitungen an zu wachsen.
Die Skalierung wird durch den Zugriff auf gemeinsam genutzte Resourcen begrenzt - typischerweise das RAM. Systeme, die keine gemeinsamen Resourcen nutzen, skalieren bereits jetzt beliebig.
Goldenboyx1 schrieb: > Wenn die kleinste mögliche Recheneinheit gebaut ist und man fängt an > diese Recheneinheiten nebeneinander und übereinander zu stappeln fangen > die Datenleitungen an zu wachsen. Daran siehst du schon, dass es auf die Aufgabe ankommt. Eine Recheneinheit, die lokal viel rechnen kann und wenig auf externe Datenzugriffe angewiesen ist, hat damit wenig Probleme.
Am besten gehen Aufgaben, die sich gut parallelisieren lassen, so daß viele Prozesse bzw. Maschinen einen Teil der Gesamtaufgabe berechnen. Was eher schlecht funktioniert sind Aufgaben, wo eine Berechnung immer auf das Ergebnis einer vorangegangenen Berechung angewiesen ist.
Goldenboyx1 schrieb: > Gibt es Ursachen für die limitierte Skalierbarkeit von > Rechenarchitekturen die prinzipieller Natur sind? Ein schon recht altes "Gesetz" ist das von Amdahl: https://de.wikipedia.org/wiki/Amdahlsches_Gesetz
Ben B. schrieb: > Was eher schlecht funktioniert sind Aufgaben, wo eine Berechnung immer > auf das Ergebnis einer vorangegangenen Berechung angewiesen ist. Wobei das auch bei Entscheidungen statt Berechnungen gilt.
foobar schrieb: > Die Skalierung wird durch den Zugriff auf gemeinsam genutzte Resourcen > begrenzt - typischerweise das RAM. Systeme, die keine gemeinsamen > Resourcen nutzen, skalieren bereits jetzt beliebig. Wenn es keinerlei gemeinsamen Ressourcen gibt, ist es dann überhaupt zusammen als ein System zu betrachten?
Rolf M. schrieb: > Wenn es keinerlei gemeinsamen Ressourcen gibt, ist es dann überhaupt > zusammen als ein System zu betrachten? Siehe SETI und Co. mfg klaus
Klaus R. schrieb: > Rolf M. schrieb: >> Wenn es keinerlei gemeinsamen Ressourcen gibt, ist es dann überhaupt >> zusammen als ein System zu betrachten? > > Siehe SETI und Co. Auch da gibt es gemeinsame Ressourcen, in dem Fall die Datenbank, von der die Eingangsdaten kommen und auf der die Ergebnisse gespeichert und verarbeitet werden, bzw. deren Verbindung mit dem Internet.
Wenn du wirklich an einer theoretischen Grenze interessiert bist, solltest du dir das Landau-Limit anschauen. https://de.wikipedia.org/wiki/Landauer-Prinzip Praktische Rechner sind allerdings um viele Größenordnungen von dieser Granze entfernt.
Das Naturgesetz verbietet das. Sogar die Intelligenz ist nicht beliebig skalierbar. Flaschenhals-Datenstrom. https://de.wikipedia.org/wiki/Von-Neumann-Architektur#Von-Neumann-Flaschenhals Parallele Ausführungen bedeutet, dass ich ein komplexes Newton-Physik-System nicht mehr ausrechnen kann, weil jedes berechnetes Atom von allen anderen Atomen beeinflusst werden müssten. Wenn ich bessere Simulationen haben will, dann berechne ich den Atomschlag nicht im Computer, sondern ich führe sie aus.
Helwein V. schrieb: > Parallele Ausführungen bedeutet, dass ich ein komplexes > Newton-Physik-System nicht mehr ausrechnen kann, weil jedes berechnetes > Atom von allen anderen Atomen beeinflusst werden müssten. Das hat aber nichts mit paralleler Ausführung zu tun. Ohne Parallelität hat man das selbe Problem.
Irgendwo ist immer ein Flaschenhals, der limitiert.
Vielleicht aendern sich auch die Anforderungen mit der Groesse. Eine Turing Maschine ist zwar denkbar, aber nicht wirklich optimal. Fuer gar nichts. Und dann benotigt man fuer einen neue Architektur auch eine Infrastruktur, sprich Compiler, usw, bedeutet man benoetigt einem Markt, und Investoren. Es gibt ja spezialisierte Architekturen. zB GPU.
Goldenboyx1 schrieb: > die in der Praxis theoretisch unendlich Ähm ja das ist ein Hirnfurz was :D Aber ne, gibt es nicht; parallel ist schön; aber auch jedes nochso komplexe Problem kann sich nicht beliebig klein aufbrechen lassen, deswegen ist "unendlich" schon im Ansatz falsch Sobald die Recheneinheit eine Rückgabe erzeugt (und das muss sie zwangsläufig um Sinn zu machen) ist mindestens der Rückgabekanal als limitierend zu betrachten. Ansprechbarkeit (addressierung) ist ein weiterer Faktor den man sogar in der Theorie als limitierend betrachten muss. Grundsätzlich gibt es also immer einen Punkt, an dem eine weitere Recheneinheit keinen Geschwindigkeitsvorteil mehr bei der Berechnung des Problems erzeugt. Entweder weil die Datenübergabe an den Rechenkern den erwarteten Zeitvorteil kompensiert, oder die Ergebnissmeldung (im Zweifel beides) Und während semi autarke Botnetze (wie seti) das relativ gut verschleiern, funktioniert das auch nur deswegen, weil die Daten redundant gerechnet werden und das Netz an sich selbst schon stark begrenzt ist. Aufgaben und Rückgaben caching sind der einzige Weg ein Botnetz einigermassen stabil laufen zu haben. implementiert man mirrors und bubbling data kann man die Controllerlast weiter reduzieren, aber selbst mit allen Tricks gäbe es einen Punkt an dem die zentrale Datenbank überlastet werden würde. In der Praxis gibt es immernoch Auswege daraus, in der Theorie allerdings ist dem immer eine Grenze gesetzt. (spätestens weil man nicht alle 10^80 Teilchen im bekannten Universum in einen eigenständigen Rechner umwandeln kann ;)) 'sid
Interessante Antworten und interessante Indizien. Indizien weil mir bisher noch nicht wirklich klar ist ob unendliche Skalierbarkeit wirklich prinzipiell unmöglich ist. Es wirkt so als würde der eindeutige mathematische Beweis fehlen. Auch wenn vieles darauf hindeutet dass es prinzipiell begrenzt ist. Wenn wir die Rechenkraft von Computern als Problemlöser interpretieren und menschlichen Fortschritt ebenfalls als Problemlösung auffassen. Ist es dann so dass die Menschheit, quasi als ein biologischer Prozess, ebenfalls limitiert ist? Der aktuelle Fortschritt sprengt bereits die Fähigkeiten einzelner Menschen. Bisher konnten immer komplexere und aufwendigere Probleme dadurch gelöst werden dass Menschen sich organisierten und ein gewisser Wissensaustausch stattfindet. Doch können organisierte Projekte beliebig groß werden? Können 100 Mio. Menschen an einem Projekt arbeiten? Könnten 100 Mrd. Menschen zusammenarbeiten? Oder würde man selbst mit den besten Organisationsmethoden und Kommunikationsmittel irgendwann an eine prinzipielle Grenze stoßen?
Mit der Anzahl der beteiligten CPUs steigt der Organisationsaufwand. Ähnlich Konzern gegen Ein-Mann-Firma. Eine Fehlersuche könnte auch interessant werden sobald das Zeitfenster nicht reicht.
sid schrieb: > ist mindestens der Rückgabekanal als limitierend zu betrachten Bei einem Computer, der Jahrhunderte rechnet und dann 42 ausgibt ist das nicht wirklich der Flaschenhals. Georg
georg schrieb: > sid schrieb: >> ist mindestens der Rückgabekanal als limitierend zu betrachten > > Bei einem Computer, der Jahrhunderte rechnet und dann 42 ausgibt ist das > nicht wirklich der Flaschenhals. > > Georg Du verwechselst Rückgabekanal mit Ausgabe. Nehmen wir ein banales true false Problem an für die durchaus leicht parallelisierbare Frage: "ist x Prim" nun nimmst Du 2^80 -1 Prozessorkerne die alle ihre ureigene uniqueID (integer zwischen 1 und 2^80) daraufhin prüfen der Auftrag ist schnell gemacht .. proc0 sendet also bool is_prim(proc_id) an alle kerne die Rückgabe ist der weg zum zwischen den 2^80 -1 prozessorkernen und dem auftragstellenden Master (proc0) der empfängt also im Zweifel zeitgleich 2^79 mal FALSE und muss diese 604462909807314587353088 binären Einzelinformationen irgendwie fassen können. Die Ausgabe 2 false 4 false 6 false etc.pp. oder xyz numbers are prime ist dem ja nachgeschaltet und besonders im letzten Fall bestimmt nicht der bottleneck ;) Goldenboyx1 schrieb: > Indizien weil mir > bisher noch nicht wirklich klar ist ob unendliche Skalierbarkeit > wirklich prinzipiell unmöglich ist. Nun das ist aber mehr ein Problem Deinerseits fürchte ich. Okay es bleibt dabei, die Zahl der Atome im Universum ist ENDLICH selbst WENN jedes Atom ein eigener Prozessor wäre, wäre die Anzahl der Prozessoren die damit prinzipiell möglich sind ebenfalls ENDLICH! Damit ist die UNENDLICHE skalierbarkeit de facto vom Tisch. Selbst unermessliche Skalierbarkeit ist nur theoretisch möglich, eben weil Du Einheits-verhalten verlangst. Eine Eingabe, eine Ausgabe und unermessliche Rechenkapazität in der Mitte. scheitert schon an der Auftragserteilung. Du kannst einfach nicht schnell genug Zählen. und bis ins "unendliche" kannst Du sowieso nicht zählen wie also willst Du die Prozessoren adressieren? Und das musst Du immer wenn Du von Systemeinheit sprichst. unermesslich grosse Zahlen sind leicht zu schreiben in der Grössenordnung von 2^1024 sogar in Gebrauch aber versuchst du nur bis 2^80 hochzuzählen in Einzelschritten wirst Du am Hitzetod des Universums scheitern (weil auch dessen Lebenszeit ENDLICH ist) 2^80 sind 1.208.925.819.614.629.174.706.176 sagen wir du kannst 100.000 Zahlen pro sekunde hochzählen (und prozessoren addressieren) also durch (~)3.155.673.600.000 brauchst Du 383.095.963.921,82 Jahre (383 milliarden jahre) ab welcher Geschwindigkeit denkst Du Du könntest für Dich erfassbare Zeitspannen erreichen? Also vielleicht ignorierst Du den inflationären Umgang mit "unendlich" wenn Du von physischen Einheiten sprichst besser schnell, und formulierst Die Frage ggf um. 'sid
Goldenboyx1 schrieb: > Gibt es Ursachen für die limitierte Skalierbarkeit von > Rechenarchitekturen die prinzipieller Natur sind? 42! Sorry, aber das ist ein typisches Beispiel einer Frage deren Antwort zweckfrei ist, weil die Frage scheisse formuliert ist. So wie beim "Hitchhiker", die Frage nach dem "Life, universe and everything" (die deren Antwort 'fourty two' lautet). Den schaut man auf das Internet und insbesonders IoT muss man schon einräumen, das Rechnerarchitekturen beliebig erweiterbar und zusammenschaltbar sind. 'Skalierbarkeit von Rechenarchitekturen' ist da ein ziemlich dehnbarer Begriff, den man auch so postulieren kann, das er nie den Wert Null annimmt. Ohnehin wird der Begriff der Skalierbarkeit nicht binär eingesetzt (ist oder ist nicht Skalierbar) sondern um qualitative Abstufungen (ist gut , ist weniger gut skalierbar) erklennbar zu machen.
georg schrieb: > sid schrieb: >> ist mindestens der Rückgabekanal als limitierend zu betrachten > > Bei einem Computer, der Jahrhunderte rechnet und dann 42 ausgibt ist das > nicht wirklich der Flaschenhals. Naja, es sind Millionen Jahre (wobei sich Jahr auf ein anderes Planetensystem als Erde-Sonne bezieht) nicht hunderte und hat er mehr als ein schnödes fourty two von sich gegeben: https://youtu.be/5ZLtcTZP2js?t=22 ;-)
Goldenboyx1 schrieb: > Doch können organisierte Projekte beliebig groß werden? > > Können 100 Mio. Menschen an einem Projekt arbeiten? Könnten 100 Mrd. > Menschen zusammenarbeiten? > Oder würde man selbst mit den besten Organisationsmethoden und > Kommunikationsmittel irgendwann an eine prinzipielle Grenze stoßen? Die Grenze liegt nicht bei 100 Millionen, die Grenze liegt bei 7. Bei einer Teamgröße von 7 ist das Optimum erreicht. Dann noch mehr Leute zu Team abzukommandieren führt zu mehr Kommunikation als Effizientsteigerung im Team. Sowas lernt man in Vorlesungen/Schulungen zum Thema 'Software engineering'. Das ist IMHO ein sinnvollerer Zeitvertreib als das aufgeblasene palaver über angeblich Mathematische Beweise und Indizien.
Berufsrevolutionär schrieb: > Bei einer Teamgröße von 7 ist das Optimum erreicht Was für ein Optimum - man kann ein System wie Windows oder Office nicht mit 7 Programmierern verwirklichen, also ist bei grösseren Projekten diese Frage irrelevant, es muss eben mit hunderten gehen. Auf der anderen Seite ist das natürlich vom Problem abhängig - ein Software-Guru hat mal gesagt, im Team programmieren wäre wie der Versuch die Zeit für eine Schwangerschaft durch Einsatz von 9 Frauen auf 1 Monat zu reduzieren. sid schrieb: > die Zahl der Atome im Universum ist ENDLICH Das ist ein völlig unbewiesene Behauptung. Georg
Goldenboyx1 schrieb: > Oder kann es eine Rechenarchitektur geben die in der Praxis theoretisch > unendlich skalierbar ist? Physikalische Systeme sind immer endlich. :-)
georg schrieb: > Was für ein Optimum - man kann ein System wie Windows oder Office nicht > mit 7 Programmierern verwirklichen, also ist bei grösseren Projekten > diese Frage irrelevant, es muss eben mit hunderten gehen. Herrgottssakrament, das hat man davon, daß die Jugend von heute nicht beim Militär war, denn dort lernt man, das man einen großen Haufen Kanonenfutter nur steuern kann, wenn man in 'Teams' aka militärische Einheiten wie Gruppe, Zug, Kompanie, Batallion etc. strukturiert. 'Divide et impera' wie schon die römischen Bettlakenträger wussten.
Goldenboyx1 schrieb: > Gibt es Ursachen für die limitierte Skalierbarkeit von > Rechenarchitekturen die prinzipieller Natur sind? weil ALLES nur limitiert skalierbar ist? (aus Prinzip) Auch 1 Mio Maurer mauern 1m² Mauer nicht 1 Mio x schneller als einer! Fragen gibt es.........
:
Bearbeitet durch User
georg schrieb: > Berufsrevolutionär schrieb: >> Bei einer Teamgröße von 7 ist das Optimum erreicht > > Was für ein Optimum - man kann ein System wie Windows oder Office nicht > mit 7 Programmierern verwirklichen, also ist bei grösseren Projekten > diese Frage irrelevant, es muss eben mit hunderten gehen. Unsinn. Man steckt dann aber nicht 100 in ein Team, sondern teilt das Problem auf und macht entsprechend wieder kleinere Teams für die Teile. Die Frage des TE ist so schwammig, wie sie gestellt ist, aber wirklich unsinning. Die Antworten sagen mehr darüber aus, was der jeweilige Antworter sich unter der Frage vorgestellt hat. In der Praxis stellt sich die Frage allein schon deswegen nicht, weil es gar keine Aufgabenstellung gibt, die unendlich parallelisiert bearbeitet werden könnte.
Ich kann ja mal den ursprünglichen Gedanken der Frage wiedergeben. Es ist die Überlegung darüber ob die Leistungsfähigkeit (Problemlösungen, Berechnungen, Intelligenz, Anhäufung von Wissen) eines System (Gesellschaft, Computer, Lebewesen) theoretisch beliebig groß werden kann. Dabei sind physikalische Grenzen wie dass es möglicherweise nicht unendlich viel Materie und Raum gibt außer Acht gelassen. Physikalische Gesetze die ein beliebiges anwachsen eines einheitlichen Systems bereits lokal begrenzen sind natürlich von Bedeutung. Die Antwort auf die Frage würde beispielsweise auch erklären ob das was wir Intelligenz nennen theoretisch beliebig groß anwachsen kann. Oder ob selbst die leistungsfähigste Maschine, also eine KI, an prinzipielle Grenzen stößt.
Joachim B. schrieb: > Auch 1 Mio Maurer mauern 1m² Mauer nicht 1 Mio x schneller als einer! Aber 1 Mio Maurer können 1 Mio Mauern ziemlich genau 1 Mio x schneller mauern als einer. Und genau damit wären wir wieder bei den gemeinsamen Resourcen: Können wir die Maurer schnell genug mit ausreichend Zement versorgen, und müssen die einzelnen Mauerteile irgendwann miteinander verbunden werden. Die Frage, ob man Systeme grundsätzlich skalieren kann, ist schon recht sinnvoll. Auf existierende Systeme mit einem "dieses da nicht" zu zeigen ist da nicht zielführend. Goldenboyx1 schrieb: > Die Antwort auf die Frage würde beispielsweise auch erklären > ob das was wir Intelligenz nennen theoretisch beliebig groß > anwachsen kann. Auch da landen wir wieder bei der Parallelisierbarkeit. Nehmen wir mal als Beispiel die Forschung: Die findet in kleinen Teams statt (weil große Teams ineffizient werden), die parallel verschiedene Dinge gleichzeitig erforschen. Aber es gibt keine globale Koordinierung, folglich gibt es viele Teams, die das gleiche machen - das ist Verschwendung. Solange es genug verschiedene Forschungsthemen gibt, hält sich die Verschwendung in Grenzen. Engt man die Bereiche ein (z.B. durch einen Fokus auf ein Virus, durch bestimmte Fragestellungen, oder durch politische Ungewolltheit), dann steigt die Wahrscheinlichkeit von Kollisionen - es wird mehr verschwendet, also sinkt die Skalierbarkeit. Nun gibt es zwischen den Forschungsteams auch Austausch (Konferenzen, Journals, etc.) und schon hast du sowohl einen Rückkanal als auch globale Koordinatoren. Verschwendete Forschung freut die Beteiligten nicht, also müssen sie Zeit opfern, um rauszufinden, was (a) sinnvoll zu erforschen ist und (b) noch nicht erforscht wurde. Insbesondere (b) ist schwierig. Es gibt viele coole Patente und Ideen aus dem 20. Jahrhundert, die man als Basis für aktuelle Forschung nehmen kann. Was vor 100 Jahren als schlechtere Option gescheitert ist, kann heute z.B. mit modernen Materialien oder Fertigungstechniken die bessere Option sein. Der Haken: Jemand mit Wissen müsste das mal durchgehen. Die Lebenszeit eines Menschen ist begrenzt - es folgen Heuristiken und damit Verschwendung und damit begrenzte Skalierbarkeit.
S. R. schrieb: > Auch da landen wir wieder bei der Parallelisierbarkeit. Nehmen wir mal > als Beispiel die Forschung: Die findet in kleinen Teams statt (weil > große Teams ineffizient werden), die parallel verschiedene Dinge > gleichzeitig erforschen. Aber es gibt keine globale Koordinierung, > folglich gibt es viele Teams, die das gleiche machen - das ist > Verschwendung. Parallelisierbarkeit beinhaltet das Konzept der Trennung. Man will getrennte Prozesse bzw. Systeme koordiniert auf ein bestimmtes Ziel hin steuern. Diese Trennung oder Aufspaltung in mehrere Prozesse/Systeme hat in der Regel immer einen guten oder zwingenden Grund. Das soll heißen dass man aus zwingenden Gründen beispielsweise einen Supercomputer aus vielen Recheneinheiten baut. Da es nicht möglich ist einen einzigen etwa 50m² großen Chip herzustellen. Der zwingende Grund muss nicht nur technologischer und praktischer Natur sein, es kann auch prinzipieller Natur zwingend werden. Also, ab einer System bedingten unterschiedlichen Skalierungsgröße, ist eine weitere Leistungssteigerung nur noch durch Trennung weiter hinzugefügter Systemressourcen möglich. Das heißt aus einem System werden zwei Systeme. Damit ist die Leistungsfähigkeit eines einzelnen Systems begrenzt. Durch zwei Systeme hat man insgesamt mehr Leistung im Raum. Aber damit beide Systeme auf das selbe Ziel hin arbeiten müssen sie miteinander wechselwirken bzw. kommunizieren. Und das ist nun eine interessante Stelle finde ich. Kann die Kommunikation die Trennung der beiden Systeme bzw. die Trennung ihrer Leistungsfähigkeit vollständig kompensieren? Eigentlich nein. Wäre die Kommunikation so effizient dass sie die Trennung vollständig kompensieren würde, dann wäre eine Aufteilung in zwei Systeme gar nicht notwendig gewesen. Man hätte quasi eine Lösung für weitere Skalierung eines Systems und hätte die maximale Skalierungsgröße nicht erreicht. Folglich verrät bereits diese Logik dass die Kommunikation zwischen zuvor zwei zwingend (Systembedingt) getrennten Systemen mit Informationsverlust behaftet ist, ganz gleich welcher Art und Effizienz die Kommunikation ist. Es gibt zwischen zwei notwendig getrennten Systemen also einen Informationsverlust. Das eine System verfügt nicht über alle Informationen des anderen Systems und somit ist das Ausmaß der koordinierten Arbeit begrenzt. Und wie du sagst, kann es passieren dass beide teilweise am selben Problem arbeiten ohne es zu wissen und somit Ressourcen verschwenden. Doch führt man dieses Konzept weiter: Immer wenn die systembedingte maximale Skalierung eines Systems erreicht ist, wird das System geklont und als neues System hinzugefügt und mit dem Rest vernetzt. Dann passiert etwas erstaunliches. Trotz der Informationsverlust zwischen den einzelnen vernetzten Systemen, gelingt es dem neuen Netzwerk eine Leistungsfähigkeit zu erbringen wie es ein einzelnes System nicht schafft. Hinzu kommt dann dass dieses neue Netzwerk wiederum als ein einheitliches System definiert werden kann. Dessen Skalierung auf die bisher formulierte Art vermutlich auch limitiert ist und nur durch Schaffung zweier Netzwerke aufgehoben werden kann, wobei es wieder einen Informationsverlust zwischen beiden Systemen gäbe, also zwischen Netzwerk A und Netzwerk B. Doch man kann dieses Prinzip immer weiter führen und es entsteht insgesamt mehr Leistungsfähigkeit. Die maximale Skalierung eines System wird also durch trennen, kopieren/klonen und vernetzen der getrennten Systeme überwunden. Oder nicht? So erklärt sich im Grunde auch die Entstehung komplexer Lebewesen bzw. Systeme. Atome verbinden sich zu Molekülen (System Level 1), Moleküle verbinden zu komplexen Proteinen (Level 2), Proteine verbinden sich zu einer ganzen Zelle (Level 3), Zellen verbinden sich zu einem Organ (Level 4) und Organe verbinden sich zu einem ganzen Organismus (Level 5). Menschen verbinden sich in Familien/Gruppen (Level 6), Menschengruppen verbinden sich zu einer Stadt/Dorf (Level 7), Städte verbinden sich zu einer Nation (Level 8), Nationen verbinden sich zu internationalen Organisationen/Partnern (Level 9). Möglicherweise verbinden sich irgendwann von Menschen bewohnten Planeten oder Raumstationen zu neuen Strukturen (Level 10). Die Einstufung der einzelnen Systemstufen kann durchaus unterschiedlich aufgelöst werden. Das hier ist also nur eine mögliche Einordnung. Was fällt dabei auf? Es wird immer größer und größer und auch die Menge an Informationsverlust zwischen den Systemen nimmt zu. Leider bin ich kein Mathematiker und habe keine Vorstellung welche Werte in welchem Maß wachsen oder sinken. Kann durchaus sein dass dieses Prinzip der natürlichen Skalierung einen Sättigungspunkt erreicht. Außerdem stellt sich auch die Frage was bei dieser großen Betrachtung eines derart vielfältigen dynamischen Systems noch überhaupt als Einheit begriffen werden kann. Kann man davon sprechen dass die Aktivitäten einzelner Menschen in einer Nation eine Form der parallelisierten Aktivität darstellen? Im groben irgendwie schon. Denn es gibt sie, die Leistung einer Nation in Form der Wirtschaft oder Forschung und diese Nation wird auch zentral durch Gesetze und Maßnahmen geführt. Doch es gilt nicht mehr die strenge Definition der Parallelisierung wie man es aus Computer Architekturen kennt.
Goldenboyx1 schrieb: > Was fällt dabei auf? Es wird immer größer und größer und auch die Menge > an Informationsverlust zwischen den Systemen nimmt zu. Leider bin ich > kein Mathematiker und habe keine Vorstellung welche Werte in welchem Maß > wachsen oder sinken. > Kann durchaus sein dass dieses Prinzip der natürlichen Skalierung einen > Sättigungspunkt erreicht. Lies ISBN: 978-3518389942 . In diesem Werk hat Stanislaw Lem deutlich unterhaltsamer und intellektuell fundierter das Problem der Erkenntnisfähigkeit als Funktion der gesellschaftlichen Entwicklung dargestellt. BTW: Das ist kein Forum für Wannebe-Philosophen und verkannten Literaten.
Fast track to /dev/null schrieb: > Lies ISBN: 978-3518389942 . In diesem Werk hat Stanislaw Lem deutlich > unterhaltsamer und intellektuell fundierter das Problem der > Erkenntnisfähigkeit als Funktion der gesellschaftlichen Entwicklung > dargestellt. Danke, sieht interessant aus. Fast track to /dev/null schrieb: > BTW: > Das ist kein Forum für Wannebe-Philosophen und verkannten Literaten. Benötigt man denn erst ein qualifizierenden Titel als Erlaubnis zum nachdenken? :D Vielleicht füge ich meinen Texten in Zukunft die nachfolgende Anmerkung hinzu damit niemand verletzt oder verwirrt wird. Zu Risiken und Nebenwirkungen lesen sie die Fachliteratur und fragen Sie Ihren Philosophen oder Logiker.
Goldenboyx1 schrieb: > Wäre die Kommunikation so effizient dass sie die Trennung > vollständig kompensieren würde, dann wäre eine Aufteilung > in zwei Systeme gar nicht notwendig gewesen. Das ist ein Widerspruch. Erst sagst du, dass man Systeme ab einer bestimmten Größe notwendigerweise trennen muss, und hier sagst du, dass man sie garnicht hätte trennen müssen. > Man hätte quasi eine Lösung für weitere Skalierung eines > Systems und hätte die maximale Skalierungsgröße nicht erreicht. Es gibt Algorithmen mit verdammt hoher Skalierbarkeit. Ich hab mal mit Lattice-Boltzmann hantiert (Simulation von Fluiden). Sinnvollerweise teilt man das zu simulierende Volumen in kleine Volumenelemente auf, und dann ergeben sich zwei für die Skalierung relevante Eigenschaften: (a) In jedem Volumenelement (abgesehen von den Randelementen, die man anders behandeln muss) finden exakt die gleichen Rechenschritte statt; die Simulation kann also im Gleichschritt erfolgen. (b) Zwischen den einzelnen Volumenelementen kommunizieren ausschließlich die Ränder miteinander. Die Anzahl der Randelemente hängt von der Größe der Volumenelemente ab und kann daher mit der Kommunikationsfähigkeit abgestimmt werden, um Skalierungsbeschränkungen zu vermeiden. Das Verfahren skaliert extrem gut. > Folglich verrät bereits diese Logik dass die Kommunikation > zwischen zuvor zwei zwingend (Systembedingt) getrennten > Systemen mit Informationsverlust behaftet ist, ganz gleich > welcher Art und Effizienz die Kommunikation ist. Nein. Wenn ich in einem Verfahren einmalig kommunizieren muss (z.B. in der Simulation einmal die Aufteilung) und danach vollständig parallel weitermachen kann, dann habe ich weder Einschränkungen in der Kommunikation noch muss ich Informationsverluste hinnehmen. Der Rest deiner Ausführungen basierend auf dieser Prämisse ist somit erstmal hinfällig: Es hängt vom konkreten Problem ab, welche Teile serialisiert werden müssen (also nur begrenzt parallelisierbar sind) und welche Teile nicht. Es gelte Amdahls Gesetz. > Doch es gilt nicht mehr die strenge Definition der > Parallelisierung wie man es aus Computer Architekturen kennt. Wenn du damit anfängst, die Definitionen, auf denen du deine Argumentation aufgebaut hast, aufzuweichen, dann kannst du die Argumentation auch gleich mit entsorgen.
S. R. schrieb: > Das ist ein Widerspruch. Erst sagst du, dass man Systeme ab einer > bestimmten Größe notwendigerweise trennen muss, und hier sagst du, dass > man sie garnicht hätte trennen müssen. Das war eine Überlegung über die Konsequenz. Nämlich der Annahme das die Kommunikation zwischen zwei Systemen die Folgen der Trennung in zwei Systeme vollständig kompensieren kann. So als wäre keine Trennung vorhanden. Wäre dem so, dann wäre die vorherige Trennung in zwei Systeme nicht notwendig gewesen. Die Trennung wäre quasi vor dem Maximum der Skalierung erfolgt. Daraus schlussfolgere ich dann dass zwei Systeme, die wirklich notwendigerweise getrennt wurden, über eine Kommunikation miteinander verfügen, die die Defizite der Trennung nicht vollständig kompensieren können. Wobei ich diesen Defizit als Informationsverlust interpretiere. Soll heißen, System A kann nicht nachvollziehen wieso System B ein bestimmtes Ergebnis mit ihm teilt und umgekehrt. Beispielsweise gibt es bei menschlicher Kooperation aus der Position der einzelnen immer Informationslücken. Beispiel: Ein Team soll ein neues innovatives Flugzeug bauen. Der CNC-Techniker der eine bestimmte Form aus Metall fräsen soll, muss nicht verstehen können, wieso die Mathematiker ausgerechnet diese Form gewählt haben. Und die Mathematiker müssen nicht wissen wie der CNC-Techniker im Detail Bauteile anfertigt. Sie müssen nur soweit miteinander kommunizieren um zu wissen was möglich ist und was nicht. Vielleicht kann man auch sagen dass die Kommunikation zwischen notwendigerweise getrennten Systemen Abstraktionen enthält. Eine Abstraktion ist mit Informationsverlust verbunden. S. R. schrieb: > Nein. Wenn ich in einem Verfahren einmalig kommunizieren muss (z.B. in > der Simulation einmal die Aufteilung) und danach vollständig parallel > weitermachen kann, dann habe ich weder Einschränkungen in der > Kommunikation noch muss ich Informationsverluste hinnehmen. Hmm. Ich ging davon aus dass der parallele Prozess zwischen den einzelnen Recheneinheiten (Systemen) mit Kommunikation verbunden ist. Das also System A zwingend mit System B kommunizieren muss um das Gesamtergebnis zu erzeugen. Eine Parallelisierung die ohne Kommunikation zwischen den einzelnen beteiligten Recheneinheiten auskommt hätte wohl kein Informationsverlust. Da im Grunde jede Recheneinheit für sich selbst arbeitet und keine Daten/Ergebnisse anderer Recheneinheiten benötigt.
Goldenboyx1 schrieb: > Da im Grunde jede Recheneinheit für sich selbst > arbeitet und keine Daten/Ergebnisse anderer > Recheneinheiten benötigt. Für Lattice Boltzmann muss jede Recheneinheit nur mit wenigen anderen Recheneinheiten kommunizieren, und zwar gleichmäßig verteilt. Der Großteil der Daten ist rein lokal. Das Gesamtergebnis ist dann natürlich auf die Recheneinheiten verteilt, aber danach hattest du ja nicht gefragt... Solange der Kommunikationsoverhead aber hinreichend gering ist, kann er vernachlässigt werden.
Goldenboyx1 schrieb: > Warum sind Rechenarchitekturen begrenzt skallierbar? Weil es irgendwann keine ls mehr gibt, um beliebig zu skalllllllllllllieren. Im Ernst, deine Annahme ist falsch, darum kann man deine Frage auch nicht beantworten. Rechnerarchitekturen SIND im Rahmen der im Universum verfügbaren Resourcen unbegrenzt skalierbar, nur ist die Skalierung für die wenigsten Probleme effizient. Gute Beispiele sind Folding@Home und SETI@Home, bei denen der serielle Anteil gegen null geht. Dann gibt es theoretisch noch DNA-Computer, in denen jedes Molekül einen Task ausführt, so dass man in der Größenordnung von 10^23 Rechnungen/(kg Materie) parallel ausführen könnte, aber auch hier wächst der Bedarf an DNA-Molekülen linear mit der benötigten Rechenleistung. Und schließlich die Quantencomputer, deren Rechenleistung sich mit jedem hinzugefügten Qubit verdoppeln kann, vorausgesetzt das Problem passt. Dann gilt für die Rechenleistung P = O(exp(n)), wenn n die verwendeten Resourcen sind. Für bisherige Architekturen incl. DNA-Computer ist P < O(n). Der Unterschied ist atemberaubend, wenn man ihn begreift (aber auch nur dann, und deshalb brauchst du keine Angst haben, dass dir der Atem stockt.)
Kurt schrieb: > Der Unterschied ist atemberaubend, Es bleib trotzdem die Frage, ob das Ergebnis 42 richtig war. Könntest Du jetzt bitte mal nachrechnen? Hast Du die Zahlen im Backup?
oszi40 schrieb: > Es bleib trotzdem die Frage, ob das Ergebnis 42 richtig war. Könntest Du > jetzt bitte mal nachrechnen? Hast Du die Zahlen im Backup? Ob 42 das richtige Ergebnis ist zu welcher Frage? Wenn du mir das sagst, schlage ich schnell nach.
Kurt schrieb: > Ob 42 das richtige Ergebnis ist zu welcher Frage? auf alle Fragen! https://de.wikipedia.org/wiki/42_(Antwort)
Darf ich mal ein Urteil fällen? Lattenschuß!
Hallo, also wenn ich an Grafikkarten denke, da skaliert die Leistung mit jeder Ausbaustufe mit. Die Daten werden häppchenweise passend zerlegt und durch die Recheneinheiten geschickt. Grafikdaten lassen sich eben gut parallelisieren. Bei CPU mit mehreren Kernen sieht das schon anders aus. Für Video/Bild-Bearbeitung klappt das mittlerweise gut. Irgendwas kompilieren auf Linux klappt auch gut. Und dann gibts eben Software die tut sich schwer mit paralleler Kern/Thread Nutzung. Warum auch immer. Entweder bringt es keine Punkte oder die Programmierer tun sich nach Jahren immer noch schwer mit mehreren Kernen. Ich weiß es nicht. Sie müßten ja ihre Software erstmal in passende Häppchen zerlegen die dann vielleicht von mehreren Kernen profitieren. Stell ich mir nicht gerade einfach vor. Wenn 3 Kerne auch einen warten bringt es ja auch nichts.
Veit D. schrieb: > Und dann gibts eben Software die > tut sich schwer mit paralleler Kern/Thread Nutzung. Du kannst ja mal versuchen, einen Emulator zu bauen, der eine CPU korrekt mit mehreren Threads emuliert...
...die Frage ist einfach doof gestellt...wie halt zum Feierabend in der Lieblingskneipe...zum Einen ist "Skaliert" so kein Begriff, der was aussagt...zum Anderen ist auch die Frage nach Rechnerarchitekturen, die skaliert sein mögen, keine Frage. Also Langeweile... Gruß Rainer
Rainer V. schrieb: > keine Frage. Also Langeweile... Das sehe ich ganz anders. Eine Rechnung muß nachvollziehbar sein. dazu gehört auch ein ordentliches Backup für de Fall dass mal was schief geht. Das mag bei der Pi-Berechnung mit einem einfachen Anfangswert noch gut gehen. Aber Säcken von Daten eine Momentaufnahme zur rechten Zeit?
Veit D. schrieb: > Grafikdaten lassen sich eben gut parallelisieren. Du meinst wohl mehrere Rechenkerne auf eine Karte zusammen mit RAM. Versuche mal, 20 Grafikkarten an einem einzigen Monitor und PC anzuschließen und auszulasten, dann merkst du, wo das Problem ist.
Goldenboyx1 schrieb: > Gibt es Ursachen für die limitierte Skalierbarkeit von > Rechenarchitekturen die prinzipieller Natur sind? > Oder kann es eine Rechenarchitektur geben die in der Praxis theoretisch > unendlich skalierbar ist? > > Die Frage die mich interessiert ist ob die Limitierungen rein > technischer Natur sind oder ob man da eher so was wie einen Naturgesetz > hat? oszi40 schrieb: > Das sehe ich ganz anders. Eine Rechnung muß nachvollziehbar sein. dazu > gehört auch ein ordentliches Backup für de Fall dass mal was schief > geht. Das mag bei der Pi-Berechnung mit einem einfachen Anfangswert noch > gut gehen. Aber Säcken von Daten eine Momentaufnahme zur rechten Zeit? Hier, wie so oft oder fast immer, beantworten die Leute ihre eigene (verstandene) Fragestellung. Ist doch eigentlich langweilig!? Wie ich schon sagte, ist die Frage nach limitierter Skalierbarkeit (und der Rest auch) Blödsinn. Ich erwarte also vom TO eine(seine) konkrete Definition von "Skalierbarkeit"...vielleicht lohnt es sich ja dann noch weiterzureden :-) Gruß Rainer
Stefan ⛄ F. schrieb: > Veit D. schrieb: >> Grafikdaten lassen sich eben gut parallelisieren. > > Du meinst wohl mehrere Rechenkerne auf eine Karte zusammen mit RAM. > > Versuche mal, 20 Grafikkarten an einem einzigen Monitor und PC > anzuschließen und auszulasten, dann merkst du, wo das Problem ist. Es wird immer Szenarien geben wo irgendwas limitiert. Wenn du das meinst. Mit einer CPU und 20 GPUs kann man die Auslastung immer noch gut verteilen. Die einzigste Frage ist nur ob die CPU für die Anzahl Karten genug Daten liefern kann. Die Aufgabe muss zur Hardware passen. Beim spielen auf dem Desktop ist das doch wie folgt. Niedrige Grafikeinstellungen > CPU limitiert. Volle Grafikeinstellungen vielleicht noch mit 4k Monitor > GPU limiert. Wobei man bei Ersteren von den Frameraten her nicht meckern kann. Im zweiten Fall kann das unspielbar werden. Daran erkennt man auch das pauschale Aussagen nicht viel bringen. Die TO Frage zur Skalierung verstehe ich so das man unglaublich viel Rechenleistung für ein bestimmten Problem benötigt und dabei die Hardware immer weiter ausbauen möchte. Dabei stellt er sich die Frage bis zu welchen Punkt das Sinn macht. Wenn ich mir dabei die Superrechner der Welt anschaue mit unzähligen CPUs und GPUs, dann werden diese für ganz bestimmte Rechenaufgaben konfiguriert. Steigt der Rechenaufwand wird erweitert. Die Hardware muss zur Aufgabe passen. Ich meine selbst Seti@home u.ä. Projekte zeigen doch auch das mit gezielter Aufgabenverteilung verteilte Rechenleistung gebündelt werden kann. Ob da 1000 Raspis mit machen oder 50 x86 Rechner ... vollkommen egal.
Veit D. schrieb: > Die einzigste Frage ist nur ob die CPU für die Anzahl Karten > genug Daten liefern kann. Ich würde auch hinterfragen, wie man die Ergebnisse der 20 Grafikkarten zu einem Monitor zusammen bringt und wie es sich auf die Effektivität auswirkt, dass sie keinen gemeinsamen RAM zur Verfügung haben.
Hallo, in sehr gut ausgestatteten Spielerechnern können bis zu 4 Grafikkarten parallel geschalten werden. Früher lief das direkt zwischen den Grafikkarten ab. Heute gehts mit über den PCIe Bus. Das skaliert aber nicht 1:1 mit. Also eine dickere Grafikkarte ist besser wie zwei. Nur wenn man schon die fetteste Grafikkarte hat und noch mehr Grafikleistung benötigt, dann muss man eben von den fetten Teilen mehrere einbauen und sich über die Mehrleistung freuen. Auch wenn es sich nicht 1:1 niederschlägt, man hat dennoch mehr Grafikleistung wie alle anderen. Genau das ist der Grund warum in besagten Superrechnern Clusterweise Hardware drin steckt. Der Rest ist die Kunst in Software die Rechenaufgabe gut zu verteilen.
:
Bearbeitet durch User
Es kommt eben immer auf die Aufgabe an. Eine Million Maurer können eine Million 1-Meter-Wände recht schnell mauern. Aber eine Million Maurer können eine einzige 10-Meter-Wand nicht schneller mauern als vielleicht 20..30. Danach stehen sie sich nur noch gegenseitig im Weg rum und der Mörtel wird nicht mehr trocken.
Veit D. schrieb: > Ich meine selbst Seti@home u.ä. Projekte zeigen doch auch das mit > gezielter Aufgabenverteilung verteilte Rechenleistung gebündelt werden > kann. Ob da 1000 Raspis mit machen oder 50 x86 Rechner ... vollkommen > egal. Aktuelle Top 10 : https://www.ingenieur.de/technik/fachbereiche/rekorde/die-schnellsten-supercomputer-der-welt/ die Anzahl der core hat die 100k längst überschritten, erst bei den Chinesen, die ganz nach dem Vorbild ihres eigenen Ameisenstaates, Millionen Kerne Reiskörner zählen lassen. Es ist nicht erkenntlich wie der TO auf das dünne Brett kommt Rechner wären begrenzt skalierbar. Wahrscheinlich hat er sich nicht ernsthaft mit dem Thema beschäftigt. https://www.top500.org/lists/2019/11/ https://www.top500.org/hpcg/lists/2019/11/
Schnell die Liste der Top500 zeigen, ist noch keine Antwort, ob z.B. eine errechnete Zahl "42" stimmt. Da steckt bei Skalierung wohl "etwas" mehr dahinter, als nur CPUs zu zählen. Die SW muß in der Lage sein diese Systeme auch alle sinnvoll zu nutzen und Flaschenhälse zu vermeiden. Besonders interessant wäre aus meiner Sicht die Backupstrategie! Es kann ja durchaus vorkommen, dass ein Teil des gigantischen Systems falsch rechnet oder ausfällt wenn Monate gerechnet werden muß.
A. K. schrieb: > Ein schon recht altes "Gesetz" ist das von Amdahl: > https://de.wikipedia.org/wiki/Amdahlsches_Gesetz Ich möchte nochmal an altes Wissen aus den 60'er Jahren des letzten Jahrhunderts erinnern.
oszi40 schrieb: > Schnell die Liste der Top500 zeigen, ist noch keine Antwort, ob z.B. > eine errechnete Zahl "42" stimmt. Das war ja auch nicht gefragt. > Da steckt bei Skalierung wohl "etwas" > mehr dahinter, als nur CPUs zu zählen. Die SW muß in der Lage sein diese > Systeme auch alle sinnvoll zu nutzen und Flaschenhälse zu vermeiden. Nach Software war auch nicht gefragt, nur nach Hardwarearchitektur und ob man diese wie Lego zusammenstecken kann?! Antwort - man kann, siehe Top 500. > Besonders interessant wäre aus meiner Sicht die Backupstrategie! Es kann > ja durchaus vorkommen, dass ein Teil des gigantischen Systems falsch > rechnet oder ausfällt wenn Monate gerechnet werden muß. In der Grundschule gepennt? Das heisst nicht Backup-strategie, sondern 'Kontrollrechnung' respektive 'Mathematische Beweisführung der Existenz einer Lösung'(ok, das wäre dann nicht mehr Grundschule). Bestandteil davon ist die Beweisführung, das der Algorithmus auch in endlicher Rechenzeit konvergiert. Erst dann mach es sinn den Datensatz nach einem Iterationsschritt non-volatil zwischenzuspeichern. Numerische Stabilität ist auch ein Thema, weil ja bei der Computer-representation einer reelen Zahl systembedingt Rundungswehler™ auftreten. https://de.wikipedia.org/wiki/Stabilit%C3%A4t_(Numerik) https://en.wikipedia.org/wiki/Numerical_analysis#Discretization Für engagierte Studenten sei angeraten sich in die Arbeiten von János Lajos von Margitta zu vertiefen: https://en.wikipedia.org/wiki/Von_Neumann_stability_analysis
Stefan ⛄ F. schrieb: > Veit D. schrieb: >> Die einzigste Frage ist nur ob die CPU für die Anzahl Karten >> genug Daten liefern kann. > > Ich würde auch hinterfragen, wie man die Ergebnisse der 20 Grafikkarten > zu einem Monitor zusammen bringt und wie es sich auf die Effektivität > auswirkt, dass sie keinen gemeinsamen RAM zur Verfügung haben. Prinzipiell geht so was ja schon, wenn auch nicht mit 20, aber immerhin mit 4 Karten: https://de.wikipedia.org/wiki/Scalable_Link_Interface#4-way_SLI Das mit dem fehlenden gemeinsamen RAM wird hier einfach so gehandhabt, dass alle Karten die selben Daten in ihrem jeweiligen RAM haben. Die Begrenzung liegt dabei aber eher darin, dass man irgendwann Schwierigkeiten bekommt, ein Board zu finden, auf das die alle drauf passen und dass es so teuer wird, dass sich das keiner leisten kann bzw. will.
:
Bearbeitet durch User
Berufsrevolutionär schrieb: > In der Grundschule gepennt? Das heisst nicht Backup-strategie, sondern > 'Kontrollrechnung' In der IT bezeichnet das englische Wort "Backup" sowohl Sicherungskopien als auch Reserve-Systeme. Kontroll-Systeme können helfen, falsche Berechnungen zu erkennen. Andererseits vertrauen die meisten darauf, dass Intel Prozessoren korrekt rechnen. Meistens kontrolliert man die Algorithmen vorher mit kleinen Datenmengen (Unit Tests) und wendet sie danach in großem Stil an. Kontrolliert wird dann nur noch, ob die Systeme laufen und Ergebnisse produzieren.
Stefan ⛄ F. schrieb: > Berufsrevolutionär schrieb: >> In der Grundschule gepennt? Das heisst nicht Backup-strategie, sondern >> 'Kontrollrechnung' > > In der IT bezeichnet das englische Wort "Backup" sowohl Sicherungskopien > als auch Reserve-Systeme. An der referenzierten Stelle wird aber kein Reserve system beschreiben, sondern schon eins was BackUp im Sinne von "Sicherungskopie" benutzt. Gemeint ist aber wohl eher etwas im Sinne von "Fail-Safe Point" im deutschen eher selten als "sichere Rückzugsposition" genannt -> ein konsistentes Zwischenergebniss das bei einer Unterbrechung (platzsparend) abgespeichert wird um später die Berechnung mit dem Zwischenergebniss als Startwert wieder aufzunehmen. > Kontroll-Systeme können helfen, falsche Berechnungen zu erkennen. > Andererseits vertrauen die meisten darauf, dass Intel Prozessoren > korrekt rechnen. Meistens kontrolliert man die Algorithmen vorher mit > kleinen Datenmengen (Unit Tests) und wendet sie danach in großem Stil > an. Kontrolliert wird dann nur noch, ob die Systeme laufen und > Ergebnisse produzieren. Naja das ist aber sehr vereinfacht dargestellt, da sind noch Kontrollmechanismen eingebaut ob Verfälschung auftrete, beispielsweise CRC/ECC. Und Abbruchbedingungen (Schleifenzähler) falls sich eine Iteration 'festfährt'. Eine ähnliche Situation hat man beim Watchdog, da vertraut man auch nicht drauf, das alles im grünen Bereich ist, solange die CPU schwitzt. Gerade beim parallelen System ist es wichtig automatisch Systemverklemmungen (deadlock) aufzulösen respektive zu erkennen (Spaghetti-essende Philosophen: https://www.google.com/search?client=firefox-b-d&q=Spaghetti+essende+Philosophen ) Das die Mathematik hinter dem Algorithmus stimmt, sichert man in der Praxis bequemerweise damit ab, das man programmbibliotheken benutzt, die als überprüft gelten und schreibt möglichst keinen Algo selbst. 'Gecheckt' wird dann an corner stones, 'Eckpunkttest').
Berufsrevolutionär schrieb: > da sind noch Kontrollmechanismen eingebaut ob Verfälschung auftrete Wo ist "da"? Wir diskutieren hier ganz allgemein von IT Systemen. Es gibt sehr viel mehr als eine Variante, diese zu realisieren. Ich kann genau so gut sagen, dass es "da" überhaupt keine Kontroll-Mechanismen gibt und das sogar mit einem konkreten Beispiel belegen. Es scheint mit ziemlich sinnlos, hier einen allgemeinen Standard beschrieben zu wollen. Des gibt es nicht und wird es nie geben. Berufsrevolutionär schrieb: > Eine ähnliche Situation hat man beim Watchdog, da > vertraut man auch nicht drauf, das alles im grünen Bereich ist, solange > die CPU schwitzt. Wenn ein Watchdog nicht auslöst, weiß man nur, dass das Programm noch läuft. Ob es auch tatsächlich noch tut, was es soll, muss man anders heraus finden. Berufsrevolutionär schrieb: > Das die Mathematik hinter dem Algorithmus stimmt, sichert man in der > Praxis bequemerweise damit ab, das man programmbibliotheken benutzt, die > als überprüft gelten und schreibt möglichst keinen Algo selbst. Ich meine damit auch nicht fertige Algorithmen von der Stange, sondern individuelle Geschäftslogik - vom Kunden spezifizierte Algorithmen. Das ist der Part, mit dem ich meine Brötchen verdiene. Die muss ich selber testen, bzw. meine Kollegen aus der Testabteilung. Es gibt keinen Standard Algorithmus, der vorgibt, was passieren soll, wenn eine SEPA Lastschrift vom Online Handel nachträglich widerrufen wird - nur um ein Beispiel zu nennen.
Stefan ⛄ F. schrieb: > Berufsrevolutionär schrieb: >> da sind noch Kontrollmechanismen eingebaut ob Verfälschung auftrete > > Wo ist "da"? > > Wir diskutieren hier ganz allgemein von IT Systemen. Es gibt sehr viel > mehr als eine Variante, diese zu realisieren. Ich kann genau so gut > sagen, dass es "da" überhaupt keine Kontroll-Mechanismen gibt und das > sogar mit einem konkreten Beispiel belegen. Und ich kann das Gegenteil belegen: https://www.heise.de/newsticker/meldung/Hauptspeicherfehler-sehr-viel-haeufiger-als-bisher-angenommen-828883.html In Server Hardware ist es de-facto 'mandatory' das zumindest auf Speicher-/Übertragungs-fehler kontrolliert wird. Wenn wir dagegen von Rechen-fehler sprechen, also das die CPU sich verrechnet ist die Situation etwas anders. Da kontrolliert der CPU-Hersteller mit aufwendigen Tests, das sein Design und Fertigung passt und beim booten/powerOn-Diagnose sollte wenigstens ein Test auf korrekte Funktion gefahren werden. So wie jeder Physiker/Messtechniker sein Equipment regelmäßig checkt und kalibriert. > Es scheint mit ziemlich sinnlos, hier einen allgemeinen Standard > beschrieben zu wollen. Des gibt es nicht und wird es nie geben. Es gibt soviele Standards da bin ich mir ziemlich sicher das in einem steht wie genau Mess- und rechenergebnisse zu kontrollieren sind. Jedenfalls gibt es das für Medizintechnik, Fluggeräte etc. warum nicht auch für WaldUndWiesen- Rechenzentren?! Da wäre bspw die DIN EN 50600 aka ISO/IEC TS 22237 (obwohl es sich bei denen eher um Absicherung der Verfügbarkeit statt um Exatheit geht), aber man denke auch an die Berechnungsvorschriften in den Grundlagen-normen oder die DIN ISO 5725 (Genauigkeit Messverfahren). Und ganz sicher unterliegen auch Rechenzentren der Qualitätssicherung, auch wenn das nicht allen Mitarbeitern voll bewusst ist.
Berufsrevolutionär schrieb: > Und ich kann das Gegenteil belegen: > Link: dass DRAM-Fehler sehr viel häufiger auftreten als bisher erwartet Das ist nicht neu. Das fiel mir schon im letzten Jahrtausend bei Lösungen mit 2 CPUs auf. Je mehr CPUs im Rennen sind, desto zeitkritischer wird der Zugriff oder die Fehlerhäufigkeit. Diese RAM liefen in 1-CPU-Maschinen noch fehlerfrei. Deswegen auch meine Zweifel, daß hoch skalierte Rechenleistung immer garantiert fehlerfrei ist.
Eigentlich ist es ganz einfach: Multiprozessorsysteme müssen immer eine Kommunikation zwischen den Prozessoren(Prozesen) durchführen, um die verteilten Threads bzw die Ergebnisse wieder zusammenzuführen. Dieser Aufwand wächst exponentiell mit der Prozessorzahl. Damit ist für jede Bus- bzw Verknüpfunsarchitektur von Superrechnern bereits im Vorraus die maximal sinnvolle Anzahl von Prozessoren ermittelbar. Man kann das Probem durch geeignete Programmierung minimieren, aber nicht beseitigen.
Hallo, Roland, du bringst das auf den Punkt was wir hier mit heißen Brei bequatschen. :-) > Stefan F. > In der IT bezeichnet das englische Wort "Backup" sowohl Sicherungskopien > als auch Reserve-Systeme. Nicht ganz, man muss unterscheiden zwischen Backup und Redundanz. Wenn mir zu Hause der Rechner kaputt geht, dann wäre es gut ich habe ein Backup meiner wichtigsten Daten. Alles was fliegt ist mit Hardware Redundanz besser bedient. Das Thema triftet jedoch ab ...
der limitierende Faktor ist der Typ davor...
Roland E. schrieb: > Multiprozessorsysteme müssen immer eine > Kommunikation zwischen den Prozessoren(Prozesen) durchführen, um die > verteilten Threads bzw die Ergebnisse wieder zusammenzuführen. Dieser > Aufwand wächst exponentiell mit der Prozessorzahl. Dass der Aufwand exponentiell wächst, halte ich für übertrieben. Ein bisschen steiler als linear wird aber wohl sein. Diese Kommunikation kann man unter Umständen verteilen, indem man sie in einer Baumstruktur organisiert. Beispiel: In einem Konzern, der Autos produziert, kommuniziert nicht jeder Facharbeiter direkt mit dem Geschäftsführer um die Arbeit zu koordinieren.
Roland E. schrieb: > Dieser > Aufwand wächst exponentiell mit der Prozessorzahl. Nein, Gegenbeispiel Topologie: daisy chain. https://de.wikipedia.org/wiki/Daisy_Chain Weiters gegenbeipiel Topologie: binary tree https://www.researchgate.net/publication/303862548/figure/fig5/AS:668313789149207@1536349832676/Binary-tree-topology.png Grad die Baumstruktur ist gut für fein granuläre Skalierung geeignet. Andere herstellerspezifische Süppchen: https://www.fujitsu.com/global/about/resources/news/press-releases/2014/0715-02.html https://www.hpcwire.com/2018/07/09/dragonfly-delivers-performance-for-canadas-fastest-supercomputer/
Leadership vor die Säue schrieb: > Gegenbeispiel Topologie: daisy chain. Ganz so einfach wirds wohl nicht. Eine Kette ist nur so gut wie das schwächste Glied. > gegenbeipiel Topologie: binary tree Auch der schönste Baum hat eine Wurzel, die ihn versorgen muß.
oszi40 schrieb: > Auch der schönste Baum hat eine Wurzel, die ihn versorgen muß. Ja, aber die Wurzel muss nicht die gesamte Last der Koordinierung aller Knoten tragen.
Roland E. schrieb: > Multiprozessorsysteme müssen immer eine Kommunikation > zwischen den Prozessoren(Prozesen) durchführen, um die > verteilten Threads bzw die Ergebnisse wieder zusammenzuführen. Beim Lattice Boltzmann-Verfahren trägt jeder Prozessor mit genau seinem simulierten Areal (plus einer vorher bekannten Überlappungskonstante) zum Ergebnis bei... > Dieser Aufwand wächst exponentiell mit der Prozessorzahl. ...daraus folgt, dass der für das Problem notwendige Kommunikationsaufwand linear (plus einer Konstante) ist. Also O(n). Ich habe das auf einer Rechnerarchitektur mit verteiltem Speicher gemacht, da war nichts exponentiell. Im Gegenteil, das Verfahren skalierte (im Rahmen der Architektur) exakt linear-plus-Konstante - wie auch von der Theorie her zu erwarten. Selbst das Auslesen der Ergebnisse skalierte linear mit der Anzahl der Prozessoren (wegen der linear zunehmenden Datenmenge). Die Topologie war übrigens ein 2D-Mesh.
:
Bearbeitet durch User
S. R. schrieb: > Lattice Boltzmann-Verfahren Das war eine schöne Aufgabe, die gut verteilt bearbeitet werden kann. Manche Prozesse sind jedoch etwas zeitkritischer. Dann wird Fehlerbearbeitung und Backup etwas interessanter.
Stefan ⛄ F. schrieb: > Andererseits vertrauen die meisten darauf, dass Intel Prozessoren > korrekt rechnen. war ja auch NIE anders, oder gab es mal Intel Prozessoren die etwa falsch rechneten?
Stefan ⛄ F. schrieb: > Beispiel: In einem Konzern, der Autos > produziert, kommuniziert nicht jeder Facharbeiter direkt mit dem > Geschäftsführer um die Arbeit zu koordinieren. und das soll der Beweis sein das da nichts schiefläuft? Gerade weil angeblich nicht alles kommuniziert wurde gab es angeblich Schummelsoftware. Glauben muss man das nicht.
Joachim B. schrieb: > Stefan ⛄ F. schrieb: >> Andererseits vertrauen die meisten darauf, dass Intel Prozessoren >> korrekt rechnen. > > war ja auch NIE anders, oder gab es mal Intel Prozessoren die etwa > falsch rechneten? Mir fehlt das Ironietag. Such mal nach Pentium Bug. Intel hat damals garantiert diese bis in alle Ewigkeit umzutauschen.
Joachim B. schrieb: > Stefan ⛄ F. schrieb: >> Andererseits vertrauen die meisten darauf, dass Intel Prozessoren >> korrekt rechnen. > > war ja auch NIE anders, oder gab es mal Intel Prozessoren die etwa > falsch rechneten? Genau genommen, rechneten die nicht falsch sondern ungenau, der FDIV-Bug führte bei einigen Operanden-kombinationen das mit einfacher statt mit doppelter Genauigkeit gerechnet wird. Ist jetzt also so das bei einer Spannungsteilerberechnung der Pentium 5,612340000 ausspuckt, wo 5,612345678 korrekt wäre. Intel hatte den Fehler in der ROM-Maske auch selber und unabhängig vom Kunden entdeckt und korrigiert. insofern besser wals bei der Softwareentwicklung wo der Kunde die Fehler für den den Hersteller finden und reporten muss. https://www.heise.de/ct/artikel/20-Jahre-FDIV-Bug-Die-Hintergruende-2438233.html
Berufsrevolutionär schrieb: > Genau genommen, rechneten die nicht falsch sondern ungenau, der FDIV-Bug > führte bei einigen Operanden-kombinationen das mit einfacher statt mit > doppelter Genauigkeit gerechnet wird. Es hing von den Operanden ab, wo im Ergebnis der Fehler auftrat, wie gross die Ungenauigkeit also war. Mit Berechnung in einfacher oder doppelter Genauigkeit hatte das nichts zu tun. Einfache Kehrwertberechnung reichte aus, um falsche Ergebnisse zu produzieren.
A. K. schrieb: > Einfache Kehrwertberechnung reichte aus, > um falsche Ergebnisse zu produzieren. Wurde diese CPU zufällig für Superrechner eingesetzt? "Eine ideale Möglichkeit Fehler zu vergrößern" 8-) Wer rechnet jetzt nach?
A. K. schrieb: > Mit Berechnung in einfacher oder > doppelter Genauigkeit hatte das nichts zu tun. Doch, es hat was mit Genauigkeit zu tun, weil die Tabelle zur nachfolgenden Genauigkeitsverbesserung fehlerhaft war. Die ersten Stellen werden korrekt berechnet, die folgenden fehlerhaft. Das passt zwar nicht korrekt auf einfache und doppelte Genauigkeit wie im FPU-standard IEEE 754 definiert, aber man kann den FDIV Bug schon als Genauigkeitsverlust beschreiben. Jedenfalls interpretiere ich so den verlinkten Text: "... lag der relative Fehler nur bei 10e-9, es gab aber noch schlimmere Zahlenpaare mit Divisionsfehler im Bereich von über 10e-5". "liefert pro Rechenschritt jeweils zwei Bits des Quotienten. Bei jedem Rechenschritt verwendet der Prozessor die sogenannte PD-Lookup-Table und schaut anhand der oberen Mantissenbits des jeweils verbleibenden Restes (6 Bits) und des Divisors (5 Bits) nach, wie der Quotient weitergeht. Nur wenn der Divisor eines der fünf betroffenen Muster aufweist, kann sich überhaupt ein Fehler ergeben, und auch nur dann, wenn *im Verlaufe der weiteren Rechenschritte* der verbleibende Rest auch auf die fehlerhaften Einträge verweist." Was aber natürlich nich bedeutet, das der Genauigkeitsverlust irrelevant ist, insbesonders bei Weiterverarbeitung von Zwischenwerten.
Berufsrevolutionär schrieb: > Doch, es hat was mit Genauigkeit zu tun, weil die Tabelle zur > nachfolgenden Genauigkeitsverbesserung fehlerhaft war. Natürlich hat das etwas mit Genauigkeit zu tun, aber nicht mit einfacher oder doppelter, zumal x87 weder single noch double precision rechnet, sondern extended, mit 80 Bits insgesamt, wenn man das nicht eigens drosselt. > Jedenfalls interpretiere ich so den verlinkten Text: So ganz präzise war Andreas Stillers Erinnerung offenbar nicht mehr, als er den Artikel schrieb. Ich hatte die 23 Kehrwerte, keine Zahlenpaare, nicht Tim Coe zugeschickt, sondern die landeten in einem Usenet-Forum, ein Wert davon war zur Kontrolle jener, der meinem P90 den Anlass gab, über Nacht ein paar Divisionen zu rechnen.
:
Bearbeitet durch User
oszi40 schrieb: >> Lattice Boltzmann-Verfahren > Das war eine schöne Aufgabe, die gut verteilt > bearbeitet werden kann. > Manche Prozesse sind jedoch etwas zeitkritischer. Dann wird > Fehlerbearbeitung und Backup etwas interessanter. Sicherlich. Aber es ist ein gutes Beispiel für eine reale Aufgabe, die eben an jeder Stelle extrem gut skaliert und (passende Hardware vorausgesetzt) das auch real tut. Schlicht, weil kaum Kommunikation zwischen den Cores nötig ist.
Stefan ⛄ F. schrieb: > Roland E. schrieb: >> Multiprozessorsysteme müssen immer eine >> Kommunikation zwischen den Prozessoren(Prozesen) durchführen, um die >> verteilten Threads bzw die Ergebnisse wieder zusammenzuführen. Dieser >> Aufwand wächst exponentiell mit der Prozessorzahl. > > Dass der Aufwand exponentiell wächst, halte ich für übertrieben. Das ist korrekt. > Ein bisschen steiler als linear wird aber wohl sein. Und das beschönigt. Betrachten wir einfach mal zwei triviale Spezialfälle: 1. ein absolut universeller, absolut symmetrischer verteilter Cluster. Jeder Knoten muß mit jedem anderen Knoten direkt verbunden sein. Dann steigt der Aufwand für die Verbindungen quadratisch mit der Anzahl der Knoten. Mehr als quadratisch geht also nicht. Offensichtlich skaliert die Hardware hier nicht. Dafür läuft jeder verteilte Algorithmus in maximal möglicher Geschwindigkeit. 2. ein quadratisches 2-D Gitter. Jeder Knoten hat Verbindungen zu seinen unmittelbaren Nachbarn (das sind 4). Jetzt steigt der Aufwand für die Verbindungen linear mit der Anzahl der Knoten. Das kann man skalierbar bauen. Dafür laufen jetzt nur noch solche Algorithmen schnell, bei denen Kommunikation nur mit den unmittelbaren Nachbarn nötig ist. Kommunikation nach weiter weg geht zwar, braucht aber entsprechend länger. Computergrafik (2D) geht damit; Wetter (3D-Gitter) nur noch schlecht. Algorithmen, bei denen potentiell jeder Thread mit jedem anderen Thread kommunizieren können muß, nur noch sehr schlecht. Schon vor 40 Jahren hat man Transputer gebaut. Nicht zufällig hatte da jeder Knoten 4 Links zur Kopplung mit anderen Knoten.
S. R. schrieb: > Beim Lattice Boltzmann-Verfahren trägt jeder Prozessor mit genau seinem > simulierten Areal (plus einer vorher bekannten Überlappungskonstante) > zum Ergebnis bei... Mal angenommen, du hast mehr Prozessoren als simulierte Areale. Wie skaliert es dann?
Axel S. schrieb: > Schon vor 40 Jahren hat man Transputer gebaut. Nicht zufällig hatte da > jeder Knoten 4 Links zur Kopplung mit anderen Knoten. ...und die Transputer sind aber doch in der Versenkung verschwunden?! Es ist doch bekannt, dass sich bestimmt Algorithmen gut parallelisieren lassen...andere eben nicht...und die benötigen massiv Kommunikation zwischen den Kernen...selbst, wenn sie nur virtuell sind. Also wiederhole ich meine Frage: What solls... Gruß Rainer
Rolf M. schrieb: >> Beim Lattice Boltzmann-Verfahren trägt jeder Prozessor mit >> genau seinem simulierten Areal (plus einer vorher bekannten >> Überlappungskonstante) zum Ergebnis bei... > > Mal angenommen, du hast mehr Prozessoren als simulierte Areale. > Wie skaliert es dann? Wenn ich mehr Prozessoren habe als zu simulierende Areale, dann habe ich die Aufteilung des Raumes versaut. Im Normfall kenne ich die Anzahl der Prozessoren ja vorher, kann also passend aufteilen. Dynamisch neu aufteilen geht sicherlich auch, damit habe ich mich aber nicht näher befasst. Ist aber unüblich, weil der zu simulierende Zeitraum üblicherweise auch vorher bekannt ist, also werden die Ressourcen passend reserviert. Allerdings kann es passieren, dass das Verhältnis von Rechenleistung zu Kommunikationsaufwand ungünstig ist (war es in meinem Fall, da mangels Speicher die Areale zu klein waren). Das macht das Verfahren zwar langsam, aber ändert grundsätzlich nichts an der Skalierbarkeit.
:
Bearbeitet durch User
S. R. schrieb: > Im Normfall kenne ich die Anzahl der > Prozessoren ja vorher, kann also passend aufteilen. In meinem Umfeld startet man immer mit der kleinsten wirtschaftlich sinnvollen Einheit und rüstet bei Bedarf auf. Während der Entwicklung ist noch gänzlich unbekannt, wie viel Last und wie viel Hardware kommen wird. Skalierbarkeit wird also von Anfang an ins Design eingeplant, aber nur so weit implementiert, wie es keine großartigen Mehraufwand bedeutet. Das kann man dann später immer noch erweitern. Das läuft dann natürlich mit gewissen Einschränkungen ab, die wir bisher aber noch nie bereut haben. Dass wir Hardware plötzlich um Faktor 10 oder mehr vergrößern mussten, hatten wir noch nicht. So Weitsichtig sind unsere technischen Projektleiter schon. Zudem folgen wir auch den Grundsätzen: * Keep it Simple * Keine voreiligen Optimierungen Denn auf Performance optimierte Geschäftslogik ist in den allermeisten Fällen schwerer lesbar und wartbar, als schnurgerade gerade herunter programmierte Sachen. Außerdem bringen viele Optimierungen (z.B. Caches + Multi-Threading) Seiteneffekte, die sporadisch auffallen und man nicht immer korrekt vorher gesehen hat. Ein Punkt, den Berater bei uns immer wieder ansprechen sind unsere Datenbanken der Web-basierten Geschäftsanwendungen. Die von uns verwendeten Billiglösung sind nicht skalierbar und daher single-point-of-failure. Das war aber noch nie ein Problem. Bei Engpässen genügte es bislang immer, einzelne Tabellen auf separate Maschinen zu verschieben oder Report mit einer Kopie der Arbeits-Datenbank zu generieren. Das ist einfach, billig und jeder versteht es. Wenn wir doch mal etwas skalierbares brauchen, wissen wir, an wen wir uns wenden müssen (z.B. Oracle). Bis dahin sparen wir uns die Kosten und Fachleute.
Stefan ⛄ F. schrieb: >> Im Normfall kenne ich die Anzahl der >> Prozessoren ja vorher, kann also passend aufteilen. > In meinem Umfeld startet man immer mit der kleinsten > wirtschaftlich sinnvollen Einheit und rüstet bei Bedarf auf. Webdatenbanken sind eine andere Umgebung als physikalische Simulationen. Da sind sowohl das Problem als auch die Hardware vorher bekannt (bzw. werden so gewählt, dass sinnvoll simuliert werden kann). Man weiß auch relativ genau, wie lange eine gewisse Anzahl an Simulationsschritten dauert (Theorie sowie frühere Simulationen), und was man eigentlich simulieren will. Stefan ⛄ F. schrieb: > Dass wir Hardware plötzlich um Faktor 10 oder mehr > vergrößern mussten, hatten wir noch nicht. Zumindest in der Umgebung, in der ich damals aktiv war, war das eigentlich auch kein Thema. Entweder, es wurden vorhandene Cluster gemietet (und das Problem skaliert), oder dem Bedarf angepasste neue Cluster gebaut. Stefan ⛄ F. schrieb: > Wenn wir doch mal etwas skalierbares brauchen, wissen wir, > an wen wir uns wenden müssen (z.B. Oracle). ...oder vielleicht auch nicht. ;-)
Stefan ⛄ F. schrieb: > Wenn wir doch mal etwas skalierbares brauchen So ganz einfach wirds wohl nicht, sobald die größere Datenmenge auch gespeichert werden soll. Irgendwie muß sie ja auch flüssig transportiert werden...
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.