Jim:

> but I suspect that internally the code relies on the assumption that a Word_t 
> must 
   be the same size as a pointer.

That is correct.  Fortunately 4Gb of RAM is a lot cheaper now.  Of course 
anything 
is possible, but memory savings would only be in very dense (non-sparse) data 
sets.  

One of the serious problems with Judy is people understanding the calling 
semantics.  
I think that has been one of my biggest headaches. 
Go ahead and try to define some semantics for your idea.   
Maybe it would be clear or not, I haven't thought about it.  

I am currently in the process of trying to come up with semantics 
for JudySLNext*() -- the new version of JudySL that includes a string 
length parameter (and allows imbedded nul chars in the string).
I suspect I will take a lot of heat on whatever I come out with.

Thank you for your interest,

Doug
 
Doug Baskins <[email protected]>



----- Original Message ----
From: Jim Lloyd <[email protected]>
To: [email protected]
Sent: Sun, December 6, 2009 5:15:03 AM
Subject: 32->32 and 64->64 on 64-bit machines

Hi,

I've used Judy Arrays in various projects for about 8 years now and have been 
very pleased with the performance for both speed and memory usage. In my 
current project I'm beginning to wish for a feature that is not currently 
available, and I'm wondering whether it is feasible.

Our applications run on 64-bit machines, and we rely heavily on both JudyL and 
JudySL. For some of our JudyL use, the keys are always 32-bits, and the values 
are counts. These counts are always well less than 2^32, so ideally we'd have a 
version of JudyL that mapped 32-bit words to 32-bit words. Its not unusual for 
one of our applications to consume well over 4Gb with these 32to32 JudyL 
arrays. I'd love to be able to cut the storage for these arrays in half.

How much effort would it be to create this feature? A JudyL array compiled for 
32-bit machine would produce the correct interface, but I suspect that 
internally the code relies on the assumption that a Word_t must be the same 
size as a pointer.

Thanks,

Jim Lloyd
Silver Tail Systems

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel


------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel

Reply via email to