Compile times

General FreeBASIC programming questions.
Landeel
Posts: 772
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: Compile times

Postby Landeel » Dec 10, 2020 19:24

For my games, gas compiles much faster, so that's what I use while developing.
When I need to compile the final version, I usually use gcc and all optimizations, because it gives me the higher fps.

My time measure was taken after several subsequent compiles, just to be sure.
jj2007
Posts: 2171
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Compile times

Postby jj2007 » Dec 10, 2020 20:50

SARG wrote:
jj2007 wrote:I am still on Win7-64. Now I checked on my wife's Win10 machine, and it fails indeed with that error. This is the very first time that I see an old WinAPI function fail...
Sure, that's strange. Have you tried to compile on your wife's PC then run the exe?
Yes, same result. It seems the global atom functions don't work any more, or they are blocked. Google does not mention the problem, which is rather odd.
srvaldez wrote:timing compile times is not so simple, it could take over a second the first time but subsequent times take but a fraction of a second, even if you make some small change to the source code
Right. My timings above take account of that. I ignore the first 3 or 4, then take the average of the next 3 builds.
marcov wrote:I can strongly recommend to work on an internal assembler and linker for the GAS target. That is probably where the biggest gains are.
Gcc seems a slow compiler, but the executables are probably faster than what GAS produces. Perhaps Landeel's strategy is the right one: develop with Gas, finalise with Gcc.

I've also noticed that including certain packages make the build slow. The solution might be to split them, e.g. into a "light" and a "full" Windows.bi
SARG
Posts: 1266
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Compile times

Postby SARG » Dec 10, 2020 21:32

@jj2007
The exe with the code below runs without any problem.

Code: Select all

#include "windows.bi"
dim as ATOM vAtom=globaladdatom("Test")
print vAtom
 
dim as string Buffer=Space(256)
GlobalGetAtomName(vAtom,strptr(Buffer),Len(Buffer))
print Buffer
 
dim as ATOM vFindAtom=GlobalFindAtom("Test")
If vFindAtom=vAtom then
   print "Found Atom",vFindAtom
else
   print "Not Found Atom"
endif
sleep
jj2007
Posts: 2171
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Compile times

Postby jj2007 » Dec 10, 2020 22:25

SARG wrote:The exe with the code below runs without any problem.
If you run a second, separate, executable, does it find that atom, using the 16-bit number returned by the previous one? I ask because I wonder if they restricted the atom table to the current executable in Win10. Under Win7 and earlier, it's a shared resource, but maybe they changed that out of security concerns...

I have updated the timing program - feedback needed ;-)
SARG
Posts: 1266
Joined: May 27, 2005 7:15
Location: FRANCE

Re: Compile times

Postby SARG » Dec 11, 2020 10:17

jj2007 wrote:If you run a second, separate, executable, does it find that atom, using the 16-bit number returned by the previous one?

Running the 3 exes in a batch file all works fine IF THERE IS A SLEEP at the end of the code. Without it the atom is not created ?????????

Code: Select all

''testbed
#include "windows.bi"
dim as ATOM vAtom=globaladdatom("Test")
print vAtom
 
 
dim as string Buffer=Space(10)
GlobalGetAtomName(vAtom,strptr(Buffer),Len(Buffer))

print Buffer
 
dim as ATOM vFindAtom=GlobalFindAtom("Test")
If vFindAtom=vAtom then
   print "Found Atom",vFindAtom
else
   print "Not Found Atom"
endif
sleep 1

Code: Select all

''testbed_2
#include "windows.bi"
dim as string Buffer=Space(256)
dim as ATOM vFindAtom=GlobalFindAtom("Test")
if vFindAtom<>0 then
   GlobalGetAtomName(vFindAtom,strptr(Buffer),Len(Buffer))
   print vFindAtom,Buffer
   GlobalDeleteAtom(vFindAtom)
else
   print "not found"
end if
sleep 1

Code: Select all

''testbed_3
#include "windows.bi"
dim as string Buffer=Space(256)
dim as ATOM vFindAtom
dim as short vAtom
input "atom ";vatom

if globalgetatomname(vAtom,strptr(Buffer),Len(Buffer)) then
   print Buffer
   GlobalDeleteAtom(vFindAtom)
else
   print "not found"
end if
sleep


Code: Select all

D:\laurent_divers\fb dev\En-cours\FBDEBUG NEW\asm64_via_llvm\test_jj2007>testbed
49496
Test
Found Atom    49496

