Ich kann einfach keine schlüssigen Informationen zu diesem Thema finden. Es gibt viele Haskell-Spiele-Implementierungen, aber die, die ich gefunden habe, sind kleine Spiele und es ist unklar, ob ihre Ansätze skalieren. Ebenso gibt es eine Menge Informationen darüber, wie man in einem Haskell-Programm einen Staat hat (meistens mit der staatlichen Monade), aber sehr wenig darüber, ob die Effizienz solcher Methoden mit dem Staat in einer imperativen Sprache vergleichbar ist.
Ich arbeite an einem Simulator mit extrem einfachen Grafiken, was die Entwicklung in Haskell sehr wünschenswert macht. Ich möchte jedoch so viele Entitäten wie möglich simulieren, was bedeutet, dass Effizienz sehr wichtig ist. Ich würde eine kleine Leistungsminderung akzeptieren, um Haskell zu verwenden, aber ich mache mir Sorgen, dass die Stateful-Natur dieser Simulation Haskell Code eine Größenordnung langsamer als meine andere Wahl, C ++ machen wird.
Wie erklärt der Titel, wie vergleicht Haskell für diese Art von Anwendung? Vorschläge für Ansätze zur Verwendung in Haskell sowie Links zu implementierten Stateful-Haskell-Programmen würden sehr geschätzt.Wenn ein konkreteres Beispiel dafür erforderlich ist, wie ich den Zustand halten muss, kann ich einen bereitstellen, aber es genügt, wenn ich an eine riesige Sammlung von Koordinaten denke, die sich bei jeder Iteration stark ändern.
Danke!
Wie es aussieht, kann Ihre Frage nicht direkt beantwortet werden.
TL; DR: Es gibt keine theoretischen Gründe, warum Sie Leistungsprobleme haben würden. Und sicherlich kein Grund, um "eine Größenordnung" schlechtere Leistung zu haben. Wenn Sie jedoch kein konkretes Szenario haben, ist es schwierig, etwas anderes als allgemeine Aussagen zu treffen.
Haskell kann auf blanken Speicher zugreifen und Bits umsortieren, genau wie C ++. Es gibt also keine theoretische "Größenordnung langsamer", um die es sich zu kümmern gilt. Wenn Sie den Status als veränderliche Speicherblobs darstellen oder zugewiesene Frames stapeln möchten, unterstützt Haskell (die GHC-Implementierung) das - schließlich gibt es in Haskell geschriebene Betriebssysteme.
Einige Idiome und Bibliotheken, die in diesem Bereich nützlich sind:
Höchstwahrscheinlich benötigen Sie keine absolute Low-Level-Kontrolle, es sei denn, Sie programmieren den Gerätetreiber.
Solange Ihre Algorithmen vernünftig sind, werden Sie in Ordnung sein.
Die GHC-Implementierung von Haskell hat eine sehr schnelle Zuweisung (Bump-Pointer), die unveränderliche Daten billig macht. Es gibt keine inhärente Strafe für die Verwendung unveränderlicher Daten, und Sie erhalten eine einfachere Parallelisierung und einen Code, der einfacher zu pflegen ist. Also, wenn du kannst, halte dich an Haskell-Idiome.
Ich möchte so viele Entitäten wie möglich simulieren, was bedeutet, dass Effizienz sehr wichtig ist.
GHC hat einen sehr effizienten Allokator und Garbage Collector, Objekte sind billig und haben einen geringen Overhead - vorausgesetzt, Sie verwenden sinnvolle Datendarstellungen - also sehe ich hier kein Problem. Z.B. auf dem Benchmark-Spiel testet der binary-trees-Benchmark die Allokator-Performance - C ++ und GHC Haskell sind gebunden zum Zeitpunkt des Schreibens für diesen Mikrotest.
Letztendlich zahlen Sie keine Strafe, um Haskell grundsätzlich zu verwenden. Sie können erforderlichenfalls imperative Algorithmen verwenden - wahrscheinlich müssen Sie das nicht. Machen Sie nicht den Fehler, naive Algorithmen zu verwenden (wie zum Beispiel unveränderliche Listen anstelle von veränderbaren Arrays). Dies ist bei weitem das größte Risiko - als neuer Benutzer könnten Sie ineffiziente Ansätze verwenden - fragen Sie nach Hilfe und Profil:)
Nebenbei schrieb ein neuer Haskell-Benutzer vor zehn Jahren Frag , was eine absolut akzeptable Leistung hatte. GHC ist jetzt auch viel schlauer ...
Tags und Links haskell performance