Results 1 to 7 of 7

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

  1. #1

    Thread Starter
    New Member
    Join Date
    Dec 2011
    Posts
    3

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

    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

  2. #2
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe bu

    Have you selected any of the Advanced Optimizations?

  3. #3

    Thread Starter
    New Member
    Join Date
    Dec 2011
    Posts
    3

    Re: VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe bu

    No. I havent selected any of the Advanced Optimizations

  4. #4
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    14,205

    Re: VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe bu


  5. #5
    PowerPoster
    Join Date
    Jul 2006
    Location
    Maldon, Essex. UK
    Posts
    6,334

    Re: VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe bu

    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 ?

  6. #6

    Thread Starter
    New Member
    Join Date
    Dec 2011
    Posts
    3

    Re: VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe bu

    Quote Originally Posted by Doogle View Post
    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

  7. #7
    PowerPoster
    Join Date
    Feb 2006
    Posts
    24,482

    Re: VB 6 calculates differently for 'No Optimiza' and 'Optimize for Fast Code' exe bu

    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:
    Code:
    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:
    Code:
        Debug.Print A(Fix(10 * Rnd())) 'Print a random entry

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width