Free Basic program size

[JLThompson999]

Hello all, new here. I've been searching for a free Basic language that supports multithreading to move a very large program I wrote in Liberty Basic, but which runs far too slowly there. This one seems to be free and to support multithreading, so now I need to know if it can handle large programs. Can someone tell me what the maximum program size it can handle is, in terms of MB and/or number of lines?

[SARG]

Welcome JLThompson999

What does large mean ?

You can compile at least 2Go of source code (32bit fbc), number of lines doesn't matter.
If not enough split the code in several modules separately compiled (.o files) then linked together.

[RNBW]

Hello all, new here. I've been searching for a free Basic language that supports multithreading to move a very large program I wrote in Liberty Basic, but which runs far too slowly there. This one seems to be free and to support multithreading, so now I need to know if it can handle large programs. Can someone tell me what the maximum program size it can handle is, in terms of MB and/or number of lines?

Before trying to re-write a large program using a different Basic Language, have you tried running your program in LBB. This is a fork of Liberty Basic that is mainly compatible and where it isn't it addresses some of the bugs in LB. It compiles and converts the LB code to BBC Basic for Windows and in most cases is quicker than LB. You can read about and download LBB at www.bbcbasic.co.uk/lbb/.

I don't know why, but the link doesn't appear to work. Just type the address into your favourite browser and it will work. By the way, LBB is free.

I must say I would be surprised if Freebasic was more limited by size than Liberty Basic. However, if you have to change to FreeBasic, since you have been programming in LB, you have probably been programming using LB's built in GUI facilities. You will need a GUI library to do the same in Freebasic. There are quite a few Freebasic GUI libraries, which I would advise trying them out before getting to far into the exercise. Some are better or easier than others, but it depends on how much GUI you need.

I have converted large and small programs from LB to FreeBasic (as SARG said it depends on what you mean by large and whether size is referring to the program itself or management of data). Some have been easier than others and there was a lot of re-writing in some cases.

Happy programming..

[JLThompson999]

Thank you both. The program is some 60,000 lines long and a few MB in size, not counting the extensive text files it utilizes.

Unfortunately, much as I would love to not have to rewrite the program, a mere speed boost like you say LBB could give it would be nowhere near enough. My program takes from 12 to 24 hours to process a single input, depending on size, and I need that to be radically reduced. The only way I can see to do that is multithreading, so I can make use of the parallel processing thing. Fortunately, I made no use of the GUIs. It's just a simple text input/output thing.

[marcov]

For most compilers, the limit you are more often practically limited by is the largest block of code (procedure or main program) rather than by the total application size. Register allocation often has some practical limits, which btw are sometimes also encountered when excessively inlining.

[JLThompson999]

For most compilers, the limit you are more often practically limited by is the largest block of code (procedure or main program) rather than by the total application size. Register allocation often has some practical limits, which btw are sometimes also encountered when excessively inlining.

Well, none of my procedures are all THAT long. I'm hoping that if it wasn't an issue in Liberty Basic, it won't be an issue in Free Basic. It's just a LOT of looping through relatively short procedures that process, and reprocess, and re-reprocess, etc.

Also: "inlining"? I'm afraid I don't know what the term means in this context. Can you expand on that?

[caseih]

Shouldn't be a problem, @JLThompson999. FB can handle that and much larger source files.

Although I highly recommend splitting source code files up in to separate files (called modules) that can be compiled individually. That makes it much easier to maintain and document the code, and dramatically decreases compile time when using a build system, as only files you actually change while your work on it need to be recompiled. But very few FB users do this.

[JLThompson999]

Thanks for the advice! I'll look into it.

[marcov]

For most compilers, the limit you are more often practically limited by is the largest block of code (procedure or main program) rather than by the total application size. Register allocation often has some practical limits, which btw are sometimes also encountered when excessively inlining.

Well, none of my procedures are all THAT long. I'm hoping that if it wasn't an issue in Liberty Basic, it won't be an issue in Free Basic. It's just a LOT of looping through relatively short procedures that process, and reprocess, and re-reprocess, etc.

It mostly is a limitation for generated code only, where you generate a very long procedure (e.g. 1.5 MB of source) with the same sequence that makes it run out of virtual registers. The same with maximum nesting depth, for non embedded targets, that limit is also usually only stressed by generated code.

Also: "inlining"? I'm afraid I don't know what the term means in this context. Can you expand on that?

Procedures/subs can be marked as inline in many compilers. Assume procedure A is marked as inline, if a procedure B calls procedure A, the compiler will insert the code of A directly into the code generated for procedure B. This can have speed advantages at the expense of size, but usually only when A is very short.

Note that marking as inline is usually considered a hint, a compiler is free to ignore it. Some compilers can only inline within a compilation unit, and not across compilation units. Many compilers can assess a procedure suitability for inline automatically, and when auto-inline is on perform this automatically.

I strongly second Caseih's remark to style your program as a multi source one. I know it can be bit of a hurdle at first, but in time it is simply better long term.

[caseih]

That's the word I was looking for. "Compile Unit."

Modularizing the code is well worth the time and effort. Each file becomes its own compile unit. Besides making incremental compile time much quicker, individual source files are easier to test in small pieces.

There are some things you need to be aware of and to do to make it all work. You'll want to create .bi (include) files for each compile unit that declare subs and functions, user-defined types, and any variables that will needed by the other compile units. Typically if a compile unit needs to access a global variable from another compile unit, you declare that variable in the .bi file with the "extern" keryword. Circular references should to be avoided between compile units, often by putting the mutually-requried things into another compile unit and .bi file.

As code gets complex and compile units grow in number, a build system becomes useful. Even a "simple" Makefile is helpful. I'm not sure what support for FB other common systems like CMake have.