-fp:fast study continued

MSVC x64 toolchain’s -fp:fast, which can cause LTCG:pgi build running behavior more different with normal, is more sensitive than x86. So, we should test the x64 build as a prototype. (No PGO build and LTCG:pgi build should all pass the UNIT tests?)
According to https://pcxfirefox.wordpress.com/2016/10/16/a-questionable-but-faster-msvc-compiler-switch, we can use some pragma code section to avoid -fp:fast bugs, but this is very difficult checking in Mozilla Unified build. So, we should use FILES_PER_UNIFIED_FILE = 1 and change UNIFIED_SOURCES to SOURCES in order to find the code section.

There will be no 50.0 released

Because there will certainly be a 50.0.1.

In this period, I change my build machine to i7 6700/1060/SSD, so I must modify my all auto build scripts and update scripts. Maybe I update 50.0 edition, but this is only for testing whether my scripts are OK. I won’t guarantee the edition is stable.

A questionable but faster MSVC compiler switch

/fp:fast

The related article :
1) https://blogs.msdn.microsoft.com/vcblog/2015/10/19/do-you-prefer-fast-or-precise/
2) https://blogs.msdn.microsoft.com/vcblog/2016/05/04/new-code-optimizer/

MSVC2012+ will generate more faster code using -fp:fast, especially on some intrinsic functions and Auto-Vectorization (/arch:SSE2, /arch:AVX?), but maybe this will produce wrong results because of reducing the accuracy.
So if we want to use the compiler switch, you should add some code to avoid the precision decrease.

#ifdef _MSC_VER
#pragma float_control(precise, on, push)
#endif

// Your higher precision code

#ifdef _MSC_VER
#pragma float_control(pop)
#endif

The code section will overwrite /fp:fast to /fp:precise, and very useful to apply for Mozilla code, because Mozilla use unified build to make the projects, it’s more trouble to change it in one source file.

Take Mozilla code for example, we can use -fp:fast on GFX code, and take the patch below.

diff --git a/gfx/2d/BasePoint4D.h b/gfx/2d/BasePoint4D.h
--- a/gfx/2d/BasePoint4D.h
+++ b/gfx/2d/BasePoint4D.h
@@ -6,16 +6,20 @@
#ifndef MOZILLA_BASEPOINT4D_H_
#define MOZILLA_BASEPOINT4D_H_

#include "mozilla/Assertions.h"

namespace mozilla {
namespace gfx {

+#ifdef _MSC_VER
+#pragma float_control(precise, on, push)
+#endif
+
/**
* Do not use this class directly. Subclass it, pass that subclass as the
* Sub parameter, and only use that subclass. This allows methods to safely
* cast 'this' to 'Sub*'.
*/
template
struct BasePoint4D {
union {
@@ -120,12 +124,16 @@ struct BasePoint4D {

void Normalize() {
*this /= Length();
}

bool HasPositiveWCoord() { return w; }
};

+#ifdef _MSC_VER
+#pragma float_control(pop)
+#endif
+
} // namespace gfx
} // namespace mozilla

#endif /* MOZILLA_BASEPOINT4D_H_ */

And in the same time, we also can use the code section below to overwrite /fp:precise to /fp:fast

#ifdef _MSC_VER
#pragma float_control(precise, off, push)
#endif

// Your lower precision code

#ifdef _MSC_VER
#pragma float_control(pop)
#endif
更高

An Experimental ProcessPriority Feature in pcxFirefox 46.0

pcxFirefox 46.0 introduced an Experimental ProcessPriority Feature, which will boost the firefox process to HIGH_PRIORITY when firefox starts, and after 30 seconds, firefox’s process priority will be changed to ABOVE_NORMAL. Correspondingly, plugin-container process will be started with ABOVE_NORMAL.

When start firefox, HIGH_PRIORITY can speed up the boot time, I plan in future, the user can custom the 30 seconds delay time and the normal running process priority. And the future feature may depend on your CPU occupancy rate.

In fact, I don’t want to release the feature to end user ( though I use the feature about a year ), but I found that my 46.0 build script contained the feature, and I have no time to check it again. So release is released, take it easy!