The optimal-predictors CODEC gives erronous values when compiled with optimization using gcc. This error is not seen when using the Microsoft MSVC compiler.
I have pushed out a version of the code that uses a pragma to suppress optimization when compiled under gcc. This provides a work-around for the problem at the cost of reduced performance.
Unfortunately, there is an issue when using the gcc compiler with optimize levels of O2 or O3. The use of optimization causes the code to produce the wrong walues. At this time, we do not know whether the error is due to a problem with coding or something in the way gcc optimizes numeric calculations. The LSOP predictor depends on floating-point logic that would be very sensitive to non-repeatability in computations. For now, we avoid the problem by using a pragma to limit the optimization level.
Other possibilities may be due to the fact that optimization changes the in-memory layout of the code. It is possible that we have a logic error which is benign in the non-optimized code but shows up when optimization is applied.
I've done a lot of tests trying to see if the -ffast-math compiler option applied to non-optimized code might be the problem (or if we can suppress fast-math). The only time I've observed the problem is when the code is optimized independent of whether fast-math is specified or not.
The optimal-predictors CODEC gives erronous values when compiled with optimization using gcc. This error is not seen when using the Microsoft MSVC compiler.
I have pushed out a version of the code that uses a pragma to suppress optimization when compiled under gcc. This provides a work-around for the problem at the cost of reduced performance.
Unfortunately, there is an issue when using the gcc compiler with optimize levels of O2 or O3. The use of optimization causes the code to produce the wrong walues. At this time, we do not know whether the error is due to a problem with coding or something in the way gcc optimizes numeric calculations. The LSOP predictor depends on floating-point logic that would be very sensitive to non-repeatability in computations. For now, we avoid the problem by using a pragma to limit the optimization level.
Other possibilities may be due to the fact that optimization changes the in-memory layout of the code. It is possible that we have a logic error which is benign in the non-optimized code but shows up when optimization is applied.
I've done a lot of tests trying to see if the -ffast-math compiler option applied to non-optimized code might be the problem (or if we can suppress fast-math). The only time I've observed the problem is when the code is optimized independent of whether fast-math is specified or not.