Message101613
| Author |
pitrou |
| Recipients |
DazWorrall, alex, brian.curtin, carljm, coderanger, dabeaz, eric.smith, flox, jhylton, karld, kevinwatters, loewis, mahmoudimus, nirai, pitrou, rcohen, rh0dium, tarek |
| Date |
2010年03月24日.01:13:44 |
| SpamBayes Score |
5.267697e-07 |
| Marked as misclassified |
No |
| Message-id |
<1269393334.4874.14.camel@localhost> |
| In-reply-to |
<1269391296.08.0.748824407099.issue7946@psf.upfronthosting.co.za> |
| Content |
> I upload bfs.patch
Interesting patch, but:
- Please give understandable benchmark numbers, including an explicit
comparison with baseline 3.2, and patched 3.2 (e.g. gilinter.patch)
- Please also measure single-thread performance, because it looks like
you are adding significant work inside the core eval loop
- Do you need a hi-res clock? gettimeofday() already gives you
microseconds. It looks like a bit of imprecision shouldn't be
detrimental.
- The magic number DEADLINE_FACTOR looks gratuitous (why 1.1^20 ?)
- By the way, I would put COND_SIGNAL inside the LOCK_MUTEX /
UNLOCK_MUTEX pair in bfs_yield().
If this gets accepted there will be cosmetic issues to watch out (and
the patch should be cross-platform). |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2010年03月24日 01:13:47 | pitrou | set | recipients:
+ pitrou, loewis, jhylton, eric.smith, kevinwatters, tarek, karld, carljm, coderanger, nirai, alex, brian.curtin, flox, DazWorrall, rh0dium, rcohen, dabeaz, mahmoudimus |
| 2010年03月24日 01:13:45 | pitrou | link | issue7946 messages |
| 2010年03月24日 01:13:44 | pitrou | create |
|