From: Doug B. <dou...@ya...> - 2012-10-22 17:35:04
|
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 <dou...@ya...> >________________________________ > From: Tim Margheim <tma...@ne...> >To: jud...@li... >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 >Jud...@li... >https://lists.sourceforge.net/lists/listinfo/judy-devel > > > |