Mirror of forum.nim-lang.org

10769 :: How to force inline?

• gcao (orginal) [2023-12-15T16:43:19+01:00] view original

  hi. I'm trying to force inline with codegenDec but couldn't get it to work. I have below code. Key is used as Table key.

  proc `==`*(a, b: Key): bool {.codegenDecl: "__attribute__((always_inline))  $# $#$#".} =
    cast[int64](a) == cast[int64](b)
  Run

  When I compile and run it I'm getting error:

  
  /home/vagrant/.cache/nim/fibonacci_r/@m..@s..@s..@shome@[email protected]@[email protected]@slib@spure@[email protected]:343:41: error: inlining failed in call to always_inline ‘eqeq___OOZgeneZtypes_u597’: function body not available
   __attribute__((always_inline)) NIM_BOOL eqeq___OOZgeneZtypes_u597(NI64 a_p0, NI64 b_p1);
  
  $ gcc -v
  ...
  gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
  Run

  It seems the generated code doesn't include the function body. What am I miss here?

---

• Yardanico (orginal) [2023-12-15T16:45:34+01:00] view original

  There's a Nim-native way of inlining code - templates, although they can be a bit different in specific cases, but I think in your cases you can just swap proc to a template and get the expected functionality.

---

• gcao (orginal) [2023-12-15T16:55:54+01:00] view original

  Thanks. So the table is able to find the right template as long as the signature matches?

---

• treeform (orginal) [2023-12-15T17:15:59+01:00] view original

  template `==`*(a, b: Key): bool  =
    cast[int64](a) == cast[int64](b)
  Run

  Nim's operators are just function calls and they resolve just like everything else by types. Nim templates always force things inline, unlike the C compiler which can decide to inline or not even after all of the markings you've added. This gives you full control, but it can also make your code slower by excessively templating things.

---

• cblake (orginal) [2023-12-15T18:31:37+01:00] view original

  @gcao - because your file name seems to be "fibonacci.nim", it bears mention that some versions of some compilers and some versions of Nim have an ability to inline several recursion levels of f(n)=f(n-1)+f(n-2) BUT they are very finicky about the shape of code to trigger this code optimization that is exponential in the depth of inlining. To me this nullifies the always questionable utility of fibonacci numbers as any sort of funcall benchmark.. or at least creates a severe interpretational hazard needing gprof or similar call counters to resolve. { Of course, if you just want Fibonacci numbers there are closed form formulas with the golden ratio or matrix methods that are better ways to get those. } I've noticed this always accidental good fortune of Nim's main module structure allowing gcc to inline & vectorize the fibonacci-esque code pattern seems to have gone away on recent Nim & recent gcc.

---

• gcao (orginal) [2023-12-16T04:50:35+01:00] view original

  Thanks for the input. My fibonacci implementation is not Nim proc. It's in my pet language and interpreted by a Nim VM. Inline won't be a problem I think.

  I am using recursive Fibonacci to benchmark my code. However, I don't know which other language I can compare with. Even Ruby implementation is much faster than mine, probably because it's caching intermediate results. So it's not an apple to apple comparison.

---