VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe builds

[arunchristopher]

There is a situation here where the exe generated with options being set to "No Optimization" produces output which differs from the output of the exe generated with options being set to "Optimize for Fast Code".
There are lot of calculations, iterations, probability and std deviation calculations involved but we cant figure out how and where VB Calculation differs in "No Optimize" build and "Optimize for fast Code" build.

The code is too big to include it in here. Would be really helpful if someone can explain what exactly VB 6 does during "Optimize for Fast Code" that is different from 'No Optimization'

Thanks,
Arun

[dilettante]

Have you selected any of the Advanced Optimizations?

[arunchristopher]

No. I havent selected any of the Advanced Optimizations

[DataMiser]

Same thread posted on Code Guru
http://www.codeguru.com/forum/showth...45#post2057145

[Doogle]

Just out of interest, which 'version' produces the correct results? (ie Optimized or un-optimized) and why did you look at optimization being an issue in the first place ?

[arunchristopher]

why did you look at optimization being an issue in the first place ?

We are converting an existing VB application to Java for a client. With VB code as reference, we have converted the vb app to java and tested the VB output(Run directly from VB6 IDE) with java output and the results were matching. But when the client(who has the exe generated from VB6 with 'Optimize for Fast code') compares both the output from VB6 exe and java, she finds some difference and reported it back.

It took some time for us to get the actual issue. When the code is directly run from the VB6 IDE or run from the exe generated with compile options set to "No Optimize", the output differs from the exe generated with compile options being set to "Optimize for Fast Code".

We are now logging the calculations in a file and could see some differences in rounding of 'double' datatypes to int during auto type casting.

I will update once we are conclusive on what makes the difference in output.

Thanks,
Arun

[dilettante]

It is very hard to find anything really definitive about the differences when selecting those compiler optimizations.

Since code generation is done using a modfied version of c2.dll (as c2.exe, which is run by vb6.exe after it completes pass 1) you might look at the VC 6.0 compiler optimization switches and their docs.

One thing I saw mentioned on MSDN when I tried following the breadcrumbs was that for "fast code" the compiler inserts some operations as inline code instead of calls into a library (in this case probably the VB6 runtime). So rounding seems a very likely difference.

While it's no comfort now, programmers really should not be using implicit coercion in anything that is sensitive. And even then they usually should be weighing the options (whether to use CLng(), Fix(), Int(), Round(), etc.) and following up with testing. As we see here, that testing almost needs to include tests as p-code and native code using various optimization settings.


We're all guilty of this though. I've cetainly written stuff like:

Dim A(0 To 9) As Single
Dim I As Integer

For I = 0 To 9
    A(I) = 30 - I
Next

Randomize
For I = 1 To 20
    Debug.Print A(10 * Rnd()) 'Print a random entry
Next

Every so often it'll round up and go boom with Subscript Out Of Range.

Clearly I meant:

    Debug.Print A(Fix(10 * Rnd())) 'Print a random entry