Wird Software jetzt noch fehleranfälliger, wenn jetzt immer mehr versuchen Mulhithreading einzusetzen?

Hi. Ja.

sunshineCoder schrieb:

Wird Software jetzt noch fehleranfälliger, wenn jetzt immer mehr versuchen Mulhithreading einzusetzen?

Hi. Ja.

Hi. Warum?

Gregor schrieb:

sunshineCoder schrieb:

Wird Software jetzt noch fehleranfälliger, wenn jetzt immer mehr versuchen Mulhithreading einzusetzen?

Hi. Ja.

Hi. Warum?

Alleine schon deshalb, weil Fehler durch Multithreading schwerer erkannt und debuggt werden können. Da kommt halt eine gewisse nichtdeterministische Komponente in die Programme. Was macht man denn, wenn ein Fehler durch fehlende Synchronisierung oder so nur alle 1000 Programmdurchläufe einmal auftritt. Und man ihn somit praktisch nicht reproduzieren kann?

Alternativ kann man natuerlich auch Ansaetze wie zB Erlang verfolgen. Ueber kurz oder lang werden wir aber fuer die meisten Anwendungen von den haendischen locks wegkommen.

Shared-State-Multithreading (was leider extrem verbreitet ist) ist nur einfach böse!

Shared-State-Multithreading (was leider extrem verbreitet ist) ist nur einfach böse!

Was genau war noch die Alternative?

rüdiger schrieb:

Shared-State-Multithreading (was leider extrem verbreitet ist) ist nur einfach böse!

Was genau war noch die Alternative?

Die Übermittlung von Nachrichten.

Die Übermittlung von Nachrichten.

Deadlocks sind da aber genauso möglich -- auch wenn lock drin steht.

Ich glaube nicht, dass Message-Passing die Lösung aller Probleme ist. Ich denke eher, dass da neue Paradigmen und Idiome hermüssen. Die best-practices der parallelen Programmierung sind leider noch recht wenig verbreitet.

Außerdem vermute ich, dass nur ein sehr geringer Teil der Entwickler in der Lage ist ein Programm zu schreiben, das wirklich skaliert.

rüdiger schrieb:

Die Übermittlung von Nachrichten.

Deadlocks sind da aber genauso möglich -- auch wenn lock drin steht.

Ich glaube nicht, dass Message-Passing die Lösung aller Probleme ist. Ich denke eher, dass da neue Paradigmen und Idiome hermüssen. Die best-practices der parallelen Programmierung sind leider noch recht wenig verbreitet.

Außerdem vermute ich, dass nur ein sehr geringer Teil der Entwickler in der Lage ist ein Programm zu schreiben, das wirklich skaliert.

Naja, das wirkliche Problem mit Threads ist der Shared State. Der erzeugt die locking Probleme. Denn die wenigen Resourcen die man wirklich sharen will, kann man recht einfach locken. Die Probleme faengt man sich bei den Sachen ein die man unabsichtlich Shared.

Wenn wir uns zB Erlang ansehen: jede Funktion ist ein Prozess. Man hat per Definition keine Locking Probleme - denn wenn man etwas sharen will, muss man es explizit machen.

Da kommen wir dann zu dem naechsten Problem: Seiteneffekte von Funktionen. Die killen dir die Parallelisierbarkeit. Man kann recht simpel einen grossteil des Codes parallelisieren wenn man auf Seiteneffekte in Funktionen verzichtet - der Trick ist naemlich dem Compiler oder der Plattform das Parallelisieren zu ueberlassen. C++ ist hier leider furchtbar, da jede Funktion Seiteneffekte haben kann. Deshalb ist soetwas einfaches wie std::for_each nicht parallelisierbar.

Da gefaellt mir zB der ParallelFX Ansatz. Man schreibt:

Parallel.forEach(vector, delegate(T elem) {
  foo(elem);
});

Wo man aktuell haengt ist eben zu garantieren dass foo keine Seiteneffekte hat die den vector betreffen. Aber es ist ein Ansatz - denn viel Code laesst sich so erstmal parallelisieren ohne dass man gross etwas tun muss. Wichtig ist vorallem dass man nur noch Semantisch sagt "das hier ist zu parallelisieren" - wie genau das dann ablaeuft soll sich die Plattform selber aussuchen (zB auf einem 8 Kern System wuerde man deutlich mehr Threads erstellen als auf einem 2 Kern System).

