this is getting more and more confusing. The one side says this is a bug, the other says it is a feature. I will try to summarize my understanding till now:
*  openser claims that they improved something and the ser guys say this fix is useless. Daniel, Bogdan could you plesase  explain what is really behind this improvement (Sorry Weiter, but your explanation is far from being sufficient).
* The ser guys show that openser is inferior to ser but Bogdan replies this is on purpose (because otherwise a strange race situation can occur which Andrei tells us is negligable).
* I will not get into the history discussion -which I have already touched in previous mails, let alone those mails about respect and the other stuff I could not really see how they relate to this discussion.
I would really appreciate if these points were clarified -I have the impression the ball is now with Daniel and Bogdan. So plesse Bogdan do not hold to your one mail policy and help clarifying this and provide a bit more of details on the improvements of openser to core and tm.

I believe Andrei has made a good suggestion that it is in the interest of the entire community to cooperate and divide the areas of interest. By combining the great work the openser guys have done in the area of documentation and featutres with the work of ser in the area of core we will all get an even better ser/openser.
I am afraid though that while this is surely in the interest of the community this might not be in the interest of the commercial entities behind the projects.

Finally I fully agree with all of the voices that have asked to be polite and concentrate on the technical aspects of the dicussion.  I find it most destressing that in an environment that is based on cooperation for the benefit of all that an effort aiming at informing the community is faced with such remarks and sarcastic attitude.

best regards
Weiter Leiter <bp4mls@googlemail.com> wrote:
This definitely sounds impressive, but, FMI:

On 11/28/06, Andrei Pelinescu-Onciul <andrei@iptel.org> wrote:
Why would you want to change the hash size from the config? Do you
really know somebody who wanted/needed to do this? If you use a variable
for the hash size the compiler will not be able to optimize the modulo
operation (x % hash_size) and it will have to implement it using slow
DIVs. Using a 2^k constant the whole modulo operation will be optimized
to  & (2^k - 1). A DIV takes minimum 56 cycles on a P4 and 16 on an
AMD64 (and this if the operands are in _registers_ which will probably
not happen for the variable containing the hash size). An  "and" takes
only 1 cycle (and the operand is an immediate constant).
Look also at the rest of the hash function: it uses only XORs, shifts
and additions, operations that all execute in 1 cycle => for normal small
uris your DIV operation will take a very significant time from the
total ammount spent hashing.

Unfortunately Daniel didn't reply anymore (maybe he wants to cover trade secrets ;-) ), but OpenSER uses now the much faster masking operation instead of the always costly modulo (which I expect to execute faster even with the cost of extra memory fetch for the hash size). I don't know whether hashing is also cheap or the result has a good distribution, but this should be something you should look at: I expect he did some research too, before changing, maybe this is a fix worth porting.

WL.

Check out the all-new Yahoo! Mail beta - Fire up a more powerful email and get things done faster.