4 ms·

Thanks! Yep we should do more Nim programming on microcontrollers, since they have lots more RAM nowadays.

brabel 3y ago
Nim uses the ORC "GC" by default, which is Reference-Count with cycle detection. I don't get why calling the GC explicitly is needed in your examples given RC will drop memory as soon as it goes out of scope (and there are no other aliases to it). Perhaps the "cycle detection" happens at indeterminate times? But can't you use the simple RC GC in such cases? That should also ensure you don't use more memory than C at all?!
- lupyuen 3y ago
  Thanks for the tip! I'll check with the folks who added Nim support to NuttX, and figure out whether we should call GC_runOrc()
  - auxym 3y ago
    For all embedded purposes, I'd strongly recommend sticking with `--mm:arc` and avoiding cyclical data structures (can't see much of a use for that anyways). With ARC, you don't need to "run" any runtime GC. ARC is a fully static thing, the reference-counting happens at compile time (static analysis) and the compiler injects (the equivalent of) malloc() and free() calls in the compiled code based on that. It's great for embedded IMO. You get the performance of manual memory management with the convenience of GC. The only thing to be wary of is that it "hides" a bit when allocation happens. On embedded, you often want to minimize dynamically allocated memory for performance and heap fragmentation reasons, though the latter should be less of an issue with 64 mb of RAM. In nim, you just have to remember that creatin a string, a seq or a `ref object` allocates. So you want to eg. avoid creating and destroying a string repetitively in a loop. Instead create a `var` (allocate a buffer) once, outside the loop, and modify it as needed in the iterations. Everything else in nim (including plain objects, which map to regular C structs) is stack allocated, so ARC doesn't get involved at all. Further reading: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... https://nim-lang.org/docs/mm.html https://nim-lang.org/docs/mm.html https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/nimc.html#nim-for-embedded-systems https://nim-lang.org/docs/nimc.html#nim-for-embedded-systems
    - elcritch 3y ago
      In my experiments 64+ kB of RAM works pretty with Nina allocator. It’s also a O(1) allocator. Still limiting allocations is important on embedded.
- mratsim 3y ago
  The default is ARC, no cycle detection. ARC is deterministic. ORC isn't, but doing cycles in general is usually a code smell, especially on embedded. Also the GC is type-bound and only needed if you use ref objects. If you don't, no GC.
  - brabel 3y ago
    > The default is ARC, no cycle detection. How long haven't you checked that for? It's been ORC for years. Try this with a recent nim version: nim --fullhelp -mm:orc|arc|refc|markAndSweep|boehm|go|none|regions select which memory management to use; default is 'orc' When you confidently try to correct someone, at least consider you may be wrong.
    - mratsim 3y ago
      > How long haven't you checked that for? Orc was blocked for a while due to cycles with async. I was under the impression that they were still there. > It's been ORC for years. The switch has been made for Nim v2 announced in December 2022, the PR #19972 that defaults to ORC has been made on September 2023. ORC has just celebrated 1 year as default GC, certainly not years. > When you confidently try to correct someone, at least consider you may be wrong. I don't get why you're so butthurt about this and feel the need to be so nasty in your replies.
      - brabel 3y ago
        Telling you that you're factually wrong (which you could easily check yourself in 1 minute) and that you should not jump to correct people on the Internet, propagating wrong information without considering they may actually be right, does not amount to being nasty.
        mratsim 3y ago
        Your tone is nasty

Nim uses the ORC "GC" by default, which is Reference-Count with cycle detection. I don't get why calling the GC explicitly is needed in your examples given RC will drop memory as soon as it goes out of scope (and there are no other aliases to it). Perhaps the "cycle detection" happens at indeterminate times? But can't you use the simple RC GC in such cases? That should also ensure you don't use more memory than C at all?!

lupyuen 3y ago
Thanks for the tip! I'll check with the folks who added Nim support to NuttX, and figure out whether we should call GC_runOrc()
- auxym 3y ago
  For all embedded purposes, I'd strongly recommend sticking with `--mm:arc` and avoiding cyclical data structures (can't see much of a use for that anyways). With ARC, you don't need to "run" any runtime GC. ARC is a fully static thing, the reference-counting happens at compile time (static analysis) and the compiler injects (the equivalent of) malloc() and free() calls in the compiled code based on that. It's great for embedded IMO. You get the performance of manual memory management with the convenience of GC. The only thing to be wary of is that it "hides" a bit when allocation happens. On embedded, you often want to minimize dynamically allocated memory for performance and heap fragmentation reasons, though the latter should be less of an issue with 64 mb of RAM. In nim, you just have to remember that creatin a string, a seq or a `ref object` allocates. So you want to eg. avoid creating and destroying a string repetitively in a loop. Instead create a `var` (allocate a buffer) once, outside the loop, and modify it as needed in the iterations. Everything else in nim (including plain objects, which map to regular C structs) is stack allocated, so ARC doesn't get involved at all. Further reading: https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc-in-nim.html https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc... https://nim-lang.org/docs/mm.html https://nim-lang.org/docs/mm.html https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/destructors.html https://nim-lang.org/docs/nimc.html#nim-for-embedded-systems https://nim-lang.org/docs/nimc.html#nim-for-embedded-systems
  - elcritch 3y ago
    In my experiments 64+ kB of RAM works pretty with Nina allocator. It’s also a O(1) allocator. Still limiting allocations is important on embedded.
mratsim 3y ago
The default is ARC, no cycle detection. ARC is deterministic. ORC isn't, but doing cycles in general is usually a code smell, especially on embedded. Also the GC is type-bound and only needed if you use ref objects. If you don't, no GC.
- brabel 3y ago
  > The default is ARC, no cycle detection. How long haven't you checked that for? It's been ORC for years. Try this with a recent nim version: nim --fullhelp -mm:orc|arc|refc|markAndSweep|boehm|go|none|regions select which memory management to use; default is 'orc' When you confidently try to correct someone, at least consider you may be wrong.
  - mratsim 3y ago
    > How long haven't you checked that for? Orc was blocked for a while due to cycles with async. I was under the impression that they were still there. > It's been ORC for years. The switch has been made for Nim v2 announced in December 2022, the PR #19972 that defaults to ORC has been made on September 2023. ORC has just celebrated 1 year as default GC, certainly not years. > When you confidently try to correct someone, at least consider you may be wrong. I don't get why you're so butthurt about this and feel the need to be so nasty in your replies.
    - brabel 3y ago
      Telling you that you're factually wrong (which you could easily check yourself in 1 minute) and that you should not jump to correct people on the Internet, propagating wrong information without considering they may actually be right, does not amount to being nasty.
      - mratsim 3y ago
        Your tone is nasty