Der Weisheit letzter Schluss ist es nicht, aber ParallelFX ist ziemlich interessant.

Wenn wir uns zB Erlang ansehen: jede Funktion ist ein Prozess. Man hat per Definition keine Locking Probleme - denn wenn man etwas sharen will, muss man es explizit machen.

Das heißt es ist unmöglich in Erlang eine Situation A wartet auf Nachricht von B und B wartet auf Nachricht von A zu erzeugen?

Da kommen wir dann zu dem naechsten Problem: Seiteneffekte von Funktionen. Die killen dir die Parallelisierbarkeit. Man kann recht simpel einen grossteil des Codes parallelisieren wenn man auf Seiteneffekte in Funktionen verzichtet - der Trick ist naemlich dem Compiler oder der Plattform das Parallelisieren zu ueberlassen.

Ich denke nicht, dass funktionale Programmierung in Zukunft einen wesentlich größteren Anteil haben wird. Die Programme sind zwar leicht parallelisierbar, aber die Denkweise ist trotzdem sehr ungewohnt.

C++ ist hier leider furchtbar, da jede Funktion Seiteneffekte haben kann. Deshalb ist soetwas einfaches wie std::for_each nicht parallelisierbar.

Da gefaellt mir zB der ParallelFX Ansatz. Man schreibt:

Parallel.forEach(vector, delegate(T elem) {
  foo(elem);
});

Wo man aktuell haengt ist eben zu garantieren dass foo keine Seiteneffekte hat die den vector betreffen. Aber es ist ein Ansatz - denn viel Code laesst sich so erstmal parallelisieren ohne dass man gross etwas tun muss. Wichtig ist vorallem dass man nur noch Semantisch sagt "das hier ist zu parallelisieren" - wie genau das dann ablaeuft soll sich die Plattform selber aussuchen (zB auf einem 8 Kern System wuerde man deutlich mehr Threads erstellen als auf einem 2 Kern System).

Der Weisheit letzter Schluss ist es nicht, aber ParallelFX ist ziemlich interessant.

Da finde ich zum Beispiel MCSTL ganz nett. Das ist ein recht ähnlicher Ansatz, nur dass eben einfach die STL-Algorithmen ersetzt werden. Damit kann man viele C++-Programme durch einfaches neu übersetzen mehrkernfähig machen.

Das heißt es ist unmöglich in Erlang eine Situation A wartet auf Nachricht von B und B wartet auf Nachricht von A zu erzeugen?

Wenn man dumm ist, dann schon. Aber da muss man sich schon ein bisschen anstrengen.

Ein Erlang wartet A auch nicht auf Nachricht _von_ B sondern auf _Nachricht_ B. Diese Nachricht kann absolut jeder schicken.

Ich denke nicht, dass funktionale Programmierung in Zukunft einen wesentlich größteren Anteil haben wird. Die Programme sind zwar leicht parallelisierbar, aber die Denkweise ist trotzdem sehr ungewohnt.

Zumindest eine Menge Konzepte fliessen in die Mainstream Sprachen ein. zB Funktionsobjekte sind nicht mehr wegzudenken aus modernen Sprachen.

Da finde ich zum Beispiel MCSTL ganz nett. Das ist ein recht ähnlicher Ansatz, nur dass eben einfach die STL-Algorithmen ersetzt werden. Damit kann man viele C++-Programme durch einfaches neu übersetzen mehrkernfähig machen.

Der Ansatz ist ganz ok, aber wie auch hier kann die implementierung nicht garantieren dass keine Seiteneffekte den Code invalid machen.

Und genau das ist der Punkt wo es IMHO noch am meisten zu tun gibt.

Wenn man dumm ist, dann schon. Aber da muss man sich schon ein bisschen anstrengen.

hm, genau sowas kann man auch über locks sagen. das konzept ist ja auch ganz einfach. die schwierigkeiten zeigen sich erst bei der umsetzung in komplexeren umgebungen. dass man statt auf A auf Nachricht A wartet hilft da auch nicht viel, schließlich könnte A einfach der einzige sein, der Nachricht A überhaupt verschicken kann... ich glaub nicht so recht an ein kostenlose deadlock-freiheit.

Shade Of Mine schrieb:

Zumindest eine Menge Konzepte fliessen in die Mainstream Sprachen ein. zB Funktionsobjekte sind nicht mehr wegzudenken aus modernen Sprachen.

