4 ms·

I'm the developer of an in-production sensor analysis backend program written in Nim. Our server scripts invoke it on individual or batches of records, so it do

I'm the developer of an in-production sensor analysis backend program written in Nim. Our server scripts invoke it on individual or batches of records, so it doesn't continuously run, and we get free parallelism via the shell. I make copious use of Datamancer dataframes. The program is entirely processing logic. I have maybe 3 lines of memory semantic code in 40k lines. I rely on Nim's default behavior, wherein dynamic types such as collections are stack-managed hidden unique pointers treated as value types. The performance is impressive. I've done some exercises on the side to compare Nim's performance to C++ building large collections along with sequential and random access, and -d:release from Nim puts out results that are neck-and-neck with -O3 for C++. No special memory tricks or anything, just writing very Pythonic, clear code. Feel free to ask me anything.

bckr 1y ago
What’s the environment management story like?
- netbioserror 1y ago
  I try to keep it simple, using Make to build, and so have ran into issues with Nimble. The upcoming Atlas is supposed to fix these issues, but I don't know enough about it yet. But I remember running into conflicting name resolution with Nimble when multiple versions of a package were installed; I believe it was trying to choose betweeen a Nim 1.x package version and a Nim 2.x, which are kept in separate Nimble folders (pkgs and pkgs2). I'm probably going to sit down and give Atlas a try soon, and migrate my dependencies.
  - elcritch 1y ago
    No need to migrate dependency with Atlas. Should "Just Work". If not file a GH issue. Note, I fixed up Atlas a few months ago for Araq (Nim's BDFL). It uses a simpler design where pkgs are put in a local `deps` folder. It works fantastic and has replaced Nimble and it's magic for me. Plus the local deps folder is easy for LLM cli tools to grep. Just make sure to install the latest version! P.S. @netbioserror I'm working on a sensors project. Shoot me an email if you want to talk sensors/iot/nim! Emails on my GH
thomasmg 1y ago
Which compile options do you recommend for best performance, but such that it is still memory-save? (I assume you use memory-save, right?) Currently I use "nim c --opt:speed". Compared to other languages (Go, Rust mostly) the runtime performance (for my use cases) is a bit slower, for some of the cases. Hm, it might be that you disable memory safety, if you compare against C++...
- netbioserror 1y ago
  I just use -d:release, along with a bunch of other options related to static compilation with musl-libc. I've tried -d:danger before and the reliability of my calculations went completely out the window. I think Datamancer and Arraymancer are dependent upon some of those checks and guarantees. The --opt flag didn't make enough of a difference in my case.
deleted 1y ago
[deleted]

bckr 1y ago

What’s the environment management story like?

netbioserror 1y ago
I try to keep it simple, using Make to build, and so have ran into issues with Nimble. The upcoming Atlas is supposed to fix these issues, but I don't know enough about it yet. But I remember running into conflicting name resolution with Nimble when multiple versions of a package were installed; I believe it was trying to choose betweeen a Nim 1.x package version and a Nim 2.x, which are kept in separate Nimble folders (pkgs and pkgs2). I'm probably going to sit down and give Atlas a try soon, and migrate my dependencies.
- elcritch 1y ago
  No need to migrate dependency with Atlas. Should "Just Work". If not file a GH issue. Note, I fixed up Atlas a few months ago for Araq (Nim's BDFL). It uses a simpler design where pkgs are put in a local `deps` folder. It works fantastic and has replaced Nimble and it's magic for me. Plus the local deps folder is easy for LLM cli tools to grep. Just make sure to install the latest version! P.S. @netbioserror I'm working on a sensors project. Shoot me an email if you want to talk sensors/iot/nim! Emails on my GH

thomasmg 1y ago

Which compile options do you recommend for best performance, but such that it is still memory-save? (I assume you use memory-save, right?) Currently I use "nim c --opt:speed". Compared to other languages (Go, Rust mostly) the runtime performance (for my use cases) is a bit slower, for some of the cases. Hm, it might be that you disable memory safety, if you compare against C++...

netbioserror 1y ago
I just use -d:release, along with a bunch of other options related to static compilation with musl-libc. I've tried -d:danger before and the reliability of my calculations went completely out the window. I think Datamancer and Arraymancer are dependent upon some of those checks and guarantees. The --opt flag didn't make enough of a difference in my case.

deleted 1y ago

[deleted]