On 20/10/2012, at 1:58 PM, Alan Silverstein wrote: > libJudy is actually remarkably OS-agnostic.
Indeed, since it's primarily about memory operations, where the primary assumption is linear addressing. Actually the performance is highly *processor* sensitive since it is optimised for Intel/conventional cache structure: not clear if it would perform well on ARM processor for example. > Nowadays I educate people that if you can build for N known > architectures or platforms, you are not portable to N+1 without work. > Much smarter to build according to specific OS resources/features, or > better yet, defer "binding" from compile/link to run-time if you can do > so elegantly and without significant performance loss. > Agreed, inline functions came along in HPUX too late for us, so I ended > up using macros. They really are about the same functionality, The problem is that the macros "gloss over" the difference between rvalues and lvalues. In C++ with references, inline functions with the same signatures as the macros do not. Consequently the failure of the documentation to clearly indicate which arguments are lvalues and which are rvalues would be less significant. Basically I think reference types in C++ are a bad idea anyhow, in general the whole idea of lvalues is wrong. The right way is to use pointers, which the raw C interface does. Unfortunately the actual C interface isn't documented :) > Although Doug'll probably pipe up saying in modern compilers/computers, > function call overhead time is negligible, etc. This is not correct. In a loop, the cost of repeated subroutine calls (JSR instruction) can be negative, that is, it can be faster than if the code were inlined because of a combination of branch prediction plus the fact the smaller amount of code is more likely to squeeze into the cache. But this is only true if * there are at least two calls to the routine * the argument/result protocol fits neatly into register allocation Generally inlining offers a host of optimisation opportunities to the compiler that actual calls defeat. For example, invariant code in a subroutine can be lifted out of a loop calling it, but only if the routine is inlined (or the compiler is certain that there are no other calls to it). Similarly, argument/parameter passing conventions can be thrown out for particular calls. As above this doesn't actually require inlining: a specialised version of the subroutine could be made, but this is a lot of extra work for a compiler. It can be done -- Felix does it. But I doubt most C or C++ compilers are capable of such high level optimisations because they're * written in bad languages like C and C++ * too focussed on low level optimisations (register allocations etc). Anyhow the biggest problem with Judy is that the small user community cannot change it. We can't fix of improve it, except by cloning the repository. -- john skaller [email protected] http://felix-lang.org ------------------------------------------------------------------------------ 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
