Gleitkomma-Migrationsprobleme

Manchmal bemerken Sie beim Upgrade Ihrer Projekte auf eine neuere Version von Visual Studio möglicherweise Änderungen an den Ergebnissen bestimmter Gleitkommavorgänge. Dies geschieht in der Regel aus zwei Gründen: Änderungen beim Generieren von Code, die den verfügbaren Prozessor besser nutzen, und Fehlerbehebungen oder Änderungen an den Algorithmen, die in den mathematischen Funktionen der C-Laufzeitbibliothek (CRT) verwendet werden. Im Allgemeinen sind die neuen Ergebnisse innerhalb der Grenzen, die vom Sprachstandard festgelegt wurden, korrekt. Lesen Sie weiter, um herauszufinden, was sich geändert hat, und wenn es wichtig ist, wie Sie die gleichen Ergebnisse für Ihre Funktionen bekommen wie zuvor.

Neue mathematische Funktionen und universelle CRT-Änderungen

Die meisten mathematischen CRT-Funktionen sind seit Jahren in Visual Studio verfügbar, jedoch sind ab Visual Studio 2013 alle Funktionen enthalten, die für ISO C99 erforderlich sind. Diese Funktionen werden implementiert, damit die Sprache ebenso leistungsfähig wie korrekt ist. Da das korrekt gerundete Ergebnis in jedem Fall nur sehr teuer errechenbar ist, wurden diese Funktionen dazu entworfen, eine starke Annäherung an das korrekt gerundete Ergebnis zu erzielen. In den meisten Fällen liegt das erzeugte Ergebnis innerhalb von +/-1 Einheit der geringsten Genauigkeit oder ulp des korrekt gerundeten Ergebnisses, es kann jedoch vorkommen, dass es eine größere Ungenauigkeit gibt. Wenn Sie eine andere mathematische Bibliothek verwendet haben, um diese Funktionen früher zu erhalten, können Implementierungsunterschiede die Änderung ihrer Ergebnisse erklären.

Wenn die mathematischen Funktionen in die universelle CRT in Visual Studio 2015 verschoben wurden, wurden einige neue Algorithmen verwendet und mehrere Fehler in der Implementierung der Funktionen, die in Visual Studio 2013 neu waren, wurden korrigiert. Diese Änderungen können zu feststellbaren Unterschieden in den Ergebnissen von Gleitkommaberechnungen führen, die diese Funktionen verwenden. Die Funktionen, die Fehlerprobleme hatten, waren erf, exp2, remainder, remquo, scalbln und scalbn sowie ihre Float- und Long-Doubel-Varianten. Andere Änderungen in Visual Studio 2015 haben Probleme beim Beibehalten von Gleitkommastatuswort- und Ausnahmestatusinformationen in _clear87, , _clearfp, fegetenv, fesetenvund feholdexcept Funktionen behoben.

Prozessorunterschiede und Compilerflags

Viele der Gleitkommafunktionen in der mathematischen Bibliothek haben unterschiedliche Implementierungen für verschiedene CPU-Architekturen. Die 32-Bit-x86-CRT hat möglicherweise eine andere Implementierung als die 64-Bit x64 CRT. Darüber hinaus haben möglicherweise einige der Funktionen mehrere Implementierungen für eine bestimmte CPU-Architektur. Eine möglichst effiziente Implementierung wird je nach den von der CPU unterstützten Anweisungssets dynamisch zur Laufzeit ausgewählt. In der 32-Bit-x86-CRT haben einige Funktionen eine x87- und eine SSE2-Implementierung. Wenn eine CPU verwendet wird, die SSE2 unterstützt, wird die schnellere SSE2-Implementierung verwendet. Wenn sie auf einer CPU ausgeführt wird, die SSE2 nicht unterstützt, wird die langsamere x87-Implementierung verwendet. Möglicherweise sehen Sie dies bei der Migration von altem Code, da in Visual Studio 2012 die Standardoption der x86-Compilerarchitektur in /arch:SSE2 geändert wurde. Da verschiedene Implementierungen der Funktionen der mathematischen Bibliothek verschiedene CPU-Anweisungen und andere Algorithmen verwenden, um Ergebnisse zu erzielen, unterscheiden sich die Ergebnisse auf den verschiedenen Plattformen möglicherweise. In den meisten Fällen liegen die Ergebnisse innerhalb +/-1 ULP des korrekt gerundeten Ergebnisses, die tatsächlichen Ergebnisse können jedoch in den CPUs variieren.

Verbesserungen bei der Codegenerierung in verschiedenen Gleitkommamodi können auch Gleitkommaergebnisse ändern, wenn alter Code mit neuem Code verglichen wird, auch mit identischen Compilerflags. Beispielsweise könnte der von Visual Studio 2010 generierte Code, wenn /fp:precise (Standard) oder /fp:strict angegeben wurde, Zwischenwerte mit "Keine Zahl" (NaN) möglicherweise nicht korrekt durch Ausdrücke propagieren. Daher können einige Ausdrücke, die in älteren Compilern ein numerisches Ergebnis ausgegeben haben, jetzt ordnungsgemäß ein NaN-Ergebnis erzeugen. Sie sehen möglicherweise auch Unterschiede, da die für /fp:fast aktivierten Codeoptimierungen jetzt weitere Features des Prozessors nutzen. Diese Optimierungen können weniger Anweisungen verwenden, aber Sie können die generierten Ergebnissen beeinflussen, da einige zuvor sichtbare intermediate-Vorgänge entfernt wurden.

So rufen Sie identische Ergebnisse ab

In den meisten Fällen führen Gleitkomma-Änderungen in den neuesten Compilern und Bibliotheken zu schnellerem oder genauerem Verhalten, oder beides. Sie erkennen möglicherweise auch eine bessere Prozessorleistung, wenn die SSE2-Anweisungen die x87-Anweisungen ersetzen. Wenn Sie jedoch Code haben, der das Gleitkommaverhalten eines älteren Compilers genau replizieren muss, erwägen Sie die Verwendung nativer Multi-Targeting-Funktionen von Visual Studio, und erstellen Sie das betroffene Projekt mit den älteren Buildtools. Weitere Informationen finden Sie unter Use native multi-targeting in Visual Studio to build old projects (Verwenden der nativen Festlegung von Zielversionen in Visual Studio, um alte Projekte zu erstellen).

Siehe auch

Aktualisieren von Projekten aus früheren Versionen von Visual C++
Überblick über potenzielle Aktualisierungsprobleme (Visual C++)
Änderungsverlauf von Visual C++ von 2003 bis 2015