Pradeep:
Sorry, that is correct. I think the purpose of that union was to force
the compiler to "pack" the items.
Thanks for your interest,
doug
Doug Baskins <[email protected]>
>________________________________
> From: "Bisht, Pradeep" <[email protected]>
>To: Doug Baskins <[email protected]>; Tim Margheim <[email protected]>;
>"[email protected]" <[email protected]>
>Sent: Monday, October 22, 2012 12:16 PM
>Subject: Re: JudySL with 64-bit pointers as values
>
>
>Hello Doug, you meant "union jp_t". correct ? I don't see any "struct jp_t".
>
>
>
>typedef union J_UDY_POINTER // JP.
> {
> jpo_t j_po; // other than immediate indexes.
> jpi_t j_pi; // immediate indexes.
> } jp_t, *Pjp_t;
>
>
>
>________________________________
> From: Doug Baskins <[email protected]>
>To: Tim Margheim <[email protected]>; "[email protected]"
><[email protected]>
>Sent: Monday, October 22, 2012 10:34 AM
>Subject: Re: JudySL with 64-bit pointers as values
>
>
>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
>
>
>
>
>
>
>------------------------------------------------------------------------------
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
