Nir Aides <[email protected]> added the comment:
On Tue, Apr 27, 2010 at 12:23 PM, Charles-Francois Natali wrote:
> @nirai
> I have some more remarks on your patch:
> - /* Diff timestamp capping results to protect against clock differences
> * between cores. */
> _LOCAL(long double) _bfs_diff_ts(long double ts1, long double ts0) {
>
> I'm not sure I understand. You can have problem with multiple cores when
> reading directly the
> TSC register, but that doesn't affect gettimeofday. gettimeofday should be
> reliable and accurate
> (unless the OS is broken of course), the only issue is that since it's wall
> clock time, if a process
> like ntpd is running, then you'll run into problem
I think gettimeofday() might return different results on different cores as
result of kernel/hardware problems or clock drift issues in VM environments:
http://kbase.redhat.com/faq/docs/DOC-7864
https://bugzilla.redhat.com/show_bug.cgi?id=461640
In Windows the high-precision counter might return different results on
different cores in some hardware configurations (older multi-core processors).
I attempted to alleviate these problems by using capping and by using a "python
time" counter constructed from accumulated slices, with the assumption that IO
bound threads are unlikely to get migrated often between cores while running. I
will add references to the patch docs.
> - did you experiment with the time slice ? I tried some higher values and got
> better results,
> without penalizing the latency. Maybe it could be interesting to look at it
> in more detail (and
> on various platforms).
Can you post more details on your findings? It is possible that by using a
bigger slice, you helped the OS classify CPU bound threads as such and improved
"synchronization" between BFS and the OS scheduler.
Notes on optimization of code taken, thanks.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue7946>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
