Re: [Serusers] Re: [Users] TM : retransmission timers

On Nov 27, 2006 at 23:16, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: Such as? I really think that you should try to chill out a little. Instead of being happy that someone ran some benchmarks (which you should probably do more often), you continue to try attack our tests, but you fail to point what's wrong with them (you can see all the configs and the compile parameters used). As a matter of fact there was an error, but this involved ser. ser.cvs was compiled with malloc debugging (-DDBG_QM_MALLOC and without -DF_MALLOC). So ser pre-release is even faster. These were only some benchmarks, you can fix the performance problems in a new release or you can ignore them and concentrate on stuff you find more important. If you dislike so much being benchmarked, then put something like "please don't publish benchmark results for openser" in the README and/ or the web page. To answer in the same spirit you wrote all your mails in this thread: if this was not a cosmetic fix (you've just replaced the hash with the hash from core) and you were really concerned about the performance then why haven't you changed the hash table size too? 512 is far too small (I won't give any perfromance numbers I don't want to make you even more angrier :-)) 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. Note also that there is another difference: we use a different hash function in ser, one that gives very good distributions also for numbers (.e.g. 12345(a)foo.bar) and not only strings. We never claimed this was the most optimized setup possible. As I pointed out ser was the one which was handicaped. I would however appreciate if you would share some of the secret openser tunning that would have changed the test results. Speaking of the hashes: it's not our fault if you choose the wrong value for them. Hash size is always a compromise between memory usage and speed (and usually some testing is necessary to find the best values). openser was neither exactly a "low memory" user or fast. Note: I have no ideea if you did really choose bad hash sizes for tm (since this is what you seem to imply), but if you kept the values from 0.9.4 you should be safe. Let me thank once again for the bug report. However let me point out that what you call invalid functionalities are some minor variable timer problems that in the worst case will extend a final reponse timer for ser 0.9.x (if variable timers are used). Do you mean in openser? Sorry, all this time I thought you were in denial, I haven't expected such a straight confession :-) Indeed, you're not saying directly that ser is dead, you're only spreading FUD. Andrei, amazed on how much anger a few simple benchmarks can produce [...]