D:\laurent_divers\fb dev\En-cours\FBDEBUG NEW\asm64_via_llvm\test_jj2007>testbed_2
49496         Test
D:\laurent_divers\fb dev\En-cours\FBDEBUG NEW\asm64_via_llvm\test_jj2007>testbed_3
atom ? 49496
Test


testing timeit.bat. Note that time is "big" due to Avast which complains so I need to force the execution....

Code: Select all

Error in TimeWithAtom, GlobalAddAtom failed: Le nom de sémaphore système spécifié n’a pas été trouvé.
 Le volume dans le lecteur D n’a pas de nom.
 Le numéro de série du volume est 186E-B590

 Répertoire de D:\telechargements\jj2007

Fichier introuvable
Error in TimeWithAtom, GlobalGetAtomName failed: Descripteur non valide

now with timeit:

*** 8476 ms for SleepOneSecond.exe ***
Appuyez sur une touche pour continuer...
marcov
Posts: 3161
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Compile times

Postby marcov » Dec 11, 2020 10:53

jj2007 wrote:Gcc seems a slow compiler, but the executables are probably faster than what GAS produces. Perhaps Landeel's strategy is the right one: develop with Gas, finalise with Gcc.


That is an discussion as old as time, many companies use development binaries for e.g. internal use (some might even ship them to customers), daring not even changing compiler options to enable optimization before shipping.

Because if you ship something different than you develop with, you risk then that you ship bugs only exposed in the gcc backend (not necessarily in GCC, the FB gcc specific part counts too). Or Heisenbugs that suddenly get exposed because the gcc binary has a different memory layout etc.

Though this is typically as applications get very large, and contain large amounts of business code written long ago for not often executed scenarios.

And the speed gain with GCC might only be measurable. +40% performance is not noticeable with many kinds of applications, specially if it is not a big factor in the rate determining step.

It also depends on the amount of control you have. In the early days in my current job we had such problems (Heisenbugs), and dare not changing anything close to a shipping. Nowadays, such bugs are incredibly rare, and directly hunted down when noticed, despite the application being much larger. But image processing code like this has less seldom run code, like true business code does. (e.g. code that only runs at the end of the quarter/year, or if prices change etc)
jj2007
Posts: 2171
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Compile times

Postby jj2007 » Dec 11, 2020 11:51

SARG wrote:Running the 3 exes in a batch file all works fine IF THERE IS A SLEEP at the end of the code. Without it the atom is not created ?????????
Very odd, thanks for testing this...!
jj2007
Posts: 2171
Joined: Oct 23, 2016 15:28
Location: Roma, Italia
Contact:

Re: Compile times

Postby jj2007 » Dec 11, 2020 12:00

marcov wrote:many companies use development binaries for e.g. internal use (some might even ship them to customers), daring not even changing compiler options to enable optimization before shipping.

Because if you ship something different than you develop with, you risk then that you ship bugs only exposed in the gcc backend (not necessarily in GCC, the FB gcc specific part counts too). Or Heisenbugs that suddenly get exposed because the gcc binary has a different memory layout etc.

I had thought of that, too. We have numerous threads here discussing problems with different tool chains (mostly because their proggies don't build without picking some obscure options, though). It is inherently messy, but I see that many of our members want the Gcc backend. There is no "right" solution imho, there will always be a tradeoff between performance, reliability and maintainability. My own choice is MasmBasic, i.e. a dialect that is built in pure assembly, but that will never be a mainstream option: 32-bit only, Windows only, etc...

The default FB Gas backend is definitely faster than Gcc regarding compile times. But is Gcc so much better for execution time?

IMHO it would be good to have a default installation that is reasonably fast and simply works, out of the box - including a decent IDE/editor, and a decent installer. The "B" in Basic does not stand for people who want to spend hours or days in this forum in order to get their hello world proggies build and run. There is a lot of competition out there, from Python, from other Basic dialects - if we want to attract new users, FB must become simpler imho.
Landeel
Posts: 772
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: Compile times

Postby Landeel » Dec 11, 2020 12:46

Because if you ship something different than you develop with, you risk then that you ship bugs only exposed in the gcc backend (not necessarily in GCC, the FB gcc specific part counts too). Or Heisenbugs that suddenly get exposed because the gcc binary has a different memory layout etc.


Games are the only thing I develop in FB, so I playtest a lot before releasing.
But I agree, for important production software, it's much safer to develop and release using the same backend and flags.

Return to “General”

Who is online

Users browsing this forum: No registered users and 13 guests