Re: gettimeofday is at the end of its usefulness?
| От | Benedikt Grundmann |
|---|---|
| Тема | Re: gettimeofday is at the end of its usefulness? |
| Дата | |
| Msg-id | CADbMkNMZWzbrEzUGGocUUijenuEa1upeS71yA7ceE2EXHKzwCw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: gettimeofday is at the end of its usefulness? (Greg Stark <stark@mit.edu>) |
| Ответы |
Re: gettimeofday is at the end of its usefulness?
|
| Список | pgsql-hackers |
On Thu, May 15, 2014 at 11:31 AM, Greg Stark <stark@mit.edu> wrote:
There are benchmarks in the link I posted (obtained by a micro benchmarking library we developed / use internally which takes great care to obtain reliable numbers) . We use posix threads extensively. We internally spend a lot of time setting up ntp and monitoring systems so that clock backwards never happens (so with other words I wouldn't be surprised if the library does NOT work correctly when it does -- our protection is outside). I do not believe we have seen the tdtsc going backwards on thread context switch you mention (and as said we use lots of threads). OS? Centos 6.5 primarily.
> I posted this on this mailing list before at Jane Street we have developedWhat OS do you run it on though? How fast is your implementation
> very fast code to get timing information based on TSC if available. It's
> all ocaml but well documented and mostly just calls to c functions so should
> be easy to port to C and we release it under a very liberal license so it
> should be no problem to take the ideas:
compared to the kernel implementation of clock_gettime()?
Are you sure your implementation is actually faster? And are you sure
you're protected against clocks going backwards? I think you should
put some i/o in the loop in the test and start several threads running
it to make it more likely the thread is rescheduled to a different
processor during the test. It suspect you'll find the rdtsc goes
backwards sometimes or produces crazy results when switching
processors.
There are benchmarks in the link I posted (obtained by a micro benchmarking library we developed / use internally which takes great care to obtain reliable numbers) . We use posix threads extensively. We internally spend a lot of time setting up ntp and monitoring systems so that clock backwards never happens (so with other words I wouldn't be surprised if the library does NOT work correctly when it does -- our protection is outside). I do not believe we have seen the tdtsc going backwards on thread context switch you mention (and as said we use lots of threads). OS? Centos 6.5 primarily.
--
greg
В списке pgsql-hackers по дате отправления: