The Sinclair QL Forum

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?

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

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.

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...

RWAP wrote: 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)

RWAP wrote: 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

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?

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.

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...

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.

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...