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