SBASIC & C++

[stevepoole]

Has anyone seen benchmarks comparing the speed of the same algorythm running in SBasic and C++.
I have an offer to transcode a SBasic program into C++, but do not wish to put the person to trouble unless C++ is definitely considerably faster than SBasic. I have read that Visual basic is almost as fast as C++. Is this also the case for SBasic?

[tofro]

Steve,
as far as I know, there's no such thing as a working C++-Compiler for QDOSMSQ. So, without leaving the platform behind (shame on you, if so ) there's not much point in doing comparisons.

If we're talking C, instead, depending on what the code is doing and the compiler used, you can still calculate with ~50% - 200% improvement , even on compiled S*BASIC. Screen output can't be made much faster, while internal calculations, especially in tight loops, can really be sped up considerably.

Tobias

[stevepoole]

Thanks Tobias. I am not thinking about quitting QPC, just porting a Travelling Salesman program to C++, that is, if it will run faster, for non-QL users. At present, that would be useful if I can get an acceleration of around 9 times, which would make it a very fast program by any standards.
I timed bits of the code, and found that SBasic assignments are slow in proportion to even such heavy routines as divisions. The functions I need to accelerate are + - * and SQRT(). As for assignments, I suspect that they are slow because of the time needed to calculate and fetch array elements. I will try to reduce that overhead by sorting out redundant (repeated) fetching.
Perhaps C++ compilers does some clever Cacheing. Does anybody use CACHE ON or CACHE OFF in programs? If so, where is this helpful?
Steve.

[RWAP]

If the program is written in SuperBASIC / SBASIC, why not simply compile it using Turbo or even SuperBASIC C-Port (have never tried the latter).

If you use Turbo, the code will probably be quicker than C code - would be interesting to know...

By the way, I don't think Visual Basic is interpreted as such - that is probably why it's as fast as C++ code...

[tofro]

If you use Turbo, the code will probably be quicker than C code - would be interesting to know...

Not exactly - C (even C68, which doesn't heavily optimize) is much faster than Turbo compiled programs - Turbo uses so-called threaded code (if not told to compile into inline code which is much faster, but ridiculously large) which is, while faster, still way more slow than C code. Most people consider threaded code still as interpreted. Compared to SMSQ/E SBASIC, Turbo really struggles to gain a twofold increase in speed. C68 is rather like 10 (or more) times faster. DP's advertising claims have always been a bit, say, optimistic (Says me, who really likes the Turbo compiler)

By the way, I don't think Visual Basic is interpreted as such - that is probably why it's as fast as C++ code...

If you consider that a stock PC today is about 1000 times faster than a QL, I think speed shouldn't be much of a problem if you move to another platform.

Tobias

[stevepoole]

So C68 progams are some 10 times faster than uncompiled SBasic. Ok that means the Travelling Salesman Program could run as fast as the current KLT algorythm running on a Mac under C++. This bodes well for the SBasic progam, which is as yet far from fully optimised.
Is C68 a cross-compiler, or do you need to learn C, as I suspect?
For the moment I will continue optimising the code with QPC.
As for Cacheing on QPC, does anyone do this?

[stevepoole]

After years of doing without, I managed to get my program TURBO'd and it does indeed run several times faster.
As for SuperBasic C-Port, where can you get this from?
Steve.

[RWAP]

I probably have a copy of C-Port left in amongst my remaining DP collection disks - I think this was written by Chas Dillon - so someone could contact him about this...

[stevepoole]

Hi Rich,
Yes I would like to aquire Superbasic C-Port and give it a try. It should make a reasonable stepping-stone for transcoding to C++.
If anyone has used it , I would like to hear their opinion on it.

This is what the SBasic 'Travelling Salesman Program' has to compete with :
Type this into your search engine : { An Effective Implementation of the Lin-Kernighan Traveling Salesman Heuristic } This is why speed matters, so that algorythm comparisons use the same languages run on the same processors.

Work on the TSP is still progressing, and I hope to have found time to release it by february.
It will be fully developped first in SMSQ/E on QPC...
Steve.

[RWAP]

I've had a look - if someone has the Digital Precision collection it is on disk 3.

Unfortunately, someone must have already purchased that disk off me...