[go-nuts] Uninitialized Array?

219 views
Skip to first unread message

Peter Froehlich

unread,
Apr 19, 2010, 10:20:00 AM4/19/10
to golang-nuts
Hi all,

I need to allocate an array but I don't want to pay for initializing
it to 0 all over; the data structure I have is designed to work safely
with un-initialized memory, so it's just wasted cycles for me. I've
looked around a bit and found unsafe.NewArray() but that seems to do
zero-initialization too. Is runtime.Alloc() what I want? Yes, I know,
it's not "proper" to worry about this and I should just use the
portable and documented initialized arrays. I still want to have
un-initialized ones. :-D

Cheers,
Peter
--
Peter H. Froehlich <http://www.cs.jhu.edu/~phf/>
Senior Lecturer | Director, Johns Hopkins Gaming Lab


--
Subscription settings: http://groups.google.com/group/golang-nuts/subscribe?hl=en

Russ Cox

unread,
Apr 19, 2010, 10:31:44 AM4/19/10
to Peter Froehlich, golang-nuts
> I need to allocate an array but I don't want to pay for initializing
> it to 0 all over; the data structure I have is designed to work safely
> with un-initialized memory, so it's just wasted cycles for me. I've
> looked around a bit and found unsafe.NewArray() but that seems to do
> zero-initialization too. Is runtime.Alloc() what I want? Yes, I know,
> it's not "proper" to worry about this and I should just use the
> portable and documented initialized arrays. I still want to have
> un-initialized ones. :-D

Sorry, not possible. And premature optimization.

I assume you're using a Briggs/Torczon style sparse set
or some other similar lazy data structure. The cost of zeroing
those at allocation time is not the big savings. The big savings
is not needing to re-zero them in the reset() operation.
An even bigger savings is using them across multiple operations
instead of throwing off tons of garbage. The zeroing at
allocation just doesn't enter the picture, and the cost for zeroing
large data structures is typically paid by background goroutines
anyway.

Russ

Xiance SI(司宪策)

unread,
Apr 19, 2010, 11:57:05 AM4/19/10
to r...@golang.org, Peter Froehlich, golang-nuts
Initialization by goroutines is an interesting idea! :)

So we can do

aBigArray := make([] int, 1024)
done := make(chan int)
go func() {
  for i := 0; i < 1024; i++ {
    aBigArray[i] = 0
  }
  done <- 1
}

// Do something unrelated ...

<- done

// Start using the aBigArray.

...

Do you mean this ? which can help to speed up on multi-core machines.

Xiance

Russ Cox

unread,
Apr 19, 2010, 12:31:47 PM4/19/10
to Xiance SI(司宪策), Peter Froehlich, golang-nuts
> Do you mean this ? which can help to speed up on multi-core machines.

No, I mean that at the time the data gets allocated,
the zeroing has already been done in the background
by other goroutines, so "allocate unzeroed" is not
significantly cheaper than "allocate zeroed".
And in either case, reusing the memory yourself is
a far bigger win than "allocate unzeroed".

befelemepeseveze

unread,
Apr 19, 2010, 12:43:26 PM4/19/10
to golang-nuts
On 19 dub, 17:57, Xiance SI(司宪策) <adam...@gmail.com> wrote:
> Initialization by goroutines is an interesting idea! :)
>
> So we can do
>
> *aBigArray := make([] int, 1024)
> done := make(chan int)
> go func() {
>   for i := 0; i < 1024; i++ {
>     aBigArray[i] = 0

Here only a int zero value (0) is overwritten by an another zero.

>   }
>   done <- 1
>
> }
>
> // Do something unrelated ...
>
> <- done
>
> // Start using the aBigArray.
>
> ...


Reply all
Reply to author
Forward
0 new messages