Boost logo

Boost :

From: Michiel Salters (Michiel.Salters_at_[hidden])
Date: 2001-03-19 03:21:39


std::vector<bool> is probably the most efficient way to stuff any random
number of bits into the smallest space, without domain-specific
knowledge.

But this might be quite inefficient for hash-tables. Optimizing space-time
tradeoffs is very implementation-dependant. E.g. misaligned reads are
more expensive on Sparcs than on x86 , so stuffing 5 bytes of data
in 8 bytes of memory might or might not be the fastest solution.

W.r.t. to your general claim, I'd argue that the ability to store data
efficiently in memory is of limited use: most programs just don't need
that much data at a time. That allows the use of virtual memory.

Michiel Salters

> -----Original Message-----
> From: pinkfloydhomer_at_[hidden] [mailto:pinkfloydhomer_at_[hidden]]
> Sent: Friday, March 16, 2001 11:26 PM
> To: boost_at_[hidden]
> Subject: [boost] Compact Data
>
>
> I may be asking a stupid question here, and it might even be off
> topic (it's becoming a bad habit), but here goes:
>
> Is there currently in standard C++ a structured way to represent data
> compactly, other than the old C bitfields?
>
> If there isn't, couldn't this be a relevant thing for Boost?
>
> Sometimes, you just need all the memory you can get, and it would be
> nice if there were a really structured way of doing this.
>
> In my particular case, I am using a hashtable in a chess program, and
> the performance in practice is directly dependant on effecient
> hashtable operations and space effecient storage of the entries,
> because more entries is better. This is not your typical hashtable,
> but one somewhat adapted to it's specific use, so I can't really use
> anything else. Also, the need to store data effeciently in memory, is
> very general.
>
>
> List-Unsubscribe: <mailto:boost-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk