Quanto può essere efficiente lo stato di Haskell rispetto a C++, per giochi/simulazioni di stato?

Question

Non riesco a trovare alcuna informazione conclusiva sull'argomento. Ci sono un sacco di implementazioni di giochi Haskell là fuori, ma quelle che ho trovato sono piccoli giochi e non è chiaro se i loro approcci sono in scala. Allo stesso modo, ci sono molte informazioni riguardo al fatto di avere uno stato in un programma Haskell (principalmente usando la monade di Stato), ma molto poco sul fatto che l'efficienza di tali metodi sia paragonabile allo stato in un linguaggio imperativo.

Sto lavorando ad un simulatore che ha una grafica estremamente semplice, il che rende molto interessante lo sviluppo in Haskell. Tuttavia, voglio simulare il maggior numero possibile di entità, il che significa che l'efficienza è molto importante. Accetterei una piccola riduzione delle prestazioni al fine di utilizzare Haskell, ma temo che la natura di stato di questa simulazione renderà il codice Haskell un ordine di grandezza più lento dell'altra mia scelta, il C++.

Come afferma il titolo, come si confronta Haskell per questo tipo di applicazione? Suggerimenti per gli approcci da utilizzare in Haskell, oltre ai collegamenti ai programmi Haskell ad alte prestazioni implementati, sarebbero molto apprezzati.

Se è necessario un esempio più specifico di come devo mantenere lo stato, posso fornirne uno, ma basti pensare a un'enorme raccolta di coordinate che cambia radicalmente su ogni iterazione dovrebbe essere sufficiente.

Grazie!

Answer 1

In questo modo non è possibile rispondere direttamente alla domanda.

TL; DR: non ci sono motivi teorici per i problemi di prestazioni. E certamente non si sa ragione per avere prestazioni "peggiori di un ordine di grandezza". Tuttavia, a meno che tu non abbia uno scenario concreto, è difficile fare qualcosa di diverso dalle affermazioni generali.

---

Haskell può accedere a memoria nuda e shuffle bit in giro, proprio come C++. Quindi non c'è alcun "ordine di grandezza più lento" teorico su cui preoccuparsi. Infatti, se si desidera rappresentare lo stato come blob di memoria mutabili, o impilare i fotogrammi allocati, o qualsiasi altra cosa, Haskell (l'implementazione GHC) lo supporta - dopotutto ci sono sistemi operativi scritti in Haskell.

Alcuni idiomi e le librerie che sono utili in questo settore:

• disimballati, severe campi
• monade ST (accesso sicuro alla memoria crudo)
• le librerie vettoriali e Repa - ad alte prestazioni vettori

Molto probabilmente non sarà necessario il controllo di basso livello assoluto, a meno che non si stia programmando il driver del dispositivo.

Fintanto che i tuoi algoritmi sono ragionevoli, starai bene.

L'implementazione GHC di Haskell ha un'allocazione molto veloce (puntatore di bump) che rende i dati immutabili a buon mercato. Non vi è alcuna penalità intrinseca per l'utilizzo di dati immutabili e si ottiene una più facile parallelizzazione e un codice che è più facile da mantenere. Quindi, se puoi, segui gli idiomi di Haskell.

Voglio simulare il maggior numero possibile di entità, il che significa che l'efficienza è molto importante.

GHC ha un allocatore e un garbage collector molto efficienti, gli oggetti sono economici e hanno un sovraccarico basso - presupponendo che si utilizzino rappresentazioni di dati sensibili - quindi non vedo alcun problema qui. Per esempio. sul benchmark, il benchmark degli alberi binari verifica le prestazioni degli allocatori - C++ and GHC Haskell are tied al momento della stesura di questo micro-test.

In definitiva, non si paga alcuna penalità per utilizzare fondamentalmente Haskell. È possibile utilizzare algoritmi imperativi dove necessario, probabilmente non è necessario. Basta non commettere l'errore di usare algoritmi ingenui (come usare liste immutabili al posto di matrici mutevoli). Questo è di gran lunga il più grande rischio: come nuovo utente, potresti usare approcci inefficienti - chiedi aiuto e profilo :)

Per inciso, un nuovo utente Haskell, 10 anni fa, ha scritto Frag, che aveva perfettamente prestazione accettabile. GHC ora è molto più intelligente ...