Compiled reality

For other topics related to the FreeBASIC project or its community.
Provoni
Posts: 296
Joined: Jan 05, 2014 12:33
Location: Belgium

Compiled reality

Postby Provoni » Jul 15, 2018 9:04

Hey all,

Consider the code down below.

When compiling it with GCC -O3 the program finishes instantly. However, when you comment out the "print j", the program runs for a long time. That is because at O3 the compiler decided that the for loop serves no obvious function. Though it still might as sometimes you just want to time a loop.

In particularly, the compiler decided that a piece of code serves no obvious function to the user/observer in function of optimization/efficiency. And here is where you can draw a link to quantum mechanics which basically does exactly the same but on a much more advanced level.

Is reality compiled?

Code: Select all

screenres 640,480,32
dim as ulongint i,j
for i=1 to 1000000000000
   j+=i
next i
'print j
beep:sleep
fxm
Posts: 8745
Joined: Apr 22, 2009 12:46
Location: Paris (suburbs), FRANCE

Re: Compiled reality

Postby fxm » Jul 15, 2018 9:17

Provoni
Posts: 296
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: Compiled reality

Postby Provoni » Jul 15, 2018 15:35

It is a good article but there are odd dogmatic remarks such as:

https://wiki.gentoo.org/wiki/GCC_optimization#-O wrote:But I get better performance with -funroll-loops -fomg-optimize!

No, people only think they do because someone has convinced them that more flags are better. Aggressive flags will only hurt applications when used system-wide. Even the GCC manual says that using -funroll-loops and -funroll-all-loops will make code larger and run more slowly. Yet for some reason, these two flags, along with -ffast-math, -fforce-mem, -fforce-addr, and similar flags, continue to be very popular among ricers who want the biggest bragging rights.

Dangerous flags like these are not needed. Don't use them.

In my use case -funroll-loops does increase performance by at least 5%. As does O3. No one convinced me to use these. I just went through the list of compiler flags and tried things out a while ago.

Also, what is dangerous about a compiler flag?
St_W
Posts: 1461
Joined: Feb 11, 2009 14:24
Location: Austria
Contact:

Re: Compiled reality

Postby St_W » Jul 15, 2018 15:41

Provoni wrote:Also, what is dangerous about a compiler flag?

They are dangerous in terms of they might change the behaviour of your compiled application, which is typically not what you want. They aren't dangerous in terms of causing any actual physical damage or permanent software corruption.
deltarho[1859]
Posts: 1718
Joined: Jan 02, 2017 0:34
Location: UK

Re: Compiled reality

Postby deltarho[1859] » Jul 15, 2018 16:20

Compile the opening post with switch -RR and check out the asm file. The loop is not there. If we drop down to -O2 the loop isn't there either. We need to drop down to -O1 to see the loop.

From what I have read -O2 is the most tested switch and recommended by most. I have not found anyone advocating the use of -O3 and some say it may reduce performance.

I take the view that performance boosts of less than 7% should be treated with suspicion. Asynchronous computers can vary by that much by doing nothing to code which is why, when testing speed, we should take an odd number of readings, the more the merrier, and use the median.
Pritchard
Posts: 5492
Joined: Sep 12, 2005 20:06
Location: Ohio, USA

Re: Compiled reality

Postby Pritchard » Jul 17, 2018 13:33

Yes, warnings... compiler flags can actually alter behavior of code. Very frustrating for professional developers. I know very good programmers who write very large programs and run into this sort of issue in production environments. I am of the belief that a compiler should never alter the results of execution in any way. Removing something because it has no obvious functionality is the most ridiculous type of "optimization" I've ever heard of, but if your team has a very strict programming methodology that would work with such optimizations... well, hopefully your team would also know how to remove dead code???

Maybe we are not compiled, but are in the process of compiling... life and death are optimizing the unnecessary as we move toward the end result.
srvaldez
Posts: 1848
Joined: Sep 25, 2005 21:54

Re: Compiled reality

Postby srvaldez » Jul 17, 2018 14:17

Pritchard wrote:Maybe we are not compiled, but are in the process of compiling... life and death are optimizing the unnecessary as we move toward the end result.

yes, that sounds about right.
dodicat
Posts: 5609
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Compiled reality

Postby dodicat » Jul 17, 2018 16:36

So compiler optimisations are to be avoided?
95 percent of the usefulness of -gcc is obliterated in a sentence by Pritchard. (For mission critical anyway)
I am not disagreeing.
I am a 32 bit gas fan.
Anyways the gcc team are not too helpful when it comes to compiling, even bare bones.

Code: Select all

 
'compile -gen gcc

Type udt
    Declare  Function set(as udt ptr=new udt) Byref As udt Ptr
    Declare  Function value(As long,As long) As udt Ptr
   As Long x,y
End Type

Function udt.value(x1 As long,y1 As long) As udt Ptr
  static as udt p:p=type(x1,y1)
  return @p
End Function

Function udt.set(pt as udt ptr) Byref As udt Ptr
    if pt then delete pt
    static as udt ptr z
    return z
End Function


Dim As udt  z
 
z.set()=z.value(12,13)     
print z.set->x ,z.set->y

Sleep   
deltarho[1859]
Posts: 1718
Joined: Jan 02, 2017 0:34
Location: UK

Re: Compiled reality

Postby deltarho[1859] » Jul 18, 2018 1:31

I do not know enough about the process from BASIC to exe to draw any conclusions but I will mention some observations.

Here are the errors when compiling with -gen gcc

Code: Select all

1531867604.c: In function 'main':
1531867604.c:73:20: error: incompatible type for argument 1 of '__builtin_memset'
  __builtin_memset( *TMP$4$0, 0, 0u );
                    ^
