> Is this a Nim problem or a GCC problem?
Neither. Modern CPUs are complex beasts and sometimes it's impossible to say
what is going on. the XOR version is slightly longer, this means different
instruction cache behaviour and/or branch prediction behaviour.
I guess more people would regard your post serious if you would not use terms
like "the program runs 4+ seconds slower".
What does that mean when maybe total runtime is a few hours?
And you did not tell us your CPU type and OS (32 or 64 bit), ARM, MIPS or x86
processor?
Generally, the result i
I looked at the generated C code for both versions. They have exactly the same
structure (reference names are different) and exactly the same number of total
lines-of-code (loc).
Here's the C code generated for the different Nim versions snippets.
while (1) {
if (!
> solved, my bad, sorry
It would be much more beneficial if you could also post _how_ did you solve it,
to help others in the future that might search forum for the same /similar
problem.
Oh by the way, the compiled code for `a[k] = 1` was 95 bytes bigger, using gcc
4.9.2
So I'm cleaning up some code, and came across this problem.
I simplified one line of code, which caused a 4+ seconds performance hit.
I have an array of bytes defined as: `a: seq[unit8]` initialized to all `0s`.
Inside a loop, called millions of times, I'm setting the lsb to `1` when
required.
getting this error while moving existing file to existing directory:
move
/mnt/314-serif/development/Personal/kostovsky/railway/try_again/video/2018.04.16/02.37.14.avi
move to
/mnt/314-serif/development/Personal/kostovsky/railway/try_again/video/2018.04.16/02.38.11.avi
parse
solved, my bad, sorry
