Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re^3: Perl Hashes in C?

by flexvault (Monsignor)
on Aug 13, 2015 at 19:02 UTC ( [id://1138483]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Perl Hashes in C?
in thread Perl Hashes in C?

BrianP,

    32 bits is too wimpy; 4.3GB is not enough. But 4.3G*4.3G BYTES is clearly OverTheTop! 18446744073709551616 ????
You have to go back to the math. 8bit or 128bit machines can get the same answer, it's knowing how the bits need to be put together :-)

    Wouldn't 65536 * 4294967296 Bytes be just about right?
For you: Yes, for me, 32bits are fine for 98% of my work. All of my servers have at least 16GB, and many have many times that amount. But I can use 32bit Perl for 98% of the work (smaller footprint), and 64 bit Perl for the rest. I also have 32bit Perl with 64bit Integers.

You are used to working with decimal numbers, but pack/unpack can be used to convert between binary, octal, decimal and hexadecimal. To use 48bit RGB, just think of the 6 octets as 3 16 bit numbers. Then this works:

my $myNum = 65000 * (2**32); my ( $R,$G,$B ) = unpack("nnn", $myNum ); print "\$myNum: $myNum\n(\$R,\$G,\$B): $R\t$G\t$B\n";
A lot of monks here are better at the math than I, but I can hold my own most of the time!

For the future, ask specific questions that show your problem and when possible show the code that's demonstrating the problem. For your initial problem, you didn't have to worry about endianess, but you may have to consider it if your working with different architectures.

Good Luck...Ed

Regards...Ed

"Well done is better than well said." - Benjamin Franklin

Replies are listed 'Best First'.
Re^4: Perl Hashes in C?
by Anonymous Monk on Aug 14, 2015 at 00:05 UTC

    Ed,

    This is the part I had working. Extracting uint16 is easy

    >> ( $R,$G,$B ) = unpack("nnn", $myNum );
    My existing code:
    @ushort=unpack("S*", $buf); # Extract oodles of UINT16s
    What I can't figure out is:
    @UINT48 = unpack("???????", $BUF)
    where each UINT48 is 48bits, 6 bytes, 1 contiguous chunk 75% as large as a (long long), 150% as long as a long, 4 byte 32 bit integer, the same size as the quanta I need.

    I need 1 contiguous 6byte REDGREENBLUE

    You are calling them "n"

    >> n An unsigned short (16-bit) in "network" (big-endian) order. I use 'S' <c>>>S An unsigned short value.<<
    I have verified that the S values agree with Photoshop color picker.

    And, I broke your masterpiece tinkering with the buffer size. I was trying various sizes from 4k to 32M to find the optimal size for my large 4TB hard drives and RAID. Interesting timing results, but some wrong answers without a 4096 pixel buffer! Dang!

    With a 500+ MB/sec SSD, there is no need to buffer. With spinning drives, I usually like to grab a cache-full then process while the drive does another read-ahead. I usually work on my SSD anyway.

    Sysread must always return exactly the same byte count for the same file or the sky is falling. The size of the chunks has nothing to do with it. I screwed up something else. I may just leave it at 4096 * 6 and be done with it. It's already darn fast.

    I think I like it as-is!

    This UINT48 is going to bug me until I figure it out. I may have to hack it into Perl myself!

    Thank you, Brian

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1138483]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (5)
As of 2024-03-28 23:10 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found