w*x
发帖数: 518 | 1 花了几个钟头研(goo)究(gle)了一下为毛Python要留着GIL不改掉，作为一个非CS人感
觉自己的智商好不够用...总结如下：1.5时代去掉GIL以后和没有去掉GIL比较，由于大
量的lock calls，单线程速度大幅度下降，而对于纯python的应用范围内这显得得不偿
失。所以，权衡的结果，是在纯python的时候用多进程取代多线程，同时在更低层次上
需要用多进程的时候，利用c-extensions来实现多线程操作。
不知道大家咋想？ |
p*****2
发帖数: 21240 | 2 这东西没啥前途吧？
【在 w*x 的大作中提到】
: 花了几个钟头研(goo)究(gle)了一下为毛Python要留着GIL不改掉，作为一个非CS人感
: 觉自己的智商好不够用...总结如下：1.5时代去掉GIL以后和没有去掉GIL比较，由于大
: 量的lock calls，单线程速度大幅度下降，而对于纯python的应用范围内这显得得不偿
: 失。所以，权衡的结果，是在纯python的时候用多进程取代多线程，同时在更低层次上
: 需要用多进程的时候，利用c-extensions来实现多线程操作。
: 不知道大家咋想？
|
w*x
发帖数: 518 | 3 看领域吧？我不知道在网站架构方面是不是已经过时了，但是科学计算里面用的人多。
用的人多，资源就多，同行评议里面废话也会少……
【在 p*****2 的大作中提到】
: 这东西没啥前途吧？
|
L***s
发帖数: 1148 | 4
大致如此。主要原因之一是基于引用计数的垃圾回收，
CPython代码里很多Py_INCREF和Py_DECREF的macros，
去掉GIL之后这些引用计数操作就不是线程安全的了。
所以在每个线程装个大锁，实现bytecode级别的线程安全。
【在 w*x 的大作中提到】
: 花了几个钟头研(goo)究(gle)了一下为毛Python要留着GIL不改掉，作为一个非CS人感
: 觉自己的智商好不够用...总结如下：1.5时代去掉GIL以后和没有去掉GIL比较，由于大
: 量的lock calls，单线程速度大幅度下降，而对于纯python的应用范围内这显得得不偿
: 失。所以，权衡的结果，是在纯python的时候用多进程取代多线程，同时在更低层次上
: 需要用多进程的时候，利用c-extensions来实现多线程操作。
: 不知道大家咋想？
|
w*x
发帖数: 518 | 5 谢谢回复！
所以都是ref counting惹的祸啊…搜了一转，大多说是因为在早期的时候GC远没现在这
么成熟，ref counting的方法又简单，就用了；哪儿想到这么多年以后多核运算这么普
及…
早在py3k开发时期有人问Guido说，能把这个ref counting换掉吗？答复说，那所有
code都重写，改动太大了…就只得作罢。
历史残留问题真是处处都有啊，嘿嘿。
[发表自未名空间手机版 - m.mitbbs.com]
【在 L***s 的大作中提到】
:
: 大致如此。主要原因之一是基于引用计数的垃圾回收，
: CPython代码里很多Py_INCREF和Py_DECREF的macros，
: 去掉GIL之后这些引用计数操作就不是线程安全的了。
: 所以在每个线程装个大锁，实现bytecode级别的线程安全。
|
L***s
发帖数: 1148 | 6
As far as I know, refcnt is a major reason, but not the whole story.
Python (as well as Ruby) VM bytecodes are simply way too high level
for any finer-grain locks to be useful.
PyPy, another Python implementation that trace-JITs the interpreter
itself instead of the Python program, does not support refcnt semantics
--it uses multiple gc algorithms, with minimark being the default one--
but it still has GIL present, for many reasons.
You may take a look at their STM proposal to get some ideas
http://pypy.org/tmdonate.html
【在 w*x 的大作中提到】
: 谢谢回复！
: 所以都是ref counting惹的祸啊…搜了一转，大多说是因为在早期的时候GC远没现在这
: 么成熟，ref counting的方法又简单，就用了；哪儿想到这么多年以后多核运算这么普
: 及…
: 早在py3k开发时期有人问Guido说，能把这个ref counting换掉吗？答复说，那所有
: code都重写，改动太大了…就只得作罢。
: 历史残留问题真是处处都有啊，嘿嘿。
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
p*****2
发帖数: 21240 | 7
换个语言了事
【在 w*x 的大作中提到】
: 谢谢回复！
: 所以都是ref counting惹的祸啊…搜了一转，大多说是因为在早期的时候GC远没现在这
: 么成熟，ref counting的方法又简单，就用了；哪儿想到这么多年以后多核运算这么普
: 及…
: 早在py3k开发时期有人问Guido说，能把这个ref counting换掉吗？答复说，那所有
: code都重写，改动太大了…就只得作罢。
: 历史残留问题真是处处都有啊，嘿嘿。
:
: [发表自未名空间手机版 - m.mitbbs.com]
|
w*x
发帖数: 518 | 8 Makes total sense. Thank you for sharing the knowledge and the link! I
learned a lot.
【在 L***s 的大作中提到】
:
: As far as I know, refcnt is a major reason, but not the whole story.
: Python (as well as Ruby) VM bytecodes are simply way too high level
: for any finer-grain locks to be useful.
: PyPy, another Python implementation that trace-JITs the interpreter
: itself instead of the Python program, does not support refcnt semantics
: --it uses multiple gc algorithms, with minimark being the default one--
: but it still has GIL present, for many reasons.
: You may take a look at their STM proposal to get some ideas
: http://pypy.org/tmdonate.html
|
w*x
发帖数: 518 | 9 没有更好的换啊！科学计算里面，用过好几年的matlab和R，代码重用性都很不好。
Python的函数库多，代码质量也高，大部分应用速度也没问题（multi-processing +
Cython 可以解决并行问题）。
如果换的话，科学计算里面还有更好的选择吗……？
【在 p*****2 的大作中提到】
:
: 换个语言了事
|