In der Tat. Die sind auch so unheimlich praktisch, weil man nämlich gleich noch zusätzlich zur Funktion einen zustand mitgeben und manipulieren kann. Genau das, was in der funktionalen Welt aber nicht erlaubt ist.

Die automatische Parallelisierung ist sicherlich einen Versuch wert. Allerdings denke ich, dass das noch ein weiter Weg wird. Kurzfristig ist sicherlich das Parallelisieren der Grundalgorithmen der vielversprechendere Weg. Und wenn es wirklich um pure Leistung geht, dann müssen auch die Algorithmen von Hand parallelisiert werden. Schließlich ist es oft auch für Menschen nicht offensichtlich wie sich eine Aufgabe parallelisieren lässt. Da können wir es kaum von der Plattform erwarten.

In der Tat. Die sind auch so unheimlich praktisch, weil man nämlich gleich noch zusätzlich zur Funktion einen zustand mitgeben und manipulieren kann. Genau das, was in der funktionalen Welt aber nicht erlaubt ist.

Ich meinte eher weniger functors als lambda Ausdruecke, closures, anonyme Funktionen

Man kann Multithreading auch dafür nutzen, dass man stabilere Programme erzeugt.

Wie?

Wie sieht denn die automatische Parallelisierung von einem einfachen Algorithmus in Erlang aus? Was passiert, wenn ich ein simples Quicksort implementiere. Wie sieht dazu die automatische Parallelisierung aus? Was passiert da parallel und was nicht?

Automatisch wird bei Erlang gar nichts parallelisiert.

ShadeOfMine schrieb:

Wenn wir uns zB Erlang ansehen: jede Funktion ist ein Prozess. Man hat per Definition keine Locking Probleme - denn wenn man etwas sharen will, muss man es explizit machen.

Nein und nein Bei Erlang ist nicht jede Funktion ein Prozess. Locking-Probleme hat man auch.

Ich denke aber, dass es einfacher ist ein Nachrichtenbasiertes System zu testen, da die Kommunikation nur über definierte Schnittstellen funktioniert.

In Erlang werden eben auch gewisse Programmiertechniken benutzt, um Deadlocks zu vermeiden. So lässt man bei einem Fehler (zB undefinierte Zustände/Nachrichten) einfach den Prozess abstürzen und neustarten.

ShadeOfMine schrieb:

C++ ist hier leider furchtbar, da jede Funktion Seiteneffekte haben kann. Deshalb ist soetwas einfaches wie std::for_each nicht parallelisierbar.

Wo ist C++ da anders, als zB C#? (Wenn du schon ParallelFX erwähnst).

So etwas wie ParallelFX ist ja auch für C++ möglich: http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html

Jester schrieb:

Die automatische Parallelisierung ist sicherlich einen Versuch wert. Allerdings denke ich, dass das noch ein weiter Weg wird. Kurzfristig ist sicherlich das Parallelisieren der Grundalgorithmen der vielversprechendere Weg. Und wenn es wirklich um pure Leistung geht, dann müssen auch die Algorithmen von Hand parallelisiert werden. Schließlich ist es oft auch für Menschen nicht offensichtlich wie sich eine Aufgabe parallelisieren lässt. Da können wir es kaum von der Plattform erwarten.

Ich denke so etwas wie OpenMP scheint auch ganz interessant zu sein. Wo man einfach angeben kann welche Schleifen und Codeteile parallelisiert werden können und der Compiler und die Lib kümmern sich dann darum, dass der Code entsprechend auf Prozesse aufgeteilt wird.

rüdiger schrieb:

Man kann Multithreading auch dafür nutzen, dass man stabilere Programme erzeugt.

Wie?

In dem man Multithreading für Redundanz nutzt zB.

und schrieb:

rüdiger schrieb:

Man kann Multithreading auch dafür nutzen, dass man stabilere Programme erzeugt.

Wie?

In dem man Multithreading für Redundanz nutzt zB.

Da fällt mir jetzt nur sowas wie in Raketen oder Flugzeugen ein, also mehrere Rechner und dann das Ergebnis nehmen das die meisten haben. Aber was bringt sowas bei einem Rechner?

Wie sieht denn die automatische Parallelisierung von einem einfachen Algorithmus in Erlang aus? Was passiert, wenn ich ein simples Quicksort implementiere. Wie sieht dazu die automatische Parallelisierung aus? Was passiert da parallel und was nicht?

