I thought "Whole Program Optimization" was a linker's job, not compiler?

2) You tell the same to the compiler, but you replace 1000000 with user-input.
You know that the user only inputs 1000000 and never anything else, but the compiler doesn't know. Compilers can do whatever optimizations, but it will always remain O(N). You can make it O(1) and beat it.

This is of course never the case, but there are problems like converting floating point to fixed because you know you won't need that precision, replacing 64-bit registers with 32- or even 16-bit ones because you don't need more values etc.

To be well done it would require the cooperation of both - I'm not certain what code generation is delayed until link-time (don't some linkers operate on byte code representations?). Or as in the case of the x86 coder would require a good model for implementing the application, and strong low level optimization skills - ideally, complementing each other.

This is not really fair to the HLL compilers. You are essentially holding back secret information from the complier. A compiler can't read your thoughts, you have to tell it what you want within the limits of it's language constructs.

If you know that the user will always enter 1000000 then tell the compiler that to give it the best chance to create the proper code. If you know that you only need integers then tell the compiler that also. Once the compiler has all the relevant information that you know then you can take the next step to judge the quality of the output.

You mean you'll need different obj files or something?

Link time code generation (LTCG), the Visual C++ .NET framework that makes whole program optimization possible, mitigates the difficulty a compiler has in performing optimizations. As the name implies, code generation does not occur until the linking stage.

It isn't strictly x86 object code the linker is working with:

... mitigates the difficulty a compiler has in performing optimizations ...

Um, no, it transfers the difficulty to yet another layer, the .NET layer.

Are you sure? LTCG is for native applications, not for .NET ones.

Visual doesn't support 64-bit assembly !!! That means - its unusable. You still need to use FASM or give up and go to GCC or ICL.

Madis731 wrote:

Visual doesn't support 64-bit assembly !!! That means - its unusable. You still need to use FASM or give up and go to GCC or ICL.

Oh really? There is command line switch named /MACHINE:X64.

Inline asm is not supported by Visual C++ on 64-bit machines. Therefore, if you want your code to be 64-bit compatible, you need to use intrinsics.

I do like C (but hate C# though), but I'm not comfortable with their non-SSSO politics. The first days of browsing through a code all you do is fix compiler-incompatibilities. I never used to get the sources to compile because there was always something missing.

Madis731 wrote:

I do like C (but hate C# though), but I'm not comfortable with their non-SSSO politics. The first days of browsing through a code all you do is fix compiler-incompatibilities. I never used to get the sources to compile because there was always something missing.

I never was able to compile anything from others and sometimes if there's a small modification I have to make I disassemble a program even if it has sources available

Why the hell is it so big? How can FASM compile so easily and flawlessly, but with C you have to setup tons of crap -- even if you use GCC mind you.

What the freaking hell?

f:     ;argument passed in eax
    cmp eax,1
    jbe .1
    push ebx
    lea ebx,[eax-2]
    dec eax
    call f
    xchg eax,ebx
    call f
    add eax,ebx
    pop ebx
.1  ret  
    

; Athlon64 2.0 GHz (corriendo en modo de 32 bits) Usando XCHG
;---------------------------
;Test de fib(50)
;Tiempo = 321375 ms ; Resultado = 3996334433 (Ojo, ocurrió overflow)
;---------------------------
;Test de fib(47)
;Tiempo = 75891 ms ; Resultado = 2971215073
;---------------------------
;Test de fib(40)
;Tiempo = 2625 ms ; Resultado = 102334155
;---------------------------

; Athlon64 2.0 GHz (corriendo en modo de 32 bits) Usando reemplazo para XCHG
;---------------------------
;Test de fib(50)
;---------------------------
;Tiempo = 157297 ms ; Resultado = 3996334433
;---------------------------
;Test de fib(47)
;---------------------------
;Tiempo = 37235 ms ; Resultado = 2971215073
;---------------------------
;Test de fib(40)
;---------------------------
;Tiempo = 1282 ms ; Resultado = 102334155
;---------------------------

N equ 47
include 'win32ax.inc'

start:
  invoke  GetTickCount
  push    eax

  mov     eax, N
  call    fib

  pop     edx
  push    eax ; Argumento para el prinft llamado sin macro
  push    edx

  invoke  GetTickCount
  pop     edx

  mov     edi, buff
  sub     eax, edx
  cinvoke wsprintf, edi, fmt, eax

  xor     eax, eax

@@:
  scasb
  jnz     @b

  dec     edi
  mov     esi, resultado

@@:
  lodsb
  stosb
  test    al, al
  jnz     @b

  dec     edi

  push    fmt
  push    edi
  call    dword [wsprintf]
  add     esp, 4*3

  invoke  MessageBox, 0, salida, titulo, 0

  invoke  ExitProcess, 0

align 16
fib:
  cmp     eax, 1 ; Caso base?
  jbe     .retornar_eax

  push    ebx

  mov     ebx, eax
  dec     eax
  call    fib

; xchg    ebx, eax (Una poronga, por lo menos dobla el tiempo de ejecución)
; sub     eax, 2

  lea     ecx, [ebx-2]
  mov     ebx, eax
  mov     eax, ecx
  call    fib

; eax = Fib(n-2) ; ebx = Fib(n-1)

  add     eax, ebx ; eax = Fib(n-1) + Fib(n-2)

  pop     ebx

.retornar_eax:
  ret

f:     ;argument passed in eax
    cmp eax,1
    jbe .1
    push ebx
    lea ebx,[eax-2]
    dec eax
    call f
    xchg eax,ebx
    call f
    add eax,ebx
    pop ebx
.1:  ret

match n, N
{
  titulo    db "Test de fib(" # `n # ")", 0
}
  fmt       db "%u", 0
  resultado db " ms ; Resultado = ", 0
  salida    db "Tiempo = "
  buff      rb 256 ; Más de lo necesario la verdad pero no importa total
                   ; Windows va a alocar 4 KB en total de todos modos
.end start    

---------------------------
Test de fib(47)
---------------------------
Tiempo = 79390 ms ; Resultado = 2971215073
---------------------------
Aceptar
---------------------------