➜

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.
History
Date User Action Args
2010-03-25 15:52:58pitrousetrecipients: + 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:57pitroulinkissue7946 messages
2010-03-25 15:52:57pitroucreate