2009-08-18 8 views
6

Le funzioni matematiche del framework .NET funzionano principalmente su float a doppia precisione, non ci sono sovraccarichi di precisione singoli (float). Quando si lavora con dati a precisione singola in uno scenario ad alte prestazioni, ciò comporta un lancio non necessario e anche il calcolo delle funzioni con una precisione maggiore rispetto a quella richiesta, pertanto le prestazioni sono in qualche modo compromesse.Operazioni matematiche di precisione singola in .NET?

C'è un modo per evitare parte di questo sovraccarico della CPU? Per esempio. c'è una libreria matematica open source con sovraccarichi float che chiama direttamente le istruzioni FPU sottostanti? (La mia comprensione è che ciò richiederebbe un supporto nel CLR). E in realtà non sono sicuro che le moderne CPU abbiano anche istruzioni di precisione singola.

Questa domanda è stata in parte ispirata a questa domanda su come ottimizzare una funzione sigmoide:

Math optimization in C#

risposta

3

A mia conoscenza, il .NET Framework non include un API con accesso diretto alla intrinseche matematiche. Le librerie Mono includono il supporto di lavoro per gli intrinsechi, ma non sono sicuro dello stato di esse.

[Edit:. Questo paragrafo è il commento sul perché non si vede sovraccarichi per float parametri] Un problema è stack di valutazione CLI (per ECMA-335) non fa distinzione tra i tipi float e double. Un'implementazione valida potrebbe trattare di tutto come double per le operazioni matematiche, ma immagino che CLR (implementazione di Microsoft della CLI) esegua ottimizzazioni per l'aritmetica a precisione singola dove possibile.

Penso che sia un po 'sfortunato che il problema degli intrinsechi (in particolare le estensioni SIMD) non sia stato ancora affrontato [in un prodotto rilasciato]. La mia ipotesi di outsider è il supporto per gli intrinsechi richiederebbe modifiche significative alla VM che pone rischi inaccettabili a questo punto nel ciclo di rilascio di .NET Framework. Il garbage collector (e penso che i meccanismi di gestione delle eccezioni) sia strettamente associato con l'allocatore di registri e il supporto degli intrinsechi aggiunge una nuova variabile radicale a quell'area.

+0

Quando si fa riferimento a instrinsics, equivale a funzioni esterne? - che è come vengono implementate le funzioni matematiche, rispetto a quelle intrinseche definite nella lingua. AFAIK il CLR potrebbe essere facilmente esteso per implementare per es. pubblico statico extern doppio Sin (float a) in aggiunta alla versione a doppia precisione. – redcalx

+1

Stai parlando di implementarlo nel codice nativo? Il sovraccarico di P/Invoke di farlo per una singola operazione in virgola mobile annullerebbe completamente il tentativo di evitare l'impatto sulle prestazioni di lavorare con 'Sin (double)'. Gli intrinsechi sono dichiarati "extern" ma non sono P/Invoke - il codice nativo per loro è gestito internamente dal JIT stesso per renderli il più efficienti possibile. –

+0

Quindi forse si potrebbero ottenere delle prestazioni se il proprio algoritmo fosse tale da poter creare un singolo P/Invoke che faccia molte operazioni float. – Fantius

1

Sì, costruiamo una libreria matematica scalare ad alte prestazioni che utilizza nativamente calcoli a virgola mobile a precisione singola se è tutto ciò che serve. E tu hai ragione, se implementato correttamente, possono essere molto più veloci di quando si usa la doppia precisione.

Verificare la libreria matematica this dal software CenterSpace.

Paul

+1

Quindi questa libreria sta presumibilmente richiamando il codice non gestito? – redcalx

+1

Sì, è corretto. – Paul