Add newSeqUninitialized, closes #6401

[edubart]

This is useful as mentioned in the issue #6401

Note that this is only implemented for seq of numbers. I'm not sure if this is the correct implementation, however testing using this method I do see random numbers when initializing and no zeros anymore.

Please review.

[edubart]

Doing some test, this implementation seems to work fine with small seqs, however huge seqs is not working:

Working example:

var a = newSeqUninitialized[int](10)
echo a[^1]

Failing example:

var a = newSeqUninitialized[int](1000000)
echo a[^1]

SIGSEGV: Illegal storage access. (Attempt to read from nil?)

I don't know why, its like the newSeqOfCap doesn't actually create a seq with the desired cap.

@Araq Can you help me on this?

[edubart]

I've created another proc in system to see if this was true.

proc getCap*[T](s: seq[T]): int =
  var s = cast[PGenericSeq](s)
  return s.reserved

My test case:

var a = newSeqOfCap[int](10)
echo a.getCap() 

The test case outputs 0, either my method is wrong, or newSeqOfCap isn't working as desired.
I've opened #6403 regarding this.

[cooldome]

Have you actually seen noInit pragma in the nim language manual? https://nim-lang.org/docs/manual.html

[edubart]

I don't think noInit works with seq

[bluenote10]

Why did you close this?

[edubart]

No interest by the upstream having this as a new core function, as this also achievable by using newSeqOfCap followed by setLen

[Yardanico]

@edubart "no interest by the upstream" are you sure?
well PRs are not accepted fast in nim repo, but they're accepted when Araq has time

[edubart]

quote

Eduardo Bart @edubart Sep 22 15:55
@Araq would be a plus if you fix it and also add newSeqUninitialized(len) and maybe a getCap(seq) function too

From IRC (bridge bot) @FromIRC Sep 22 15:55
<Araq> you haven't convinced me of the merits

From IRC (bridge bot) @FromIRC Sep 22 15:56
<Araq> your FFI use cases were all covered by setLen()

I'm sure

[yglukhov]

what's the use case for this? IMO, newSeqOfCap should be enough, as it should not do initialization, and setLen should always nullify the extent no matter what to not introduce non-deterministic behavior. So to get max performance one has to do newSeqOfCap + subsequent adds.

[edubart]

Filling a huge seq (GBs of bytes length) non contiguously, fastly without double initialization, and also in parallel with OpenMP (we can't use add in parallel) , such as in machine learning tasks in https://github.com/mratsim/Arraymancer.

[Araq]

FYI I'm fine with this being closed.

[bluenote10]

Pity, I find newSeqUninitialized communicates the behavior much clearer than newSeqOfCap + setLen.

[edubart]

Indeed, Araq had to tell me a few times to become clear that this could be achieved by using newSeqOfCap + setLen. From reading the manual, setLen is not clear if it does initializes or not when growing a seq, because nim default behavior is to initialize to zeros I've thought it would. But to my surprise setLen does not initialize to zeros when growing a seq and this could be done with the combination of both funcs.

[bluenote10]

Same reasoning for me, I always thought this just wasn't possible.

[Yardanico]

@edubart maybe make a PR for docs then ? :)

[Araq]

Thinking about it, this is arguably a setLen bug that is exploited here. :D

[mratsim]

I guess we need a PR for setLenUninitialized then ;)