Someday destructors may be defined/automatically called, but today there will
be no clean-up without the `close` call. You may not need to/want to clean-up
anyway.
need to: `memfiles.open()` creates a memory mapping, but does not (by default)
keep the file descriptor open. The only thing the
Very sorry to be annoying but with --gc:arc, is it necessary to close the
memfile?
Well, the data "on disk" is not NUL-terminated. So, though the type I am using
is called "cstring" the string data is not terminated. If anything, the data is
more "newline terminated" in your file format. Those newlines are mapped out by
the `memSlices` iterator, though with the result stored
Just a small question regarding your parseUint, you are taking an argument
called size. If I convert something to a cstring, wouldn't I get a null
terminated string? In which case I can just check if the char is 0 or not to
end the loop.
One vexing thing about modern CPUs is that a single CPU core cannot saturate
RAM bandwidth. So, while throughput in L1 can be 100..200 GB/sec, and RAM
bandwidth might be 50..150 GB/s, the amount just one L1 cache system can read
from L2/L3/DIMMs might be only 5-30 GB/sec. This puts (often much
Note that with a shared table, accesses will need to be serialized to ensure
soundness and data consistency:
* This means that threads will compete for cache accesses and might lead to
cache thrashing/cache ping-pong/false sharing/cache invalidation. If your task
per thread is short (less
Oh, and if you did want to use a zero copy IO interface like `memfiles` on
this, you can and indeed it is over 3X faster, but you have to write your own
integer parser because `parseUint` and all its analogues take a Nim `string`
not `MemSlice`. You can use the dollar operator `$` to convert,
This topic can be confusing to beginners because the word "read" is overloaded.
There is a "system call" named "read", but also many higher level APIs that are
"buffered" which are also called "read", and people often refer to the general
activity as just "reading". The buffering means those
> [https://nim-lang.org/docs/sharedtables.html](https://nim-lang.org/docs/sharedtables.html)
Thank you, I never noticed it. I love Nim's stdlib!
> What would be faster is to read from the file line-by-line.
I always thought calling read() over and over again is fairly expensive. That
said I
eation and destruction of threads, which will
make it slower than the single threaded version. See
[https://forum.nim-lang.org/t/5909](https://forum.nim-lang.org/t/5909) for an
example of inefficiency caused by threading.
But back to the main question:
> Is it possible to share a Hashmap between thre
In pursuit of optimizing the following code, I realized that if somehow the
loop is paralleled (i.e. each thread operates on a certain chunk of the array),
the code may execute faster:
import tables, os, parseutils, strutils
proc ytz(args: openArray[string]): uint =
11 matches
Mail list logo
