Questions arising from the console log below:
- 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.
- 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".
-
Are you posting in the right place? Check out Where do I post X? to know for sure.
-
Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
<code> <a> <b> <big>
<blockquote> <br /> <dd>
<dl> <dt> <em> <font>
<h1> <h2> <h3> <h4>
<h5> <h6> <hr /> <i>
<li> <nbsp> <ol> <p>
<small> <strike> <strong>
<sub> <sup> <table>
<td> <th> <tr> <tt>
<u> <ul>
-
Snippets of code should be wrapped in
<code> tags not
<pre> tags. In fact, <pre>
tags should generally be avoided. If they must
be used, extreme care should be
taken to ensure that their contents do not
have long lines (<70 chars), in order to prevent
horizontal scrolling (and possible janitor
intervention).
-
Want more info? How to link
or How to display code and escape characters
are good places to start.