#276 Speed boost

open
nobody
None
2013-06-24
2013-06-23
Kott
No

Basic has commands converting between types of numbers, but they are rarely used because compiler does it for a user. It checks for type and then converts if it's necessary. I think if you add an additional switch to the compiler, e.g. -strict or so to force the user to take care of the variable types and conversion, it would give speed boost for compiled programs. I heard that some programming languages use this and it works.
The second - afaik freebasic compiler "sits" on crt that way or another and all the discussions about speed boost ends up in "use crt". What if replace freebasic internal procedures with calls to crt? The first fb compiler afaik was created to demonstrate that writing something like that is just possible, but now it is a mature programming language and if compiled programs need crt to work, compiler's own procedures can be replaced with calls to crt. This would also speed up program's execution.
I'm not a good programmer like The Great Ones from the forum and I can be wrong, just a bunch of thoughts.

Discussion

  • dkl
    dkl
    2013-06-24

    Well, in -lang fb variable types already need to be handled by the user (except for the Var keyword). And conversions between integers and floats for example aren't that slow. The only improvement possible in that area is to use -gen gcc and rely on gcc to generate better ASM code than fbc would.

    Conversions from and to strings are surely slow, but the only case where they're done automatically is the & concatenation operator, isn't it? Everywhere else the coder uses str()/hex()/oct()/bin() or val()/valint()/etc. That seems ok to me.

    The slowest part of FB perhaps is the dynamic strings. But strings are always slow if compared to integers or floats. Though if the coder uses strings instead of integers to hold score counts in a game for example, that's slow but cannot be fixed with a command line option.

    --

    It's true that FB's Print, Locate, Open etc. are implemented in parts by using CRT functions. But they also use (other) system functions (Win32 API, POSIX etc. on Linux).

    Granted, you may be able to use printf() instead of PRINT and get a speed boost. However, how would you do Locate? There is no locate function in the CRT. And sure, fopen()/fread()/fclose() is faster than Open/Line Input/Close, but the CRT version is based around pointers, while the FB version uses file numbers and dynamic strings and supports additional Open modes like Random.

    This is the case with many FB functions: They are of course sometimes similar to CRT, but often have additional QBish/BASICish features. If you're happy without this extra functionality and can handle the plain CRT syntax, then it's ok to go ahead and use the CRT functions directly.