w***g
发帖数: 5958 | 1 搞得我整天都在等结果上bbs. 本来应该是C++写的核心计算程序是瓶颈, 结果外围的
python程序比核心程序还慢. 真是郁闷死我了. 貌似还不能parallelize, 怎么会有这
种弱智的解释器! |
c****e
发帖数: 1453 | |
w***g
发帖数: 5958 | 3 可怜我花了大量时间想核心算法的scalability, 结果死在了python的interpreter
lock上.
【在 c****e 的大作中提到】
: haha.坐等有人让你起多进程。
|
s***o
发帖数: 2191 | 4 早就说过了，PHP才是世界上最好的语言，赶紧换吧
【在 w***g 的大作中提到】
: 搞得我整天都在等结果上bbs. 本来应该是C++写的核心计算程序是瓶颈, 结果外围的
: python程序比核心程序还慢. 真是郁闷死我了. 貌似还不能parallelize, 怎么会有这
: 种弱智的解释器!
|
t****a
发帖数: 1212 | 5 你不是玩haskell的嘛，好好的haskell并行不用怎么跑回python来了，是不是图上面的
package多，呵呵。
【在 w***g 的大作中提到】
: 可怜我花了大量时间想核心算法的scalability, 结果死在了python的interpreter
: lock上.
|
w**z
发帖数: 8232 | 6 multi processor?
【在 w***g 的大作中提到】
: 可怜我花了大量时间想核心算法的scalability, 结果死在了python的interpreter
: lock上.
|
s********k
发帖数: 6180 | 7 多线程和CPU intensive的工作就不适合python，换event based或者核心代码用C写，
python调用库就是了
【在 w***g 的大作中提到】
: 可怜我花了大量时间想核心算法的scalability, 结果死在了python的interpreter
: lock上.
|
z*******3
发帖数: 13709 | |
p**o
发帖数: 3409 | 9
对自己不熟悉的东西不要乱给“建议”
楼主的计算内核是用C/C++写的
jython调用不了C扩展
【在 z*******3 的大作中提到】
: 楼主，给你一个小建议
: 有个东西叫jyphon
|
z*******3
发帖数: 13709 | 10 对自己不熟悉的东西不要乱给“建议”
有个东西叫做jni
【在 p**o 的大作中提到】
:
: 对自己不熟悉的东西不要乱给“建议”
: 楼主的计算内核是用C/C++写的
: jython调用不了C扩展
|
|
|
w****k
发帖数: 6244 | 11 cpython 直接调用c不就可以，干嘛绕那么大弯用jython和jni
【在 z*******3 的大作中提到】
: 对自己不熟悉的东西不要乱给“建议”
: 有个东西叫做jni
|
d***q
发帖数: 1119 | 12
jython现在还无法和python比较性能， 我有个协议的解析程序。jython 只有大约 1/3
-1/2的性能。如果jython下一个版本能有效利用 jvm的dynamic invoke指令，那么说不
定会
有所提高。
jython用jni来调用c就太迂回了，先不说jni大多数时候效率并不高，而且如果要用c,
干吗要用jython? 如果是cpu-intensive，这里面也要看是什么类型的计算，有部分可
以用java写，性能也不差。
【在 p**o 的大作中提到】
:
: 对自己不熟悉的东西不要乱给“建议”
: 楼主的计算内核是用C/C++写的
: jython调用不了C扩展
|
y****e
发帖数: 23939 | 13 profile一下，看看是哪部分慢。能把源代码贴出来吗？不会是人笨怪刀钝吧？
【在 w***g 的大作中提到】
: 搞得我整天都在等结果上bbs. 本来应该是C++写的核心计算程序是瓶颈, 结果外围的
: python程序比核心程序还慢. 真是郁闷死我了. 貌似还不能parallelize, 怎么会有这
: 种弱智的解释器!
|
z*******3
发帖数: 13709 | 14 都不看原帖？
楼主在抱怨cpython慢啊
【在 w****k 的大作中提到】
: cpython 直接调用c不就可以，干嘛绕那么大弯用jython和jni
|
c****e
发帖数: 1453 | 15 有个global lock，没办法。
【在 y****e 的大作中提到】
: profile一下，看看是哪部分慢。能把源代码贴出来吗？不会是人笨怪刀钝吧？
|
z*******3
发帖数: 13709 | 16 宾狗
对于楼主来说，最简单的就是抛弃python上jvm
但是问题在于，这样做就丢掉了原来的代码
上jyphon可以最大程度复用代码
另外就是，jni只是一个小接口，这个有什么效率不效率的
一步的效率再慢能慢到哪里去，后面执行都是c的效率
前台执行完全是jvm的效率，这两个效率都明显有保证
有的是办法做优化，jvm的优化是几十年的积累
估计楼主用的就是web，上tomcat
效率明显高过各种乱七八糟的web server
这个效率也是n个人说过的例子了
/3
【在 d***q 的大作中提到】
:
: jython现在还无法和python比较性能， 我有个协议的解析程序。jython 只有大约 1/3
: -1/2的性能。如果jython下一个版本能有效利用 jvm的dynamic invoke指令，那么说不
: 定会
: 有所提高。
: jython用jni来调用c就太迂回了，先不说jni大多数时候效率并不高，而且如果要用c,
: 干吗要用jython? 如果是cpu-intensive，这里面也要看是什么类型的计算，有部分可
: 以用java写，性能也不差。
|
h**********0
发帖数: 88 | 17 为什么不试试pypy？
完全提高了N个档次。。。。（官方是说跟C差不多） |
d***q
发帖数: 1119 | 18
pypy 可以有效消除 function call的开销，不过对于数值计算，效果不如用cython。
而且现在pypy的坑也比较多，就算是2.0也是如此。
【在 h**********0 的大作中提到】
: 为什么不试试pypy？
: 完全提高了N个档次。。。。（官方是说跟C差不多）
|
d***q
发帖数: 1119 | 19 这个效率问题还是要看具体的例子。
如果仅仅是单纯 计算一下 然后返回。那么使用jni也没啥问题。但是如果有些场景需
要做大量的交互， 不停在边界上进出，这时jvm没法很好优化， 效率反而还不如直接
用java。
我几年前搞过一些gis的东西。之前有一套系统的计算用c++写，然后用jni来调用，问
题特别多。最后全部用java写，现在用了几年也没啥问题，之前还担心性能会降低，后
来发现还好了，没有想象中的慢。
现在对于这种场景，我的做法是把这些 要计算的封装一下，做个服务，用个rpc之类的
call一下就好。不通过jni来调用。容易调试，反正计算部分的耗时要远大于call的开
销。用rpc也无所谓。
如果是一些cpu intensive & io intensive都有的，这时候直接用java来写90%也能
满足，如果还不能满足，就只有上c++了，整个都替换，不过这种极端的情况甚为少见。
【在 z*******3 的大作中提到】
: 宾狗
: 对于楼主来说，最简单的就是抛弃python上jvm
: 但是问题在于，这样做就丢掉了原来的代码
: 上jyphon可以最大程度复用代码
: 另外就是，jni只是一个小接口，这个有什么效率不效率的
: 一步的效率再慢能慢到哪里去，后面执行都是c的效率
: 前台执行完全是jvm的效率，这两个效率都明显有保证
: 有的是办法做优化，jvm的优化是几十年的积累
: 估计楼主用的就是web，上tomcat
: 效率明显高过各种乱七八糟的web server
|
d***q
发帖数: 1119 | 20 python （估计，ruby, 或者其他动态语言也可能适用）
的 function call是个很重型的动作，vm又比较差劲，没法很好地Inline 来避免开销，
+ 类型的检查，导致如果发生大量函数调用时就会很慢。于是不少人搞出了一些
例如 cython,swig之类的东西，本质就是要绕过pvm， 降低函数调用的损失，来达到加
速的效果。
GIL 这个可以用多进程来部分解决这个问题，也有不少应用的例子，例如web的
前端用nginx, 后端起若干个进程，或者用zeromq之类来进行进程间的通信，都有真实
的例子，所以gil 现在反而不是太敏感。
【在 c****e 的大作中提到】
: 有个global lock，没办法。
|
|
|
w****k
发帖数: 6244 | 21 所以你建议换更慢的jython？
【在 z*******3 的大作中提到】
: 都不看原帖？
: 楼主在抱怨cpython慢啊
|
z*******3
发帖数: 13709 | 22 我对jvm的效率更有信心
优化起来办法也多
【在 w****k 的大作中提到】
: 所以你建议换更慢的jython？
|
z*******3
发帖数: 13709 | 23 宾狗
我也觉得楼主当初坚决上jvm
不听别人乱忽悠的话，可能现在就开始爽了
而不用像现在这样，不仅解决方法没几个
处处受限，还要被嘲笑人笨怪刀钝
出来混，总要还的
当初投机取巧，现在还回去
另外，如果计算的公式很复杂的话
用scala可能会更好，会直观一点
oop尤其是java数学公式的书写不直观是软肋
如果是简单的数学，用apache common math包就好了
【在 d***q 的大作中提到】
: 这个效率问题还是要看具体的例子。
: 如果仅仅是单纯 计算一下 然后返回。那么使用jni也没啥问题。但是如果有些场景需
: 要做大量的交互， 不停在边界上进出，这时jvm没法很好优化， 效率反而还不如直接
: 用java。
: 我几年前搞过一些gis的东西。之前有一套系统的计算用c++写，然后用jni来调用，问
: 题特别多。最后全部用java写，现在用了几年也没啥问题，之前还担心性能会降低，后
: 来发现还好了，没有想象中的慢。
: 现在对于这种场景，我的做法是把这些 要计算的封装一下，做个服务，用个rpc之类的
: call一下就好。不通过jni来调用。容易调试，反正计算部分的耗时要远大于call的开
: 销。用rpc也无所谓。
|
w*s
发帖数: 7227 | 24 can you precompile phthon script into exe ?
【在 w***g 的大作中提到】
: 搞得我整天都在等结果上bbs. 本来应该是C++写的核心计算程序是瓶颈, 结果外围的
: python程序比核心程序还慢. 真是郁闷死我了. 貌似还不能parallelize, 怎么会有这
: 种弱智的解释器!
|
n******t
发帖数: 4406 | 25 crazy.......
坑爹的建议可能也就这个level了吧。
【在 z*******3 的大作中提到】
: 楼主，给你一个小建议
: 有个东西叫jyphon
|
z*******3
发帖数: 13709 | 26 well
既然坑已经挖出来了
要么越挖越深，比如jyphon
或者坐以待毙，逆来顺受，比如继续用下去
要么干脆跳出来，重新挖，比如代码全部重写换java
实话实说，现实生活中，大多数老板会选择前两个
而对于有经验的人来说，会很清楚滴知道，最后一个其实是最好的选择
要不你给说说怎么办？
【在 n******t 的大作中提到】
: crazy.......
: 坑爹的建议可能也就这个level了吧。
|
w*x
发帖数: 518 | 27 小白弱问 为啥不用Cython?
【在 z*******3 的大作中提到】
: 宾狗
: 我也觉得楼主当初坚决上jvm
: 不听别人乱忽悠的话，可能现在就开始爽了
: 而不用像现在这样，不仅解决方法没几个
: 处处受限，还要被嘲笑人笨怪刀钝
: 出来混，总要还的
: 当初投机取巧，现在还回去
: 另外，如果计算的公式很复杂的话
: 用scala可能会更好，会直观一点
: oop尤其是java数学公式的书写不直观是软肋
|
g********n
发帖数: 296 | 28 If you are using Linux, in your C code, use set_affinity system call to
overwrite Python's scheduler. It might work.
Assume you have 8 cores, leave the first for Python and OS, use the reset 7
cored for your C task. |
