Message102502
| Author |
pitrou |
| Recipients |
beazley, dabeaz, flox, kristjan.jonsson, loewis, pitrou, torsten |
| Date |
2010年04月06日.22:35:15 |
| SpamBayes Score |
2.080441e-09 |
| Marked as misclassified |
No |
| Message-id |
<1270593434.3518.62.camel@localhost> |
| In-reply-to |
<1270592538.55.0.790564762224.issue8299@psf.upfronthosting.co.za> |
| Content |
[...]
> _PyObject_Call 403 99,02
[...]
> affinity off:
> Functions Causing Most Work
> Name Samples %
[...]
> _PyObject_Call 1.936 99,23
[...]
> _threadstartex 1.934 99,13
>
> When we run on both cores, we get four times as many L1 instruction cache hits!
You mean we get 4x the number of cache /misses/, right?
This analysis is gratuitous if you can't evaluate/measure/calculate the
actual cost (in proportion of total elapsed or CPU time) of the
instruction cache misses. Perhaps it is actually negligible and the
slowdown is caused by something else.
> How best to combat this? I'll do some experiments on Windows.
> Perhaps we can identify cpu-bound threads and group them on a single
> core.
IMHO, the OS should handle this. I don't think ad-hoc platform-specific
CPU affinity tweaks belong in the Python core. |
|