MathRecompiler performance enhancer

[agraham]

Although not a library I think that this thread is probably the correct home for this utility.

This is the culmination of my efforts to get high performance maths under Basic4ppc. This utility will give optimised compiled Basic4ppc applications that require it almost the same level of numeric performance that C# and VB.NET applications enjoy, at least for Double values. It is based on the recompilation technology of my DebugRecompiler program. It will recompile individually specified Subs in an application to perform all numeric operations as .NET Double types but such Subs will have to conform to a set of constraints if the recompilation is to be successful.

The archive contains the MathRecompiler utility, help and an admittedly rather artificial demo app that shows an approximately 25 fold increase in performance on my Vista desktop and similar on my iPAQ 214 when recompiled.

I may well not have covered all the recompilation scenarios so if you find some code that won't recompile despite conforming to the stated constraints then please post it and if possible I will modify the utility accordingly.

Hopefully, at some time in the (not too distant) future further enhancements to Basic4ppc itself will make this utility redundant but until that time this will make some applications feasible that would take too long to run otherwise.

EDIT:- Quick update to version 1.3. See post #9 for details.

EDIT:- Updated to version 1.4 See post #12 for details. I didn't deliberately design it in but it seems that version 1.4 works with Single, Int32 and Int64 arrays as well as Doubles which could be useful to save memory with large data sets.

EDIT:- This library is now obsolete with the release of Basic4ppc version 6.90.

 

[klaus]

Hi Andrew,

I wanted to try the MathRecompiler with your demo program, but have some trouble:
1) My Basic4PPC is in a different folder than the default one. I added a MathRecompiler.ini file with:
C:\Program Files\Anywhere Software\Basic4ppc Desktop_V6_80 , the directory where the Basic4ppc Desktop.exe is located.
And get the error message in the 1st picture.
I tried also this MathRecompiler.ini file:
C:\Program Files\Anywhere Software\Basic4ppc Desktop_V6_80\Tzor
same result.

2) I copied the whole B4PPC folder with the default directory name. Loaded the B4ppc IDE from there and compiled (optimized Windows EXE). But I get the error message in the 3rd image. The 4th image shows the message whit pause compilation.

What am I doing wrong ?

Another question: The help file says the other Subs should not be called from within a Double subroutine. In the Dynamic Simulation program where I am interested to add the MathRecompilation I call some subroutines but with no parameters tramsmitted and no return value expected. Could such cases be added in the Recompiler or do I need to copy all the subroutines into one, this would become a huge one because several routines are called several times.

Best regards and thank you for this improvement.

Best regards.

 

[agraham]

1) It's MathRecompiler.inf (information) not MathRecompiler.ini.

2) The Tzor folder and its contents need to exist under the Basic4ppc installation folder - I suspect you haven't copied them.

The next version will support Msgbox, without a return value, as it might help in debugging and I am thinking about sub-routines. To keep the performance up, which is the whole reason for this, it will probably only be possible to call recompiled sub-routines with no return values. To return results Double globals could be used. It is likely that such sub-routines will need to be annotated "Subname_AsDoubleSub" so the recompiler can optimise the parameter passing. Such Subs could call each other but not an "_AsDoubles" Sub which would be the top level interface to normal Basic4ppc code.

EDIT:- I'm also likely to change _"AsDoubles" to the singular "_AsDouble" 'cos I don't like the plural now I've used it!

FURTHER EDIT:- Due to a side effect that I overlooked I've just realised (and tested) that subroutines without parameters or return values do in fact work!

 

[klaus]

Hi Andrew,

Thank's for the answer.
Sorry for the mistake between .ini and .inf.

With the correct MathRecompiler.inf file the Recompiler finds the new directory.
But I still get the same error as shown in the 4th image in my previous post.
The 4 *.cs files reported there are in the Tzor folder as shown in the image below, they were also copied when I copied the whole B4PPC folder to a folder with the default name.

Having "Subname_AsDoubleSub" subs would really be fine !
The routines I was speeking about manipulate Global Double variables.

Best regard and thank's for the help.

 

[agraham]

Open a command window in your project directory and type

mathrecompiler /p

You will get a message box showing two paths. The top one should be the path to the Tzor folder - check that it is what you expect.


When you get it running note that subroutines calls do work to either _AsDoubles or normal Subs as long as they take no parameters and any return values are not used. I am unlikely to be able to improve on this for technical reasons to do with .NET delegates.

 

[klaus]

Hi Andrew,

Attached the PathInfo message.
The B4PPC path is the correct one.

Best regards.

 

[agraham]

The recompiler writes a batch ffile like this and then deletes it when it is finished.

@echo off
cd "C:\Program Files\Anywhere Software\Basic4ppc Desktop\Tzor"
@echo on
C:\Windows\Microsoft.NET\Framework\v2.0.50727\csc.exe /o /noconfig /nostdlib /nologo /target:winexe /out:"C:\Users\Andy\AppData\Roaming\Anywhere Software\Basic4ppc\Tzor\1.exe" /define:DEVICE @"C:\Users\Andy\AppData\Roaming\Anywhere Software\Basic4ppc\Tzor\1.rsp" /define:AUTOSCALE /warn:1
@echo off
@echo.
@echo.
Del "C:\Users\Andy\Documents\Basic4PPC\MathRecompiler\Going"

Note that the first line is a change directory to work from the Tzor folder where the cs files are. I've just noticed that in your command window the present directory is not the Tzor folder, it is your project folder on D: I think this is the problem, you can't "cd" across drives. Try it from a folder on your C: drive

 

[klaus]

Thank's Andrew.
Now after copying the folder to the C dirve it works fine.
I think this information would be useful in the help file.

Just a typo in the help file:
'This help file documents version 1.2 of the DebugRecompiler utility.'
should be
'This help file documents version 1.2 of the MathRecompiler utility.'

Best regards.

 

[agraham]

Version 1.3 now posted.

MsgBox statements may now be used in a recompiled Sub in case it is useful for debugging.

_AsDouble is now the preferred indicator suffix for a Sub to be recompiled but _AsDoubles is still accepted.

Help is changed to document MsgBox and give a description of the constraints of calling other Subs from a recompiled Sub.

The project folder may now be located on a drive other than the one on which Basic4ppc is installed.

 

[klaus]

Hi Andrew,

I tried version 1.3, it works well also from disc d:
I ran your demo program recompiled with version 1.2 and also with version 1.3.
It seems that there is a big difference in the execution speed ?
Version 1.2 32 times speed increase.
Version 1.3 8 times speed increase.

Enclosed both exe files.

EDIT: The two source codes of the demo program are different between version 1.2 and 1.3. The call of the DoMathsSub routine from DoMaths_AsDouble instead of calculating directly in this routine makes the differenche.

Best regards.

 

[agraham]

The call of the DoMathsSub routine from DoMaths_AsDouble instead of calculating directly in this routine makes the differenche.

Yes, because the called Sub doesn't do much work so the call overhead is high. Hence the emphasis on the help in doing a significant amount of work in a called Sub or or inlining what would otherwise be small Subs.

 

[agraham]

Version 1.4 now copes with "=" and "<>" in conditional expressions, previously they threw a cast exception. The other comparison operators worked fine as they always assume numeric quantities but as "=" and "<>" can also be used on strings the optimising compiler treats them differently and I hadn't taken this into account .

 

[agraham]

I didn't deliberately design it to do so but it seems that version 1.4 works with Single, Int32 and Int64 arrays as well as Doubles which could be useful to save memory with large data sets.

Post the code here if you try it and it doesn't work and I'll take a look.