30 Nov
2006
30 Nov
'06
1:05 a.m.
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(a)googlemail.com> wrote: This definitely sounds impressive, but,
FMI:
On 11/28/06, Andrei Pelinescu-Onciul <andrei(a)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.