Hello again, > It shows that, on my platform for this specific benchmark: > * newgil manage to leverage a significant amount of parallelism > (1.7) where python 3.1 does not (3.1 is 80% slower) I think you are mistaken: -j0 (main thread only) newgil: 47.483s, 47.605s, 47.512s -j4 (4 consumer threads, main thread producing/waiting) newgil: 48.428s, 49.217s The runtimes are actually the same, so newgil doesn't leverage anything. However, it doesn't degrade performance like 2.x/3.1 does :-) > * newgil as a small impact on non multi-threaded execution > (~1-2%) [may be worth investigating] It goes from very slightly slower to very slightly faster and it is likely to be caused by variations in generated output from the compiler. > * 3.1 is more than 2 times slower than python 2.6 on this > benchmark That's the most worrying outcome I'd say. Are you sure the benchmark really does the same thing? Under 2.6, you should add re.UNICODE to the regular expression flags so as to match the 3.x semantics. > [if I understood correctly in 3.x regex release the GIL]. Unless I've missed something it doesn't, no. This could be a separate opportunity for optimization, if someone wants to take a look at it. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4