1531867604.c:73:20: note: expected 'void *' but argument is of type 'struct $3UDT'
1531867604.c:78:20: error: incompatible type for argument 1 of '__builtin_memset'
  __builtin_memset( *TMP$5$0, 0, 0u );
                    ^
1531867604.c:78:20: note: expected 'void *' but argument is of type 'struct $3UDT'
1531867604.c:83:20: error: incompatible type for argument 1 of '__builtin_memset'
  __builtin_memset( *TMP$6$0, 0, 0u );
                    ^
1531867604.c:83:20: note: expected 'void *' but argument is of type 'struct $3UDT'

That was with gcc 5.2. I get the same with gcc 8. I suspect that versions 6 and 7 may also have the same errors. That is quite a few versions with the same issue.

Is anybody else having similar problems with their languages?

Perhaps the issue is not with gcc but an intermediate file being presented to it that it cannot cope with?

Now, what might that be?

The fact that the code works with gas may not be helpful - for all I know the process from BASIC to exe may differ.

Perhaps dodicat's code can be rewritten such that is does work with gcc?
caseih
Posts: 1325
Joined: Feb 26, 2007 5:32

Re: Compiled reality

Postby caseih » Jul 18, 2018 1:44

I'm not sure why the code compiles. set() is being called with no arguments, yet the function declaration clearly requires one. Something smells funny about this example code. Or am I missing something obvious?
dodicat
Posts: 5609
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: Compiled reality

Postby dodicat » Jul 18, 2018 1:59

It's the gcc team reporting a compiler error in the c code.
But there is no easy clue as to what the error is in the freebasic code.

To fix it
as long x,y
goes to the top in type udt.

casieh
set has it's parameter=new udt, so you don't have to pass a parameter.

deltarho[]
Are you using Poseidon ide quick run?
clue
1531867604.c
deltarho[1859]
Posts: 1718
Joined: Jan 02, 2017 0:34
Location: UK

Re: Compiled reality

Postby deltarho[1859] » Jul 18, 2018 10:18

dodicat wrote:deltarho[]
Are you using Poseidon ide quick run?
clue
1531867604.c

Yes.

WinFBE gives 'compiling C FAILED: Error Code 1.

We then have to check the Compiler Log File.

Poseidon is much better at reporting errors, it parses out the relevant error 'stuff' and puts it straight into the Output window.
deltarho[1859]
Posts: 1718
Joined: Jan 02, 2017 0:34
Location: UK

Re: Compiled reality

Postby deltarho[1859] » Jul 18, 2018 10:57

Here is the failing C code.

Code: Select all

int32 main( int32 __FB_ARGC__$0, char** __FB_ARGV__$0 )
{
   struct $3UDT* TMP$4$0;
   struct $3UDT* TMP$5$0;
   struct $3UDT* TMP$6$0;
   int32 fb$result$0;
   __builtin_memset( &fb$result$0, 0, 4 );
   fb_Init( __FB_ARGC__$0, (uint8**)__FB_ARGV__$0, 0 );
   label$0:;
   struct $3UDT Z$0;
   __builtin_memset( &Z$0, 0, 8 );
   struct $3UDT* vr$3 = _ZN3UDT5VALUEEll( &Z$0, 12, 13 );
   void* vr$4 = malloc( 0u );                                                         <---- 0u
   TMP$4$0 = (struct $3UDT*)vr$4;
   __builtin_memset( *TMP$4$0, 0, 0u );                                               <---- 0u
   struct $3UDT** vr$7 = _ZN3UDT3SETEPS_( &Z$0, TMP$4$0 );
   *vr$7 = vr$3;
   void* vr$8 = malloc( 0u );
   TMP$5$0 = (struct $3UDT*)vr$8;
   __builtin_memset( *TMP$5$0, 0, 0u );                                               <---- 0u
   struct $3UDT** vr$11 = _ZN3UDT3SETEPS_( &Z$0, TMP$5$0 );
   fb_PrintInt( 0, *(int32*)*vr$11, 2 );
   void* vr$13 = malloc( 0u );
   TMP$6$0 = (struct $3UDT*)vr$13;
   __builtin_memset( *TMP$6$0, 0, 0u );                                               <---- 0u
   struct $3UDT** vr$16 = _ZN3UDT3SETEPS_( &Z$0, TMP$6$0 );
   fb_PrintInt( 0, *(int32*)((uint8*)*vr$16 + 4), 1 );
   fb_Sleep( -1 );
   label$1:;
   fb_End( 0 );
   return fb$result$0;
}

The only difference that I can see between that and the successful code is the lines marked '<---- 0u'
Provoni
Posts: 296
Joined: Jan 05, 2014 12:33
Location: Belgium

Re: Compiled reality

Postby Provoni » Jul 18, 2018 14:46

Pritchard wrote:Removing something because it has no obvious functionality is the most ridiculous type of "optimization" I've ever heard of

And it especially attempts to determine the functionality in terms of the user (or the observer in quantum mechanics). But if you add a timer to time the loop it is not smart enough (or by design so) to recognize that the user wants to keep the loop instead. That is the key point. That in general the assumptions behind optimization of all kinds are not in line with what the user wants. And that may cause problems.

In quantum mechanics this problem is solved by having everything in superposition until it is observed. Even the past is uncertain.
deltarho[1859]
Posts: 1718
Joined: Jan 02, 2017 0:34
Location: UK

Re: Compiled reality

Postby deltarho[1859] » Jul 18, 2018 21:30

In the opening post replace

Code: Select all

dim as ulongint i,j

with

Code: Select all

dim as ulongint i
dim shared as ulongint j

and the loop is no longer optimized out.

Compiled with -gen gcc -Wc -O3

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 2 guests