FreeBASIC vs QB64

[systemctl]

What is the different between us and QB64? Both claimed to be successor of QB4.5. I found QB64 using many keyword with the underscore prefix, e.g: _MEM, _OFFSET and they have no IDE for themselves other than the textmode IDE.

[systemctl]

It turns out that QB64 doesn't have the pointer data type. They introduced many extensions to workaround this: http://www.qb64.org/wiki/Keyword_Refere ... _Clipboard:

FB compiles to C code but QB64 seemed to compiles to C++.

[systemctl]

Most of the examples here compiled correctly with FB: https://github.com/QB64Team/qb64/tree/d ... mples/misc

But I found the graphic made by the QB64 compiled program is more stable, the graphic compiled by FB, in the other hand, seems to be furious and unstable. You could test with vortex.bas and check if you found the same problem as me.

p/s: I'm on Linux so I can't speak for Windows.

[caseih]

There's no instability. 'The issue is that FB's code is so much faster than QB64's code. If you could slow the loop down, the FBC-compield version would be the same. The shortest __Sleep I can add to the FB loop is 1 millisecond, which is too much delay. If you could delay like several hundred microseconds, then it would get down to near QB64 speed.

[systemctl]

There's no instability. 'The issue is that FB's code is so much faster than QB64's code. If you could slow the loop down, the FBC-compield version would be the same. The shortest __Sleep I can add to the FB loop is 1 millisecond, which is too much delay. If you could delay like several hundred microseconds, then it would get down to near QB64 speed.

I don't understand why there is too much different in speed between FB and QB64. As both compile to C/C++ and utilize GCC/G++ to produce binary. BTW, I don't see any sleep statement in vortex.bas.

[systemctl]

I think it could be because the different on the graphic stack. The QB64's graphic stack is based on SDL2. I don't know about FB but as I didn't see SDL2 as a requirement to install FB, I think we don't use SDL2 and implement everything on our own.

[marcov]

"compile to C(++)" is not a magic incantation. It matters what C++ you generate.

To get speed you really need to generate fairly lowlevel C++.

[caseih]

qb64 has always seems really slow to me. I've got an older version installed (0.980) and even the IDE is laggy (can't even keep up to my typing). I'll have to try the most recent version.

It's also possible that QB64 intentionally introduces delays in some cases, so that code designed to run on a 20 MHz 16-bit computer will run properly on a modern system.

[systemctl]

qb64 has always seems really slow to me. I've got an older version installed (0.980) and even the IDE is laggy (can't even keep up to my typing). I'll have to try the most recent version.

It's also possible that QB64 intentionally introduces delays in some cases, so that code designed to run on a 20 MHz 16-bit computer will run properly on a modern system.

I think I found the reason. QB64 always `emulate` the Console using SDL2. It doesn't use native Console provided by the platform like FB. It could be easily verified by running ldd on the QB64 compiled binary. Without doing so, we still easily see how different the QB64 program console compared to the rest on the system. This plus being compiled by generated C++ caused the QB64 program to be bloated in size.

BTW, I don't think they intentionally introduce delays in code.

p/s: Might be you could use the -x option: https://www.qb64.org/wiki/QB64_FAQ#Q:_I ... the_IDE.3F I think this option will use the system Console only and don't link with SDL2 but I didn't test.

[srvaldez]

@systemctl
to use the system terminal use one of the following

Code: Select all

$CONSOLE:ONLY
_DEST _CONSOLE

PRINT
PRINT "Copy this text by highlighting and right clicking!"

or

Code: Select all

$SCREENHIDE
$CONSOLE
_DEST _CONSOLE

PRINT
PRINT "Copy this text by highlighting and right clicking!"

@caseih
you can add Optimization in the file makeline that's appropriate for your OS, for example: qb64/internal/c/makeline_lnx.txt
(of course this will only affect the programs compiled with QB64)
but even after that, it's executable's are significantly slower than that produced by FB

[aurelVZAB]

@sytemctl

I don't know what is your agenda here ..with all that questions ,,ž
why you don't ask similar question on QB64 forum ?

If you are real basic programmer you should download both and see the difference...

[caseih]

I don't see any problems with anything systemctl has posted here. This forum is pretty quiet, so traffic is welcome. It's not like it's off topic really.

[marcov]

I don't see any problems with anything systemctl has posted here. This forum is pretty quiet, so traffic is welcome. It's not like it's off topic really.

IMHO offtopicness or not is not dependent on forum busy-ness. I don't mind comparisons questions myself, but not if they are very open, extremely wide and unresearched like this one. That is only a trigger for pointless and unfocused discussion.

So not just "FB vs QB64", but at least with some qualifiers for intended goal, used target, a concrete problem description etc.

E.g. "I'm making a game on Windows using library YY, and I notice that the game is noticably slower by xx% on machine ZZ with QB64 then with FB. I benchmarked a bit, and the difference seems mostly in the screen update event, what is the cause and what can I do to improve it"

[aurelVZAB]

I have problem with his question ,,,what he want to know by that ???
like his ; Why did you choose FreeBASIC?
- come on...what is that.??

[caseih]

My feeling is that he's curious about the inner workings of FB compared to other compilers out there like QB64. Many people on this forum use FB as a means of running their old QB code. QB64 is another good choice for that. Shrug. Doesn't bother me at all.