Ich habe eine Art von Brute-Force-Problem, das ich gerne in Haskell lösen möchte. Meine Maschine hat 16 Kerne, deshalb möchte ich meinen aktuellen Algorithmus etwas beschleunigen.
Ich habe eine Methode "tryCombination", die entweder ein Just (String) oder ein Nothing zurückgibt. Meine Schleife sieht so aus:
%Vor%Ich weiß, dass es eine spezielle parMap gibt, um eine Kartenfunktion zu parallelisieren. Ein mapFind kann schwierig sein, da es nicht vorhersehbar ist, ob ein Thread wirklich das erste Vorkommen findet. Aber gibt es etwas wie ein mapAny, um die Suche zu beschleunigen?
BEARBEITEN:
Ich habe den Code mit dem Snippet "withStrategy (parList rseq)" neu geschrieben. Der Statusbericht sieht folgendermaßen aus:
%Vor%Wie bereits erwähnt (siehe meine Kommentare), arbeiten alle Kerne nur für drei Sekunden (wenn alle Funken bearbeitet sind). In den folgenden 30 Jahren wird die gesamte Arbeit von einem einzigen Kern erledigt. Wie kann ich noch mehr optimieren?
Einige mehr EDIT:
Ich habe jetzt "withStrategy (parBuffer 10 rdeepseq)" einen Versuch gemacht und mit verschiedenen Puffergrößen herumgespielt:
%Vor%Zunächst kann ich sagen, dass dies eine große Verbesserung gegenüber den 59er Jahren ohne Multithreading ist. Die zweite Schlussfolgerung ist, dass die Puffergröße so klein wie möglich, aber größer als die Anzahl der Kerne sein sollte. Aber das Beste ist, dass ich weder übergelaufene noch zerstreute Funken mehr habe. Alle wurden erfolgreich konvertiert.
Abhängig von der Faulheit von tryCombination und der gewünschten Parallelisierung kann eine davon das tun, was Sie wollen:
Dies gleicht die Arbeit von tryCombination aus, um herauszufinden, ob es sich um ein Just oder ein Nothing handelt, aber nicht um das tatsächliche Ergebnis in Just .
Wenn es keine solche Faulheit gibt, die ausgenutzt werden kann und der Ergebnistyp einfach ist, könnte es besser sein,
zu schreiben %Vor%Tags und Links haskell parallel-processing