Mirror of forum.nim-lang.org

2005 :: for loop increases executable size by 5k compared to while

• Stefan_Salewski (orginal) [2016-02-03T23:25:24+01:00] view original

  I tried only some minimal cleanup of my toy chess game...

  I have only replaced a while loop by a for loop, and executable size went from 126640 bytes to 130864 bytes. I would not be surprised by a few hundred bytes, but that much. I think I must be doing something wrong for this case, but have no idea currently

  #[
  proc walkKing(kk: KK; s: var KKS) =
    var i: int
    var kk = kk
    while true:
      kk.di = king_path[kk.si][i].pos
      if kk.di == -1: break
      kk.df = board[kk.di]
      if kk.df == 0 or capture(kk):
        s.add kk
      inc i
  ]#
  proc walkKing(kk: KK; s: var KKS) =
    var kk = kk
    for i in 0..7:
      kk.di = king_path[kk.si][i].pos
      if kk.di < 0: break
      kk.df = board[kk.di]
      if kk.df == 0 or capture(kk):
        s.add kk
  
  Run

  Also surprising is, that inserting a plain let statement, without really using it, saves 600 bytes:

  proc initPawn(color: Color) =
    let colorcol_idx = color.col_idx # funny, this saves a few hundred bytes in executable, gcc -O3
    for src in PosRange:
      var i = 0
      for d in PawnDirsWhite:
        pawn_path[color.col_idx][src][i].pos =
          if pawn_move_is_valid(color, src, src + d * color.int): src + d * color.int else: -1
        pawn_path[color.col_idx][src][i].nxt_dir_idx = i + 1 # not really needed
        inc i
      pawn_path[color.col_idx][src][i].pos = -1
  Run

  All tested with Nim 0.13, gcc 5.3 with -d:release , which is -O3 for gcc.

  https://github.com/StefanSalewski/nim-chess

  [EDIT]

  really no idea. In the C files there seems to be nearly no difference. Is executable size a random value?

  The actual size difference is in .o file:

  lt nimcache/engine.o nimcache126/engine.o
  -rw-r--r-- 1 stefan stefan 50728 Feb  4 10:24 nimcache/engine.o
  -rw-r--r-- 1 stefan stefan 44392 Feb  4 10:21 nimcache126/engine.o

  I would understand that for the first for loop in a module the size may increase by a larger amount, because code for the iterator is added to the executable. But there are already many for loops in that module.

---

• v3ss0n (orginal) [2016-02-04T17:09:26+01:00] view original

  very interesting find

---

• OderWat (orginal) [2016-02-04T17:18:31+01:00] view original

  Just a wild guess: Could there be some loop unrolling and/or is there a difference for clang / no O3 ?

---

• Stefan_Salewski (orginal) [2016-02-04T17:35:31+01:00] view original

  Great guess! Thanks. Indeed, a 8 times loop for that case, so gcc may do unrolling.

---

• jibal (orginal) [2016-02-04T20:22:05+01:00] view original

  You should use the size command, not ls (I'm assuming that lt is an alias) ... a difference in file size might just be due to the symbol table.

---

• Stefan_Salewski (orginal) [2016-02-04T20:50:55+01:00] view original

  Yes, here is the output. (there is cairo prefix for the .o files now, I am not sure why, have copied sources from git dir to temp dir before calling Nim on it)

  size board board126
   text	   data	    bss	    dec	    hex	filename
  108856	    728	 409224	 518808	  7ea98	board
  104632	    728	 409224	 514584	  7da18	board126
  stefan@AMD64X2 ~/verti $ size nimcache/cairo_engine.o nimcache126/cairo_engine.o
   text	   data	    bss	    dec	    hex	filename
  29289	      0	    328	  29617	   73b1	nimcache/cairo_engine.o
  25065	      0	    328	  25393	   6331	nimcache126/cairo_engine.o

  I think text section is the actual code, so it was really a great guess of Mr OderWat. ( I append the 126 for the one without the "for i in 0..7" loop.)

---

• jibal (orginal) [2016-02-05T11:08:55+01:00] view original

  Yes, .text was the PDP11 assembler directive for the code section, for some reason, and it lives on. The bss section, which is for data that isn't explicitly initialized (it is zeroed when the program is loaded), has an even more obscure origin.

---