SetCompilerPathsII & SetCompilerSwitches for WinFBE

Windows specific questions.
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 13, 2020 16:00

A couple more tips.

I have not written any FB programs which use many functions so tend not to use the 'View Explorer Window'; although I did when writing Encrypternet. It is handy because we can double-click on a procedure and WinFBE will jump straight to it. Well there is fair chance that you will have enough space at the bottom of the Explorer Window to locate the 'Paths' and 'Switches' windows so you could open them and leave them open without getting in the way of code.

With the batch file approach a command prompt very briefly opens and closes - more like flashes on and off. However, if we go into the 'User Tools' window and look at the SCPplusSCS entry, at the bottom right, of all tools, there is a checkbox where we can force 'Run minimized'. This minimizes the command prompt, so we no longer see it flash on and off. Well done, Paul. Image
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 14, 2020 0:45

More tips.

If you do as I do and put the tools at the far right of WinFBE's code edit area then ideally we want to make sure that our code lines do not exceed the 'x-position' of the nearest tool. In WinFBE's 'Environment>Code Editor' we have 'Show edge margin' and an edit box to insert a 'Position'. I have mine set to 158, just a couple of pixels to the left of the nearest tool. Not going beyond that margin by using a continuation marker will ensure that the nearest tool does not interfere with our code.

I have now decided to never close these tools and would prefer they were executed at WinFBE's startup.

Well that is easy enough using this batch file, put into WinFBE's Tools folder.; using your paths.

WinFBEStart.bat

Code: Select all

start F:\WinFBE_Suite_1.94\WinFBE64-1.94.exe
timeout /t 1
start F:\WinFBE_Suite_1.94\Tools\SetCompilerPathsII.exe
start F:\WinFBE_Suite_1.94\Tools\SetCompilerSwitchesII.exe

The tools get loaded with great speed and before WinFBE does, so I've put a one-second delay before loading the tools. ( Timeout: Windows 7 or later ). I have put a shortcut to WinFBEStart.bat on my desktop. The shortcut's Property Sheet allows Run with a 'Normal window', 'Minimized', or 'Maximized'. If we choose 'Minimized' then we don't see a prompt command flash on and off.

You may think that I must be really bone idle (British) coming up with some above ideas but I refuse point-blank to do anything that my machine can do for me. I am bone idle but what has that got to do with it. Image

With all of these tips then they are begging for a Help file. If fifty people or more request one then I will write one. Image
srvaldez
Posts: 2461
Joined: Sep 25, 2005 21:54

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby srvaldez » Feb 14, 2020 12:09

@deltarho[1859]
thank you for the tips
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 14, 2020 19:18

This is what I have finally ended up with on my secondary monitor.

I double-click on a desktop shortcut called WinFBE (WinFBEStart.bat) and WinFBE loads along with CSwitches and CPaths at the top right with no command prompt flashing on and off. On loading some source code a margin is placed just to the left of CSwitches and I won't code beyond that margin. I can grab the scrollbar and move it up and down with CSwitches and CPaths remaining fixed. When editing, CSWitches and CPaths remain visible as they are Topmost.

For testing the various compilers and gcc optimization levels this is the ideal setup for me. I am done with this now. Image

Image
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 18, 2020 23:54

Yours truly wrote:I am done with this now.

Famous last words. Image

I have been toying with the idea of checking out the compiler option '-arch 686'. I very much doubt that anyone is still using a 486 or 586 computer so the strongest likelihood is at least 686. After some reading it occurred to me that using '-arch native' would be a better option as a lot of us will have a 786 ( Pentium 4 ) on board so why force the issue with 686. From the FreeBASIC manual: "native: For compiling to the architecture which the compiler is running on.".

If someone else is going to use one of our compilations it would be best to stick with the default 486 as we won't know what the host computer is using. From the FreeBASIC manual: "The -arch native shortcut is similar to gcc's -march=native option. On x86, it causes fbc to try and detect the host CPU automatically based on the cpuid instruction and its availability or results." Notice "try and detect" because the cpuid instruction was not implemented until the 786.

The easiest way to 'play around' with -arch is to add another checkbox to SetCompilerSwitchesII (SCSII) . To keep the checkbox text short I have used 'local' rather than 'native' to be understood as, obviously, 'use local architecture'. Needless to say '-arch native' is passed to WinFBE.

From the FreeBASIC manual: "You can use -arch 686 to override the default -arch 486, and the compiler will generate faster code in some cases, by using certain instructions which were not available on i486 (or other CPUs older than i686)."

Notice "will generate faster code in some cases". That is the theory but I have found code that had a performance hit using 686. The 'hit' was very small and I cannot understand why it occurred - to my mind 686 should have either no effect or a benefit. On the other hand I have seen a performance boost of up to 11.5%. That is amazing considering we have not altered the source code and simply used 'native'. However, it should be noted that increase was on code snippets used for testing before including in an application - I doubt that a completed application would benefit by as much and also bearing in mind that "-arch only affects newly generated code, but not pre-compiled code such as the FreeBASIC runtime libraries, or any other library from the lib/ directory."

