**Update** : goto-based exceptions can now handle Defects like the other
exception implementations. There is a new switch called `--panics:on` to turn
Defects into process terminations. The benefits are smaller code size and
performance improvements.
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 =
> [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
> Is there any way I can leverage multiple cores of the target system to
> maximize efficiency?
Yes, but efficiency can't be guaranteed. The workload must be sufficiently
large for the cores to most all of their time processing it, or else the
bottleneck will fall into the creation and
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
It's not a problem.
For example:
[https://github.com/status-im/nim-beacon-chain#raspberry-pi](https://github.com/status-im/nim-beacon-chain#raspberry-pi)
Some comments:
* The swap file was for a RocksDB dependency that was taken over 1GB of RAM
but compiling the Nim compiler itself might
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
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
Dear All,
I'm a beginner in NimLang and i'm trying to use it to make some programs for
Raspberry PI microcomputer (ARM proc, Raspbian(Debian) OS).
Please advise:
Is the latest (1.x?) compiler version is available for that system - since
official cite link result in 0.19.4 version only? Or
Very nice
Does it works with filters/plugins already? Say FFT3D or masktools I would
guess we would need to create a Nim wrapper for each filter.
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,
Thanks, shashlick, may be I'll check it as well.
One more question I currently troubled:
I'm trying to reach serial port from RPi. The device pluged work on 250k bod...
It works perfect on RPi with Python pyserial. It works fine with nim serial lib
under windows But when trying the same nim
Nim is available precompiled for RPi (armv6) on the nightlies releases page.
[https://github.com/nim-lang/nightlies/releases](https://github.com/nim-lang/nightlies/releases)
Thanks for answer!
Actually I just have downloaded the source and built it straight on raspberry.
And it works finally! Now lets see how it works there
FFT3D should work (I haven't tried).
I think Masktools are not available as a plugin for VapourSynth. If I am wrong,
let me know and I will wrap it.
Nice!
I think this is the equivalent:
[https://github.com/dubhater/vapoursynth-motionmask](https://github.com/dubhater/vapoursynth-motionmask)
[Added](https://github.com/mantielero/VapourSynth.nim/blob/master/src/plugins/motionmask.nim)
Let me know if it works (or not)
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
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.
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
Very sorry to be annoying but with --gc:arc, is it necessary to close the
memfile?
22 matches
Mail list logo
