Mirror of forum.nim-lang.org

3318 :: Hiding sideeffect from compiler

• cdome (orginal) [2017-11-10T16:42:46+01:00] view original

  Hi, I am actively using Nim's side effect tracking system and marking procs with noSideEffect pretty much everywhere. I have external requirement not to have side effects and Nim helps here quite a bit.

  However, I have place in a code that logically I don't have side effects, but physically I am changing global cache map object. I do memoization for perfomance reasons.

  Is there a way hide this effect to compiler?

---

• Udiknedormin (orginal) [2017-11-12T00:11:04+01:00] view original

  I don't think it's something you should actually do as the compiler can do certain optimizations when it knows a routine has no side effects. Optimizations which may opt out your side effects, I guess.

---

• Araq (orginal) [2017-11-13T10:12:21+01:00] view original

  There is a way to hide this, but I don't know if it's a good idea for your use case.

  proc sideEffect(a, b: string) = echo a, b
  
  proc lacksSideEffect() {.noSideEffect.} =
    cast[proc (a, b: string) {.nimcall, noSideEffect.}](sideEffect)()
  Run

---

• Udiknedormin (orginal) [2017-11-15T13:53:58+01:00] view original

  @Araq That looks nasty! :-o Wouldn't it confuse the compiler? Also --- it prevents inlining, I guess?

---

• Araq (orginal) [2017-11-15T15:40:02+01:00] view original

  Well it's not "nasty", 'cast' is used to circumvent the type system. Probably needs better documentation in the manual. Pretty sure the C backend can see through the cast and inline it anyway.

---

• Udiknedormin (orginal) [2017-11-15T17:38:38+01:00] view original

  @Araq Oh, I shold bold it I mean Nim optimization and inlining, not C's ones... as weird as it sounds. I mean, any pattern-template or pattern-macro which matches a noSideEffect routine would match here, despite the fact this routine has side effects, actually. I guess whenever it's good or not depends on the intended behavior.

---

• pwernersbach (orginal) [2017-11-15T18:14:15+01:00] view original

  In regards to cdome's original question, I think tricking the compiler to ignore side effects for a certain function is the wrong way to go about this. If the memoization table was passed as a function parameter, the function would have no side effects, with no tricks involved.

---

• cdome (orginal) [2017-11-15T19:32:34+01:00] view original

  I am fine with Araq's solution.

  Passing cache table as argument is not an option, because it needs to be updated on every request which is a side effect. Returning a copy of table on every call is not an option either, as its size is 64GB. It is cache of matrices

---

• Araq (orginal) [2017-11-16T02:33:32+01:00] view original

  Keep in mind though that this "my code is logically without side effects" is useless in a multi-threaded environment. It can be as logical as you want, the tables will cause threaded code to crash. :-)

---

• cskiraly (orginal) [2022-10-08T01:39:02+02:00] view original

  I've found the above trick useful to have a stack trace for debugging deep in a noSideEffect hierarchy, using the following little helper:

  proc noSideEffectWriteStackTrace() {.noSideEffect.} =
    cast[proc () {.nimcall, noSideEffect.}](writeStackTrace)()
  Run

  Maybe there are better ways to do the same, but this worked for me.

---

• ElegantBeef (orginal) [2022-10-08T05:20:38+02:00] view original

  The contemporary way of doing it would be

  proc noSideEffectWriteStackTrace() {.noSideEffect.} =
    {.cast(noSideEffect).}:
      writeStackTrace()
  Run

---