In Erlang rufst du eher selten Funktionen auf - du sendest viel oefter Nachrichten. Ich wuerde in meiner naivitaet einfach folgendes machen: Die rekursiven aufrufe von QuickSort durch Message Passing ersetzen.

Und immer wenn die nur Nachrichten verschickst, kannst du Parallel Arbeiten. Ganz trivial ist das ganze natuerlich nicht. (ich habe jetzt 10 min ueberlegt wie man das am besten implementieren wuerde - aber da ich in Erlang nicht ganz so fit bin, bin ich am Design gescheitert :/)

In Erlang rufst du eher selten Funktionen auf - du sendest viel oefter Nachrichten. Ich wuerde in meiner naivitaet einfach folgendes machen: Die rekursiven aufrufe von QuickSort durch Message Passing ersetzen.

Das ist genau das wo ich Probleme bei der automatischen Parallelisierung sehe: Diese naive Parallelisierung von Quicksort skaliert nicht.

Allein das erste partitionieren, das dadurch ja nicht parallelisiert wird, benötigt O(n) Zeit. Das heißt egal wieviele Prozessoren ich Dir spendiere, es wird ab einer gewissen Sättigungsgrenze einfach nicht mehr schneller, der erste Partitionierungsschritt wird zum Flaschenhals.

Ich denke dieses Problem lässt sich am besten durch geeignete Bibliotheken umgehen, die die Algorithmen bereit stellen.

Ich denke dieses Problem lässt sich am besten durch geeignete Bibliotheken umgehen, die die Algorithmen bereit stellen.

PLINQ

array.AsParallel().Orderby(x => x)

Klingt nach einem guten Ansatz. Zumindest die wichtigsten Grundoperationen sollten dadurch abgedeckt werden können.

Das steckt ebenfalls noch in den Kinderschuhen und mit .NET 3.5 kam die erste Version raus. LINQ sagt dir uU etwas - query syntax auf Datenstrukturen.

Danach ging man einen Schritt weiter und hat PLINQ entwickelt (wobei PLINQ seit 2005 in Entwicklung ist) um eben solche Sachen parallelisieren zu koennen.

Was aber wieder fehlt ist eine Garantie dass der Code wenn er parallel ablaeuft nicht durch Seiteneffekte kaputt gemacht wird. Weiters glaube ich, dass (P)LINQ keine Inplace Operationen machen kann. Sprich man hat enormen Speicherverbrauch

Ideal ist es also noch lange nicht - aber die unterliegende Technik ist ziemlich interessant. PLINQ basiert auf der TPL.

TPL (Task Parallel Library) ist die Library um das Subsystem in .NET dass die komplette Parallelisierung uebernimmt. Ein Parallel.forEach oder ein PLINQ Query machen nichts anderes als eine Menge kleiner Tasks zu erstellen - die Arbeit also in kleine Stueckchen zu schneiden. Diese Tasks werden dann je nach Plattform parallelisiert.

Worum es nun geht ist, den Programmierern die Tools zu geben um solche Tasks moeglichst automatisiert zu erstellen. PLINQ ist da recht nett - man macht Queries auf Datenstrukturen und diese koennen dann Parallel ablaufen. Aber wie dein QuickSort Beispiel ja zeigt - so einfach ist das nicht immer. Denn man wird immer Algorithmen haben die man selber Parallelisieren muss und das suckt.

Aber die Ansaetze sind ja schonmal da - wenn wir zB von einem Binary Tree ausgehen und wir wollen alle Elemente aufsummieren:

int sum() {
  return left.sum()+right.sum();
}

dann bietet uns ParallelFX folgendes nettes:

int sum() {
  int r,l;
  Parallel.Do(
    delegate { l=left.sum(); }
    delegate { r=right.sum(); }
  );
  return l+r;
}

Wobei man hier natuerlich aufpassen muss, dass man nicht zuviel Zeit mit dem Schedulen verbringt und man Sequentiell nicht schneller waere - da Threads ja doch Overhead bringen.

Ich bin jedenfalls gespannt was es noch so alles geben wird - denn momentan gibt es verschiedene interessante Ansaetze - aber das wichtigste fehlt noch: die Garantie dass Seiteneffekte den Code nicht zerstoeren.