3 ms·

I have not found this slower-than-C to be the case. You may need to use something like `iterator getDelims` in https://github.com/c-blake/cligen/blob/master/cl

by cb321 4y ago

I have not found this slower-than-C to be the case. You may need to use something like `iterator getDelims` in https://github.com/c-blake/cligen/blob/master/cligen/osUt.nim https://github.com/c-blake/cligen/blob/master/cligen/osUt.ni... to manage memory with fewer copies/less alloc "more like C", though or perhaps `std/memfiles` memory mapped IO. More pithy ways to put it are that "there are no speed limits" or "Nim responds to optimization effort about as well as other low level languages like C". You can deploy SIMD intrinsics, for example. In my experience, it's not that hard to "pay only for what you use". As a more concrete thing, I have timed (yes, on one CPU, one test case, etc..many caveats) the tokenizer used in https://github.com/c-blake/bu/blob/main/rp.nim https://github.com/c-blake/bu/blob/main/rp.nim to be faster than that used by the Rust xsv. Of course, you really shouldn't tokenize a lot if it's costly/data is big, but rather save a binary answer that does not need parsing (or perhaps more accurately is natively parsed by the CPU).

nerdponx 4y ago
This stuff honestly goes over my head and beyond my current skillset, but it's useful to know that there is no "speed limit" in the hands of someone who knows what they're doing. My experience has been with basically translating Python and shell scripts into Nim, and occasionally comparing them with my own feeble attempts at doing the same in C.
- elcritch 4y ago
  Just a note that the "loop over lines of stdin and do some basic calculations" use case highlights probably one of the places where it's really easy to blow up Nim's performance benefits -- string or seq copies. :/ The issue is that Nim's string library ends up making copies when doing things. It's a sane default and ensures sane behavior. However, it often leads beginner's to make slower programs, sometimes even slower than equivalent Python ones. If you used `strcopy` in C a lot, you'd get similar results. Often the solution is trivial and is just to use the `var` or `openArray[T]` variants of proc's. It's one of the points in the blog post and is crucial for good real time code. I'm hopeful the new `lent` and `view` features will make it easier to use non-copy slices on strings. That'd be nice!

by cb321 4y ago

nerdponx 4y ago

This stuff honestly goes over my head and beyond my current skillset, but it's useful to know that there is no "speed limit" in the hands of someone who knows what they're doing. My experience has been with basically translating Python and shell scripts into Nim, and occasionally comparing them with my own feeble attempts at doing the same in C.

elcritch 4y ago
Just a note that the "loop over lines of stdin and do some basic calculations" use case highlights probably one of the places where it's really easy to blow up Nim's performance benefits -- string or seq copies. :/ The issue is that Nim's string library ends up making copies when doing things. It's a sane default and ensures sane behavior. However, it often leads beginner's to make slower programs, sometimes even slower than equivalent Python ones. If you used `strcopy` in C a lot, you'd get similar results. Often the solution is trivial and is just to use the `var` or `openArray[T]` variants of proc's. It's one of the points in the blog post and is crucial for good real time code. I'm hopeful the new `lent` and `view` features will make it easier to use non-copy slices on strings. That'd be nice!