Since it doesn't follow that using 'native' will give us a performance boost we are, which is often the case with other measures, reduced to testing with and without.

This is what the new SCSII now looks like.
Image
Here is a zip of the new version.

SetCompilerSwitchesII.zip
srvaldez
Posts: 2461
Joined: Sep 25, 2005 21:54

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby srvaldez » Feb 19, 2020 2:21

Hi deltarho[1859]
never thought about choosing the architecture, so I ran the n-body test without -arch and with -arch native, the test run was 1.33 times faster
that's a significant speed boost, it seems to me that the default should be native.
thank you :-)
[edit]
was reading this https://documentation.help/FreeBASIC/Co ... tarch.html
However, -arch only affects newly generated code, but not pre-compiled code such as the FreeBASIC runtime libraries, or any other library from the lib/ directory. For example, using -arch 386 is not necessarily enough to get a pure i386 executable -- it also depends on how all the libraries that will be linked in were compiled.

I think I will compile FB with -arch native and see if there's a notable difference in execution speed, something for tomorrow maybe.
Last edited by srvaldez on Feb 19, 2020 2:59, edited 2 times in total.
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 19, 2020 2:41

1.33 times faster! Flaming heck.

What is the n-body test?
it seems to me that the default should be native.

That is OK when members are compiling source code written by themselves or others but I wouldn't publish a binary compiled with native otherwise we could have some folk saying "This doesn't work on my <whatever>.
Last edited by deltarho[1859] on Feb 19, 2020 2:53, edited 1 time in total.
srvaldez
Posts: 2461
Joined: Sep 25, 2005 21:54

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby srvaldez » Feb 19, 2020 2:48

deltarho[1859] wrote:What is the n-body test?

it's one of computer languages shootout test, I posted it here viewtopic.php?p=258982#p258982
btw, my new box runs it in about 3 seconds +/- depending on the O level
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 19, 2020 2:55

@srvaldez

I added to my last post.
srvaldez
Posts: 2461
Joined: Sep 25, 2005 21:54

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby srvaldez » Feb 19, 2020 3:02

yes, compiling FB with -arch native would be for personal use.
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 19, 2020 3:04

@srvaldez

I tried your n-body port but only one line of output, a few seconds pass and the console closes.
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 19, 2020 3:07

srvaldez wrote:yes, compiling FB with -arch native would be for personal use.

So, native should not be the default.
srvaldez
Posts: 2461
Joined: Sep 25, 2005 21:54

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby srvaldez » Feb 19, 2020 3:11

deltarho[1859] wrote:@srvaldez

I tried your n-body port but only one line of output, a few seconds pass and the console closes.

argh, I forgot to put a sleep at the end
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 19, 2020 3:34

srvaldez wrote:I forgot to put a sleep at the end

So you did. Image

Your new machine is swift - mine took just over 6 seconds and it is no slouch.

Using '-arch native' only had a negligible effect so folk should test their code with and without. I don't think anyone can second guess what the gcc optimization levels will do to our code or which compiler we use. The only way is: Suck it and see and with SCPII + SCSII we can do that very easily.
deltarho[1859]
Posts: 2524
Joined: Jan 02, 2017 0:34
Location: UK

Re: SetCompilerPathsII & SetCompilerSwitches for WinFBE

Postby deltarho[1859] » Feb 22, 2020 19:55

Whilst considering a new feature, after saying that I was done with this, I did something which I had not done before - made a change but didn't bother with it and closed WinFBE down. Until then I executed a 'Compile' or 'Build And Execute' on every change made. To my horror the changes were not remembered. Paul Squires has explained why this is so.

Whilst the changes were not remembered my SCS was telling me what had been done because I record the changes on a drive. So, my records and WinFBE.ini were out of sync. SCP was not out of sync because I don't record anything with that but the last change was not remembered.

I should stress that there was no issue making changes within WinFBE with both tools if we followed through with a command which included a compilation; most people's procedure and mine. The problem occurs when we make a change and then close WinFBE.

So, until a solution can be found both tools will now remind us, if we make a change, with a message: "Make sure you do a compilation before closing WinFBE.".

OK, so what was this new feature? The -arch checkbox now displays as '-arch ?' because it now a three state checkbox. This what we get on clicking three times:

Image

1. codes for a i486, FB's default
2. codes for native, as we had with the previous version of SCS
3. codes for a i686.

So, why did I bother? Well, I wasn't happy with just i486 or native. I cannot believe that anyone is still using a 486 or 586 - blimey the solder joints on the motherboard would have 'gone west' by now. I don't think that FB would get into any hot water if the default was changed to 686. Come at me with all guns blazing if you think that I am wrong.

I got into a right state when I saw 3., I was expecting a greyed tick. I got José involved. It transpired that it is the norm when we theme a Check3State.

The following link unzips to a folder containing new versions of SCPII and SCSII.

SCPII&SCSII.zip

Needless to say when Paul comes up the means to avoid having to do a compilation when the tools make changes I will report back. Whatever he comes up with I have a feeling it will be well over my head. Meanwhile, don't make changes and then close WinFBE.

Return to “Windows”

Who is online

Users browsing this forum: No registered users and 2 guests