Front page | perl.perl6.internals |
Postings from May 2005
>>>>> "LT" == Leopold Toetsch <lt@toetsch.at> writes: LT> Uri Guttman wrote: >>>>>>> "LT" == Leopold Toetsch <lt@toetsch.at> writes: LT> I'm currently rewriting the hash implementation in >> src/hash.c. The LT> new hash structure has just one piece of malloced memory with LT> bucket pointers and buckets in one piece. >> here is an odd thought to add to that. since your hash is a single >> hunk >> of ram, you could use offsets inside it instead of pointers. that means >> it could be both shareable (given locks) and even writable to disk. LT> I don't see the difference WRT shareable, but yes, the memory hunk LT> could be written at once for freezing, which may save some LT> cycles. More importantly it doesn't need relocation during LT> hash_expand(), if offsets are calculated from start of mem. sharing is also simpler since the hash can be mmap'ed to different virtual addresses in different processes and with offsets they don't have any issues with pointers into/inside that space. it is the same advantage if has for freezing and thawing. LT> With some benchmarks we can see, which is better, but using offsets LT> seems to be a good idea. it can't hurt as it is about the same amount of cpu work (1 more addition of the chunk base address is needed) but the wins for sharing and freeze/thaw may make that worth it. also you could declare a hash to be offset based so the compiler/optimizer code generates offset based code (that is if people want that 1 addtion optimized away if offsets aren't used. uri -- Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs ---------------------------- http://jobs.perl.orgThread Previous | Thread Next