• Welcome to PlanetSquires Forums.
 

fumbling first questions

Started by dcouzin, December 18, 2018, 10:30:06 PM

Previous topic - Next topic

Johan Klassen

@dcouzin
I am glad that the suggestion for FreeBASIC worked for you, as for -gen gcc not working with version 1.05.0, I suspect that gcc may be missing in your distribution.

dcouzin

@Johann Klassen
FreeBASIC-1.06.0\bin\win32\ contains gcc.exe.  gcc.exe is nowhere inside FreeBASIC-1.05.0 or FreeBASIC-1.04.0, which each have gprof.exe (which FreeBASIC-1.06.0 doesn't have).
Are there compiler options for FreeBASIC-1.05.0 or FreeBASIC-1.04.0 corresponding to the one you suggested for FreeBASIC-1.06.0?

Dennis

Paul Squires

Why use 1.04 or 1.05 just to save a few KB and a maybe a second or two of execution? I would much rather use the latest compiler to ensure that I am compiling with the most bug free version of the compiler.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

Johan Klassen

#18
@dcouzin
I recommend that you just copy the bin folder from FreeBASIC-1.06.0-win32 to FreeBASIC-1.05.0-win32 but first rename the bin folder in version 1.05.0 to something else, that way you can revert if it doesn't work.
beware that versions before 1.06.0 may have bugs that since have been fixed, and perhaps the C emitter may not be as good as that of version 1.06.0
I have not investigated if there are optimization options using the default -gen gas for 32-bit FB, I am inclined to think that if they are present, would not be as good as that of gcc

[edit] better use the FreeBASIC-1.06.0-win32 bin folder from the version available here https://www.freebasic.net/forum/viewtopic.php?p=248057#p248057

dcouzin

@Paul Squires
As the FreeBASIC language evolves the compiler must evolve, always with new bugs and their fixes.  But I am not yet a fan of FreeBASIC.  Parts of me prefer the less fussy syntax of QuickBASIC.  So at this time, for running FB with the '-lang qb' option, it's a different question whether 1.04.0, 1.05.0, or 1.06.0 is least buggy than it is for the '-lang fb' option.  The farther the language evolves away from QB, the easier for a new fix to break the old '-lang qb' option. 

So far, all three FB versions are giving correct answers for the QB code I'm feeding them.  Now with the 'gen gcc' option there are no speed differences, just the size difference of the executable.  I should use whichever version is least likely to have a lurking bug for my code.

Dennis

Paul Squires

Here is the link to the changelog so you can see what has changed/fixed over 1.04, 1.05, 1.06. I wouldn't be so much concerned about any -lang qb breakages as I would about fixes and optimizations that later compiler versions are giving to the -gen gcc output. More recent versions have better -gen gcc output.
https://github.com/freebasic/fbc/blob/master/changelog.txt

I hope that you can get all of the versions working and that FB serves you well with your program. I totally understand and appreciate your situation with your legacy code.
Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer

dcouzin

#21
Quote from: Johan Klassen on December 25, 2018, 06:12:41 PM
... I recommend that you just copy the bin folder from FreeBASIC-1.06.0-win32 to FreeBASIC-1.05.0-win32 ...

This worked.  Is this a hybrid of 1.06.0 and 1.05.0?  The 'gen gcc' option then works, and execution time matches that with 1.06.0.  The executable filesize is a bit smaller, as with old 1.05.0.

Quote from: Johan Klassen on December 25, 2018, 06:12:41 PM...[edit] better use the FreeBASIC-1.06.0-win32 bin folder from the version available here https://www.freebasic.net/forum/viewtopic.php?p=248057#p248057

[modified 1 hr after first posting] The WinFBE_Suite I'm using was released 6 months after that post at freebasic.net, and it uses the preferred 8.1.0 gcc.

Dennis

dcouzin

Quote from: Paul Squires on December 26, 2018, 09:34:52 AM... I hope that you can get all of the versions working and that FB serves you well with your program. I totally understand and appreciate your situation with your legacy code.

Thanks.  I actually have about 500 QB87 (QuickBASIC v.3.00) programs, 200 of which still butter my consulting bread.  All 200 are based on the same calculational core: 1400 lines of numerical operations.  Fifteen numerical input parameters set the core running to yield one number.  Each of the 200 programs twiddles the input parameters differently and runs the core up to millions of times.  Each twiddling code is transparent, mostly loops, and I could probably write them in FB.  But the core is opaque to me now, so I must just test/trust that FB with '-lang qb' produces correct numbers from the core.

Dennis 

Johan Klassen

@dcouzin
I personally only use the -Ofast option for trivial programs, -Ofast or -O3 may optimize your program to the point where it gives wrong results
in your case, since you use your programs for serious applications, I would either use -O2 or -Os
-Os is equal to -O2 with an emphasis on optimizing for small code

dcouzin

Quote from: Johan Klassen on December 26, 2018, 04:46:16 PM
... -Ofast or -O3 may optimize your program to the point where it gives wrong results
in your case, since you use your programs for serious applications, I would either use -O2 or -Os ...

According to this advice, I can have no option '-gen gcc' benefit at all.
As I originally used FB, with options simply '-lang qb', the test program ran in 29.5 sec.
Then with options '-lang qb -gen gcc -Wc -Ofast' the test program ran in 15.5 sec, a nice improvement.
But replacing '-Ofast' with either '-Os' or '-O2' or '-O3' makes the test program run in about 39 sec.

It boggles my mind that there can be over-optimizations that cause seriously wrong calculations.  What exactly does '-Ofast' do?  I know the kinds of calculation in my core program and might be able to judge whether it's immune to the dangers of '-Ofast'.

The 5 different optimizations do cause extremely slight differences in the calculated output.  The '-Os', '-O2', and 'O3' optimizations give identical results to the 15th displayed digit.  The optimization with simply '-lang qb' agrees with them through 14 digits.  The optimization with '-Ofast' agrees only through 13 digits.  These differences are zilch to me, who only needs 3 or 4 good significant digits, though I'm curious where '-Ofast' chisels.

Incidentally, when I run the test program in QB64, the calculated output agrees with the FB output through just 8 digits.  Using QuickBASIC (v.3.00) through NTDVM, my old standard, there's agreement with the FB output through just 6 digits.  I'd noticed that and it wasn't a concern.  My only concern is that a compiler might do something cuckoo.

Dennis

Johan Klassen

#25
@dcouzin
I just wanted you to be aware that there could be a problem when using -Ofast, if you have enough tests to ensure that the results are always acceptable then you can make a decision whether you want to use it or not.
have a look at the gcc documentation on optimization https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
Quote
-ffast-math
Sets the options -fno-math-errno, -funsafe-math-optimizations, -ffinite-math-only, -fno-rounding-math, -fno-signaling-nans, -fcx-limited-range and -fexcess-precision=fast.

This option causes the preprocessor macro __FAST_MATH__ to be defined.

This option is not turned on by any -O option besides -Ofast since it can result in incorrect output for programs that depend on an exact implementation of IEEE or ISO rules/specifications for math functions. It may, however, yield faster code for programs that do not require the guarantees of these specifications.

dcouzin

@Johan Klassen
Thanks much for the link to the gcc documentation.  I'm now warned about -Ofast, so will do an extensive test over all the input parameters.
What's puzzling now is that setting the options simply as '-lang qb' results in a faster running compilation than use of '-gen gcc' together with any of '-O2', '-O3', or 'Os'.  What kind of optimization does FreeBASIC 1.06.0 do when options are set simply as '-lang qb'?

Dennis

Johan Klassen

#27
I am not familiar with the compiler internals to answer that question.

dcouzin

My reported speed trials were poorly done.  I made the mistake of doing repeated runs of the calculational core with identical parameters, only outputting the value computed last.  This would allow a clever compiler to skip all or part of the first many calculations.  It also ignored the time needed for writes to disk.  I've now redone the speed trial on a real version of my optical design program.  It writes almost 400,000 single precision values to disk, each one requiring (I think) 100 runs of the calculational core.   

The new speed results are surprising.  The real program, which used to take overnight to run in QB87 compilation with NTDVM, took these times to run with FB compilation, with various options set:
32.4 min with '-lang qb'
31.3 min with '-lang qb -gen gcc -Wc -Ofast'
51.8 min with '-lang qb -gen gcc -Wc -O2'
51.8 min with '-lang qb -gen gcc -Wc -Os'
51.8 min with '-lang qb -gen gcc -Wc -O3'

The single precision output values are identical for the different compilation options, so there is hardly reason to specify any gcc options for this program. 

The writes to disk are not taking significant time.  When I doubled the core runs to 200 (all different) required for each write the times just doubled.

FreeBASIC 1.06.0 compiles this program very well with the '-lang qb' option set.  Is it making use, in its own wise way, of gcc?

Dennis

Paul Squires

-lang qb is outputting using the assembler backend because -gen gas is the default output. The problem is that if you want 64 bit compiles then you need to use the -gen gcc parameter and invoke the GCC backend. In that case, FB compiles the code to C and passes that code to GCC to compile the 64 bit EXE.

I guess for certain scenarios the -gen gas is outperforming the -gen gcc.



Paul Squires
PlanetSquires Software
WinFBE Editor and Visual Designer