Tim:
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 wereto "get around"
compiler/hardware deficiencies. I have since learned mylesson:
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 toget 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 inretirement. Judy is still my passion and I
am actively working on a much fasterversion.
Thanks for your interest,
doug
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 <[email protected]>
>________________________________
> From: Tim Margheim <[email protected]>
>To: [email protected]
>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:
>http://p.sf.net/sfu/appdyn_sfd2d_oct
>_______________________________________________
>Judy-devel mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/judy-devel
>
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Judy-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/judy-devel
