> David explained that in the issue tracker - 2.x typically doesn't do > that much work per bytecode instruction, Oh, but that's wrong in general. Dave's *spinning loop* doesn't do much work per bytecode instruction, however ;) > The current settings mean we have less GIL overhead in the normal case, > but worse worst-case I/O latency. Actually, ccbench shows that worst case IO latency is much worse in 2.x (when executing bytecodes which do a lot of work, e.g. matching a regex). What happens though is that best case IO latency is better in 2.x (e.g. spinning loop, or short opcodes approaching the spinning loop case :-)). cheers 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