Message 101711 - Python tracker

➜

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	pitrou
Recipients	DazWorrall, alex, brian.curtin, carljm, coderanger, dabeaz, eric.smith, flox, jcea, jhylton, karld, kevinwatters, loewis, mahmoudimus, nirai, pitrou, rcohen, rh0dium, tarek
Date	2010年03月25日.15:52:56
SpamBayes Score	0.0031386733
Marked as misclassified	No
Message-id	<1269532487.3360.19.camel@localhost>
In-reply-to	<1269531159.16.0.774435758434.issue7946@psf.upfronthosting.co.za>

Content
> Please specify system and test details so I can try to look into it. It's a dual-core Linux x86-64 system. But, looking at the patch again, the reason is obvious: #define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted \|\| (tstate->tick_counter % 1000 == 0)) `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, which based its speculative operation on the number of elapsed opcodes (and which also gave bad latency numbers on the regex workload). By the way, I configure --with-computed-gotos.

Content

> Please specify system and test details so I can try to look into it.
It's a dual-core Linux x86-64 system. But, looking at the patch again,
the reason is obvious:
#define CHECK_SLICE_DEPLETION(tstate) (bfs_check_depleted || (tstate->tick_counter % 1000 == 0))
`tstate->tick_counter % 1000` is replicating the behaviour of the old
GIL, which based its speculative operation on the number of elapsed
opcodes (and which also gave bad latency numbers on the regex workload).
By the way, I configure --with-computed-gotos.

History
Date	User	Action	Args
2010年03月25日 15:52:58	pitrou	set	recipients: + pitrou, loewis, jhylton, jcea, eric.smith, kevinwatters, tarek, karld, carljm, coderanger, nirai, alex, brian.curtin, flox, DazWorrall, rh0dium, rcohen, dabeaz, mahmoudimus
2010年03月25日 15:52:57	pitrou	link	issue7946 messages
2010年03月25日 15:52:57	pitrou	create

homepage