3 ms·
Lots of discussion about obstacles to speeding up python in older threads, e.g. https://news.ycombinator.com/item?id=12025309 https://news.ycombinator.com/item?
by shoo 6y ago
Lots of discussion about obstacles to speeding up python in older threads, e.g. https://news.ycombinator.com/item?id=12025309 https://news.ycombinator.com/item?id=12025309
- Rochus 6y agoThanks for the link. Had a quick look at the top rated comment, but "Python spends almost all of its time in the C runtime - This means that it doesn't really matter how quickly you execute the 'Python' part of Python" is already wrong. CPython is an interpreter, and this interpreter is implemented in C. You cannot argument that due to the fact that the runtime spends most of its time in C functions it makes no sense to improve it. That's exactly what a JIT (in contrast to an interpreter) is for.
- bjoli 6y agoOver in #guile on freenode we just hit a bump where string-for-each on a string was a lot slower than (for-each proc (string->list lst)) due to a costly jump into C from the jitted code. Rewriting string-for-each in scheme solved the problem. I don't know what I wanted to say with that, but I know pypy has spent a lot of time rewriting some core libraries in python/Rpython. I thought it was to make pypy more hackable, but maybe it has some jit benefits as well.