2009-08-18 7 views
6

Die Math-Funktionen des .NET-Frameworks arbeiten hauptsächlich mit Floats mit doppelter Genauigkeit, es gibt keine Überladungen mit einfacher Genauigkeit (Float). Wenn Sie in einem Hochleistungs- szenario mit Daten mit einfacher Genauigkeit arbeiten, führt dies zu einem unnötigen Casting und außerdem zu einer präziseren Berechnung der Funktionen als erforderlich, wodurch die Leistung in gewissem Maße beeinträchtigt wird.Einzelpräzision Math Operationen in .NET?

Gibt es eine Möglichkeit, einen Teil dieses zusätzlichen CPU-Overheads zu vermeiden? Z.B. Gibt es eine Open-Source-Math-Bibliothek mit Float-Überladungen, die zugrundeliegende FPU-Anweisungen direkt aufruft? (Mein Verständnis ist, dass dies Unterstützung in der CLR erfordern würde). Und eigentlich bin ich mir nicht sicher, ob moderne CPUs sogar Befehle mit einfacher Genauigkeit haben.

Diese Frage wurde zum Teil von dieser Frage inspiriert über eine S-förmige Funktion zu optimieren:

Math optimization in C#

Antwort

3

Mein Wissen ist das .NET Framework nicht eine API mit direktem Zugang zur Mathematik intrinsics umfasst. Die Mono-Bibliotheken enthalten Arbeitsunterstützung für Intrinsics, aber ich bin mir nicht sicher über deren Zustand.

[Edit:. Dieser Absatz ist Kommentierung, warum Sie float Parameter nicht sehen Überlastungen für] Ein Problem ist die CLI Auswertungsstapel (pro ECMA-335) unterscheidet nicht zwischen den float und double Typen. Eine gültige Implementierung könnte alles als double für mathematische Operationen behandeln, aber ich stelle mir vor, dass die CLR (Microsofts Implementierung der CLI) Optimierungen für Einzelpräzisionsarithmetik durchführt, wo es möglich ist.

Ich denke es ist etwas bedauerlich, dass die Frage der intrinsics (insbesondere SIMD-Erweiterungen) noch nicht [in einem freigegebenen Produkt] angesprochen wurde. Meine Außenseiter vermuten, Unterstützung für intrinsics würde erhebliche Änderungen an der VM erfordern, die an dieser Stelle im .NET Framework-Release-Zyklus inakzeptable Risiken darstellen. Der Garbage Collector (und ich denke, dass die Ausnahmebehandlungsmechanismen) eng mit dem Registerzuordner verbunden ist, und das Unterstützen von Intrinsics fügt diesem Bereich eine radikal neue Variable hinzu.

+0

Wenn Sie auf Intrinsics beziehen, ist dies das gleiche wie externe Funktionen? - So werden die Mathematikfunktionen implementiert, im Gegensatz zu den in der Sprache definierten Eigenschaftswerten. AFAIK der CLR könnte leicht erweitert werden, um z.B. public static extern Double Sin (float a) zusätzlich zur Double-Precision-Version. – redcalx

+1

Sprechen Sie darüber, es in nativem Code zu implementieren? Der P/Invoke-Aufwand, der für eine einzelne Gleitkommaoperation anfällt, würde den Versuch, die Leistungsbeeinträchtigung durch das Arbeiten mit "Sin (double)" zu vermeiden, vollständig negieren. Intrinsics werden als "extern" deklariert, sind aber nicht P/Invoke - der native Code für sie wird intern vom JIT selbst behandelt, um sie so effizient wie möglich zu machen. –

+0

So könnte vielleicht etwas Leistung erzielt werden, wenn Ihr Algorithmus so wäre, dass Sie ein einzelnes P/Invoke erstellen könnten, das viele Gleitoperationen durchführt. – Fantius

1

Ja, wir erstellen eine mathematische Hochleistungsbibliothek für die Vorwärtsskalierung, die nativ Fließkomma-Berechnungen mit einfacher Genauigkeit verwendet, wenn dies alles ist, was Sie brauchen. Und Sie haben Recht, wenn sie richtig umgesetzt werden, können sie viel schneller sein als mit doppelter Genauigkeit.

Auschecken this Math Bibliothek von CenterSpace Software.

Paul

+1

Also ruft diese Bibliothek wahrscheinlich zu nicht verwaltetem Code auf? – redcalx

+1

Ja, das ist richtig. – Paul