As a rule or thumb, I never use native C types (char, int, long, long long)
except when it simply does not matter, such as the case you sited or when
there is no choice.   However, if I remember correctly, "long" was used
instead of "int" in the case of JudyCount, because the compiler generated
better code (in loops) in the 64bit case (with the HP-PA compiler).  In the
32bit case an int and long is the same thing.  The Judy project was funded
by the HP-PA folks.  Therefore, a lot of code decisions were to "get around"
compiler/hardware deficiencies.   I have since learned my lesson: 
If you leave performance on the table, someone will pick it up and
you will be left with a "follow them" legacy.  When Microsoft decided to require
a uint64_t to be "unsigned long long", I figured they would fix that
mistake eventually.  At that time an uint32_t and uint64_t had not been
defined in a consistant  place.   I hope it is now in <stdint.h>. 

While I am reminiscing, I will mention some things about 1.0.5 Judy.
PA-risc had some serious performance problems with subroutine calls and
variable shifts.   The designers knew it and always said the would fix it in
"the next version", but it always fell below the "cut line" in the next version. 
Judy used "byte" accesses and macros to get around those problems.
But at the cost of making Judy "Endian" dependent.  Sometime later
I modified Judy to get rid of the Endianess dependency, but at some more
performance cost.

The next version of Judy does not use "byte" accesses and uses macros
only to make short, often used pieces of code more understandable.
It also uses extensive variable shifts which are very fast on modern CPUs.
Sometimes I make the Debug version of the macro a real subroutine.
(The compiler will in-line it to generate the same code as the macro).
This is an easy way to make sure the macro is written with my guidelines
of correctness (no hidden parameters, and readable).  The 64 bit version
uses "bit-counting" (popcnt instruction) extensively.  It disapoints me
that Intel made a 64bit processor (core2-duo) without that instruction.
It is probably going to be difficult to produce a 64bit Judy that runs at full speed
on that processor.  I simply do not want to hear "64bit Judy core-dumps on my
core2-duo or 32bit Judy runs slow on my PentiumIII"

I would be willing to make a version 1.0.6 of Judy, if someone would submit
(for Microsoft) the fixes and test it.  I do not have a Microsoft Windows
development path.  Last time I checked, I could not afford it. 

I am a one-person developer in retirement.  Judy is still my passion and I
am actively working on a much faster version.

Thanks for your interest,


PS.  If I remember correctly, Windows does not pack structures by default.  Make
sure that the struct jp_t is 8 or 16 bytes in size with 32 and 64 bit compiles respectively. 
I.E. assert(sizeof(jp_t) == 16); assert(sizeof(Word_t) == 8);  in the 64bit compile.
Doug Baskins <dougbaskins@yahoo.com>

From: Tim Margheim <tmargheim@neuric.com>
To: judy-devel@lists.sourceforge.net
Sent: Monday, October 22, 2012 9:07 AM
Subject: Re: JudySL with 64-bit pointers as values

On 10/19/2012 10:00 PM, john skaller wrote:
> Judy didn't select the right type for Windows, but the choice is in a
> single place. All the rest of the code is correct AFAIK.
That may be the case, but I did find some functions and objects that
have Word_t variables right next to some signed "long" variables. (The
BranchB object in JudyCount.c, for instance.)  So in Windows, that's
compiling as just a 32-bit int, while Doug & Alan wrote & tested Judy
with it as a 64-bit int.

It may be that a 32-bit int is actually enough even when Word_t is
64-bit, and it's somewhat reassuring that you haven't run into any
problems in your use, John.  (And memory is a concern for me, so I'd
love to avoid doubling the size of the member variable ints.)

But I'll be more comfortable ensuring that every variable is the same
size as when Judy was being designed & tested--unless Doug or Alan
remember the nitty-gritties well enough to express confidence that
leaving the signed ints as 32-bit shouldn't be a problem.

Tim Margheim

Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Judy-devel mailing list