Piero: there’s a bad bug in the program - you start the timer before the MsgBox() call - so the time spent waiting for the user to hit “OK” is included in the timing, so that throws everything off.
To fix this move these lines:
qq="Start: size of the matrix: "+str( n)+" x "+str(n)
msgbox(qq)
immediately before this line:
tempo1=microseconds
That way, the timer is not started until the user hits “OK”.
With those changes, I get the following timings (which are now reliable):
I’m seeing 15.8 in the IDE which drops to 6.8 in a built app with background tasks off, a 230% difference. I suspect this is close to your VB6 results, suggesting that the IDE and xojo framework overhead are to blame, but can be eliminated quite easily.
For fun, I tried to optimize your code - my first target was to get rid of function calls, so I inlined the Abs() calls by replacing them with a temp variable and an if statement:
g = 100. * Abs(a(ip, iq))
becomes
tmp2 = a(ip,iq)
if tmp2 < 0 then
tmp2=-tmp2
end if
g = 100 * tmp2
This doesn’t seem to help at all, and may hurt - it goes from 6.8 to 6.9 seconds in my testing. Hmm. This surprises me as I thought function calls were expensive in Xojo - maybe Abs() is not?
Next, I removed the bounds checking in the array code, adding this to both methods:
#pragma DisableBoundsChecking
This drops it from 6.8 seconds to 6.5 seconds (only a 5% improvement).
Michael: you are absolutely right, the timing was bugged. I have moved the lines and
it should be ok now. Probably this did not dramatically affect the timing, as people tend to
click the OK button without waiting more than a fraction of a second.
As a very rough conclusion from previous data it turned out that the old VB6 is still a strong competitor as far as
number crunching is concerned.
Considering all timing as an absolute scale without bothering with different arch and CPUs , only
the xojoscript from Rinaldi is close to the VB6 results.
As Geoff Perlman pointed out, the xojoscript should be as efficien as the LLVM compiler expected in the near future.
The above test was made to assess the portability to xojo (in term of performance) of a molecular graphic code I have developed
since long ago in pure VB6 (no OpenGl and alike) (http://www.moldraw.unito.it)
The present results suggest that the porting would be worthtrying
for better results on number crunching you can do a couple of things:
better code optimization (there is some space for this, I think)
use a plugin for handling matrixes and calcs. It seems to me there is something specific to your needs, but I don’t remember the name at this time. I can search if needed.
for sure there is a lot of room for improvement as the Jacobi algorithm is the simplest and the code was not optimized at all.
My purpose was just to grasp the general behaviour of the two world (VB6 and Xojo) and what to expect when converting
a piece of code representative of numerical (and memory) intensive task from VB6.
Optimized plugins specific to linear algebra would be very useful for my purposes.
thank you Piero Ugliengo for starting this thread. I am also looking to move 3 large projects to xojo(from vb6), but as I suspected I need to wait until LLVM is implemented as indicated by this test.
Very valuable information, thanks for everyone’s efforts
