http://qs321.pair.com?node_id=959598

BrowserUk has asked for the wisdom of the Perl Monks concerning the following question:

Questions arising from the console log below:

  1. Why does reading bits from already allocated memory cause a memory allocation?

    Yes, I am indirecting through a substr ref, but I'm only reading.

  2. Why does unpack '%32b*', $v; fail?

    It works just fine here:

    [0] Perl> print unpack '%32b*', chr( 0b10101010 );; 4

Any relevant info gratefully received. Other workarounds for the vec > 2**31 offsets bug?

The following is an annotated console log from my perl REPL.

C:\test>p1 ## Start new session 2.5 MB allocated to process ## Create a 2**32 bit bitvector [0] Perl> $v = chr(0); $v x= 512*1024*1024;; ## Just over 512 MB allocated to process ## As vec cannot address offsets > 2**31, ## create a reference to the second half of the bitvector [0] Perl> $r = \substr $v, 256*1024*1024;; ## No further memory allocated; still just over 512 MB allocated to pr +ocess ## Set some bits in the first byte of the second half of the vector ## As we can't use offsets that size, address the bits as a byte (offs +et/8) [0] Perl> vec( $v, 256*1024*1024, 8 ) = 0b10101010;; ## No further memory allocated; still just over 512 MB allocated to pr +ocess ## Now check that we can see the bits we just set ## via the reference we created (offsets == actual offset - 2**31 avoi +ding the bug [0] Perl> print vec( $$r, $_, 1 ) for 0..7;; 0 1 0 1 0 1 0 1 ## Yes! we can see the bits. (They are in the reverse order to intuiti +on, but that's okay!) ######## BUT ... the memory usage jumped from 512MB to somewhat over 7 +68 MB! ######## ## Q1 ## Why? Why does reading bits from already allocated memory caus +e a memory allocation? ## Q1 ## ## Check the length of the vector [0] Perl> print length $v;; 536870912 ## Still 512 MB ## Try counting the bits [0] Perl> print unpack "%32b*", $v;; 0 ## Q2a ## ZERO! WTF? ## Q2a ## ## Try counting them via the reference [0] Perl> print unpack "%32b*", $$r;; 0 ## Q2b ## ZERO! WTF? ## Q2b ## ## Check the byte we set is non-zero [0] Perl> print vec( $v, 256*1024*1024, 8 );; 170 ## Still set. 170 == 0b10101010 ## Set a bi in the bottom half of the vector without reference tricker +y [0] Perl> vec( $v, 7, 1 ) = 1;; ## Now count the bits again [0] Perl> print unpack "%32b*", $v;; 0 ## Q2c ## WTF? ## Check the bit was actually set [0] Perl> print vec( $v, 7, 1 );; 1 ## Yup! ## Check the bits either side are unset [0] Perl> print vec( $v, 6, 1 );; 0 [0] Perl> print vec( $v, 8, 1 );; 0 ## Yup! ## Try doing the same thing again to see it anything changed. ## (Maybe Perl was busy taking a telemarketeers phone call) [0] Perl> print unpack "%32b*", $v;; 0 ## Q2d ## NOPE! Just doesn;t see the bits? ## Q2d ## ## Check via the reference (again). [0] Perl> print unpack "%32b*", $$r;; 0

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

The start of some sanity?