z****e
发帖数: 54598 | 1 虽然说没看到过你偷偷删贴的行径
但是还是先留个存档
发信人: TeacherWei (TW), 信区: Programming
标 题: Re: 提上来：Goodbug有资格谈I/O么？
发信站: BBS 未名空间站 (Sun Jan 12 22:50:53 2014, 美东)
其实一般写写程序，尤其是单线程不特殊优化，Java的内存管理效率还是蛮高的。
那个GC是stop the world GC，对多线程的杀伤力还是巨大的。 |
|
|
c******o
发帖数: 1277 | 3 用scala 有一段了，最近又自学了clojure和自己练习了一下 akka/spark
说说新的感想。
我们的新后端是Play/Scala的，本来想加akka,但是事实上最后用的很少。
是不是akka不好，没啥用呢？我以前也有这个疑问，现在觉得理解错了。
Akka是很好，绝对是killer app. 以前我觉得没用，没用到，是理解错了。
第一，我其实是在间接的用akka, scala 2.10.x的future就是以前akka的future,
scala的future已经deprecated, play本身就是build在akka上的，spark也是。
第二，其实我们确实用不到actor,actor最大得用途是distributed fault tolerance
system, 一般的async future/dataflow就足够足够了。要是需要shared data,
transaction, agent就够了。虽然actor以上两个都可以用，但是也不一定要用。
第三，其实akka很多内容，actor只是一个最general的。
有future(其实内部都是callback),... 阅读全帖 |
|
z****e
发帖数: 54598 | 4 从结果各种数据分析
vert.x的效果是非常惊人
反应时间在1000个hits时候
居然达到了0.04s，对比nodejs的1.45s
那是快得不知道要到哪里去了
而且这还是一个js的表达
如果是java写的话，还能再快20％以上
而且有一个worker thread
做单线程/伪多线程的对于这种机制应该最清楚
有些时候，有些任务，设计之初就强行要求你做同步
这个时候如果要异步，那就需要自己去折腾
比如db，比如hadoop，都是blocked，这个时候如果没有worker thread
你需要自己去倒腾额外一层做封装，这就麻烦了
直接扔给worker thread就好了，哪里需要自己折腾
vert.x最大的问题就是内存消耗
那这个简直不是问题，对于server来说
破内存，不值几个钱的 |
|
z*******3
发帖数: 13709 | 5 r是单线程的
不止c的接口，当然也有java的接口
但是这样做只能直接call，跑还是跑在慢腾腾的r engine上
相比之下，renjin直接挂到jvm上去跑
用scala来优化loop这些
这个比较抽象
jvm就是一个平台，这个平台上只要是byte code就能跑
jvm不管是不是java写的，你用你自己的语言搞一个都行
只要最后给jvm一个byte code，它就能跑
而renjin是一个r在jvm上的引擎
简单说就是把r写的脚本，编译成byte code，然后交给jvm去执行
所以等于是绕开了java这个东西，这样做的好处就是
直接在jvm上执行，其效率会高于r自身的引擎
这里可以有多线程等操作，而r本身引擎没有这些 |
|
z*******3
发帖数: 13709 | 6 就是统计的去用r，it的用java那些
现在要用r效率低是一回事，r引擎还是单线程的，fp可以通过多线程优化的
主要还是接口很烦，所以给了sas以生存的空间
但是renjin出来以后，这个局面会改观
r有广泛的群众基础，这个很重要 |
|
z*******3
发帖数: 13709 | 7 modeling跟具体的impl没有什么关系
做出了model，领导们想看，随时点个按钮就能看到
这个就需要折腾jvm去了，另外就是r是fp和单线程的东东
很多东东理论上是可以通过多线程来优化效率的
我买这张账，但是到底行不行，试了才知道
至少我觉得理论上没啥问题，等1.0出来之后我试试
integrated |
|
T********i
发帖数: 2416 | 8 说实话，没真的做过。interlocked会不会更慢真的不知道。
不过，99%的可能是更快。因为Sandy Bridge只锁cache line。
这就是为啥我强调1条线路20个区段，就是说用单线程每秒500万次也不会有任何压力。
我不会留下1%的不确定性的。
还有99%的可能性是，多线程interlocked，比500万次快好几倍。这都是设计余量。 |
|
g*****g
发帖数: 34805 | 9 我不相信单线程能搞定，多线程就要锁一样搞不定。就像qxc说的，如果能做出来，
至少也秒Oracle一个数量级，价值至少数以亿计，太监光扯嘴皮子没用。 |
|
L*****e
发帖数: 8347 | 10 如果老魏需要解决理论上所有需要解决的情况，那么古德八可以一千个车次，每个联票
请求的起点（甚至停靠站）都是另一个联票请求的中转，那么所有的联票请求得形成一
个巨大的耦合圈，然后500W个都是这样的请求话，多线程P的作用都没有，不断的
rollback反而要花比单线程更多的时间。。。 |
|
b*******s
发帖数: 5216 | 11 10台机器跑单线程，我看不出相对一台机器10个核跑10个线程的优越性 |
|
T********i
发帖数: 2416 | 12 你他妈的连线程通信都不会么？
单线程抢票，我还有10几个core不能处理网络编码解码么？
这点基本常识都没有？恭喜你再创新低。 |
|
T********i
发帖数: 2416 | 13 单线程做到50M比多核多线程简单可靠，而且性能都不差。 |
|
T********i
发帖数: 2416 | 14 其实你再想想？
别说现在抢票用单线程，就算是多线程，也能让它想同步就同步，想异步就异步。
代价就是那么几个微秒毫秒而已。
你真以为我们做高频的萝卜快了不洗泥？这个系统的可控性也是强实时的。 |
|
c****3
发帖数: 10787 | 15 虽然是单线程，后台改计数器的时候，前台没法同时改计数器。但是统计数据库区间剩
票数的程序，好像也必须在这个线程运行，才能不出现超卖。还是有什么其他方法？
因为区间剩余总票数很容易变化，比如有人退票。数据库和计数器两者必须保持一致。 |
|
z*******3
发帖数: 13709 | 16 单线程还需要2个cpu么？
如果不需要，那就是一个cpu一台机器，sharding
如果需要，那就是伪多线程，async
都有人在做，都看着这家伙怎么表演了
有本事别过来 |
|
c****3
发帖数: 10787 | 17 架构没觉得有啥问题，因为是单线程处理请求，把数据库锁，简化成计数器没有大问题
。如果多线程，就比较困难了。
剩下的就是堆硬件了，现在硬件处理能力确实厉害。既然有40G，甚至100G以太网卡卖
，这也不是什么大问题。
是有点难维护，数据库各个区间的剩余票数，要和计数器对应上，总是保持一致，这上
面要化不少力气。但应该是能工作的。 |
|
g*****g
发帖数: 34805 | 18 宇宙第一的算法，死撑三个月，在最基本的计数器上就换了两次设计，一次多线程改单
线程，一次号称不用找座位再加上。每次都要打脸打到混不下去了才承认。我以为宇宙
第一的东西是不用修改的。修改了到底哪个是宇宙第一呢？
换个设计，再讨论三个月，再换个设计。我老可浪费不起这个时间。
至少我老做的设计，到现在一个补丁都没有，这就是水平的差距。三个月足够我一个人
做一个12306全套的prototype了。
一个计数器，三个月都没搞定，还做啥12306呀，洗洗睡吧。 |
|
p*****2
发帖数: 21240 | 19
cache
看需求。如果我没记错的话，mongodb可以达到10K/sec, 不过mongo是多线程。而Redis
一个instance的单线程就比mongo要更快。如果上多进程的话，差距就出来了。
mongo比redis易用多了，所以如果性能要求不高的话，应该没啥问题。要求高性能就上
redis吧。 |
|
q*c
发帖数: 9453 | 20 单线程就不锁，多线程是的锁。不过基本都不冲突，所以也应该没啥。 |
|
T********i
发帖数: 2416 | 21 来自主题: Programming版 - 简单就是美 网络后发先至和有票买不到是两个根本不同的概念。
你看明白我的设计了么？分票是多线程，但是只有请求不书记以来的情况下。有数据以
来还要单线程。
你当然能保证完全跟着request包到达的顺序处理。你要是不知道如何做，那是你的问
题。
有票买不到才是大问题。你说过，有票要保证100%出票。自己说的，还以此来要求别人
。怎么到自己就不认账了？
最后一句涉嫌PA。警告你一次了。下次再PA就举报你。 |
|
p*****2
发帖数: 21240 | 22
本来不就说了non－blocking了吗？无论是单线程，还是多线程，想高并发都不能阻塞
。 |
|
n****1
发帖数: 1136 | 23 用python要尽量使用yield, 单线程能搞定的就别多线程/进程. |
|
G**Y
发帖数: 33224 | 24 这是gpu computing吗？那就折腾了，估计要tune你的code吧。
据说tune的很好的gpu code，也就提高4-5倍。
毕竟其几百个线程，overhead太多。
我不理解的是为啥openblas即使单线程，似乎overhead也很大。不过前面说了，在
virtualbox上跑，可能有很多别的问题。看来需要新硬件。 |
|
h*******u
发帖数: 15326 | 25 我开了200个线程，按理说应该自动offload到mic上，但是计算速度没有任何变化，还
不如单线程openblas快。
用xeon phi 还需要对原程序修改吗？ |
|
p*****2
发帖数: 21240 | 26 多线程就会有race condition
单线程不用担心 |
|
c******t
发帖数: 133 | 27 刚接触c++ multithreading，自己用一个小例子想看看多线程能增加多少速度，由于电
脑是双核的，就想用两个threads把一个int array前后两部分分别排序，但不知道为什
么这个程序跟单线程排完前一半再排后一半的效率差不多，有没有同学指教一下，谢谢
了，代码如下。
#include
#include
#include
#include
using namespace std;
const int SIZE = 20000;
const int NO_OF_THREADS = 2;
void bubbleSort(int A[], int size, int);
void singleThread(int A[], int size)
{
clock_t t1, t2;
t1 = clock();
for(int i = 0; i < NO_OF_THREADS; i++)
bubbleSort(A+i*(SIZE/NO_OF_THREADS), SIZE/NO_... 阅读全帖 |
|
z****e
发帖数: 54598 | 28 但是客户端尤其是app大部分都是单线程或者是双线程（android）
为主，需要用到singleton的地方不多呀，直接pool objects就好了 |
|
S*A
发帖数: 7142 | 29 real 19m21.306s
user 19m19.382s
sys 0m1.902s
这个是单线程做4000x100000， 每行30 random ASCII string。
配额合前面的 python 生成的数据文件使用。
这个 diff 的强度比较高了，我的破笔记本是老版MBA。
才19 分钟。如果加多线程，快点的 CPU， 例如 4 thread 个
就可以 5 分钟左右了。
我想要拼过这个速度恐怕很难了。
BTW, lcs code 是网上的改的。
发包子吧。
/* Dynamic Programming implementation of LCS problem */
#include
#include
#include
#include
#include
#include
/* Utility function to get max of 2 integers */
static inline int max(... 阅读全帖 |
|
l**********n
发帖数: 8443 | 30 my question is
单线程快，还是多线程快。 |
|
l**********n
发帖数: 8443 | 31 js就一单线程。java的多线程更难掌握。js比ruby也简单。ruby的proc比js的function
更难理解。js比python也简单，python的decorator不是很直接。 |
|
z****e
发帖数: 54598 | 32 用多线程搞异步，就是用ejb方式折腾worker都可以，完全可以对每一个worker实例单
独启
动一个thread, 但是如果是process, 就没戏了，很容易就出问题了 |
|
z****e
发帖数: 54598 | 33 用多线程搞异步，就是用ejb方式折腾worker都可以，完全可以对每一个worker实例单
独启
动一个thread, 但是如果是process, 就没戏了，很容易就出问题了 |
|
z****e
发帖数: 54598 | 34 process那么大一个overhead横在那边，这个是js的原罪
js从本质上就不支持多线程，你是无法改变这一点的
要改变仅有通过其他语言的帮忙才可以，但是一旦引入其他语言
你这个事情就会变得复杂起来，就你这个例子里面的fibjs
在win上好像要安装vs.net 2011啊，而且本质上并没有解决单线程带来的问题
你一旦到了multiple core的环境中，你就需要启动多个processes
这个玩意你多起几个，你的server就开始抱怨了
而且fibjs跟node本身的eco也有大量的不兼容，等于是另外一个东西
就是无法兼容所有的npm，那你用这个真的划算？
另外，用promise的做法本质就是一个lib
跟其他语言没有任何区别，而且要命的是
程序猿可以不用这个lib呀，没有任何强制手段不让他们制造callback hell
最后结果就是他们拼命地造出各种hell来，然后你去给他们擦屁股
scope对我来说不是问题，哪怕我用的是js
对于node来说才是
scope
快。 |
|
z****e
发帖数: 54598 | 35 这么简单一个东西还需要交给npm去做
套上了这一层之后，你的代码还很直观吗？
另外，这个mod还是无法让你自由启动线程
棋牌乐需要对每一局额外启动一个thread
你要想办法黑进npm，明白webworker是怎么搞的
然后再想办法在他们的基础之上搞出新东西来
你看连启动一个最简单的thread都要折腾，这个东西还简单吗？
换个说法，一旦介入这个npm你觉得你还在用单线程吗？
这个时候immutable，lock，synchronized什么就都来了，在等着你呢
你用js倒腾这些，文档可不好找哦 |
|
z****e
发帖数: 54598 | 36 no
大多数脚本都支持object
而且大多数脚本都是object和func的拼凑
java则偏向比较纯粹的oo
而lisp则偏向比较纯粹的func
脚本则多数介于两者之间
如果你非要认为lisp也是脚本的话
那有一点很明显不同
就是脚本一般不支持immutable
几乎所有的脚本使用的东东，都是var，而非val
在对付多线程上
java等纯粹oop会选择lock，或者说synchronised关键字
脚本选择了单线程，which is bad，very bad
fp则多数选择了immutable
当然互相之间未必冲突，但是可以明显从一些很简单的例子中看到不同 |
|
z****e
发帖数: 54598 | 37 其它语言嘛，尤其是脚本，基本上不适合用来搞app
c类语言太底层，写起来太慢，而且ide支持也弱
java能搞定android和server，能够复用代码
但是搞不定ios，swift能搞定ios，但是一旦涉及网络啥的
就显得蛋疼，更谈不上server side了，但是如果swift能搞定android的话
那就太好了，不过还是搞不定server，其实本质上就是llvm和jvm两个虚拟机
用这个还是用那个的区别，swift和java其实差别很小
apple和google好好商量一下，这两个自己再搞一个语言出来
能够兼容cloud，android和ios平台，这事基本就定了
app主要考虑单线程，gui，java最弱的就是gui，android和java差异就是gui
server主要考虑多线程，网络，跨平台，数据存储，java这几点做得尤其powerful
其实google和apple只要联手，两个凑一起，搞一个新兴语言出来
一点问题都没有，根本不是啥难事，这些features都写在这里了
就是一层窗户纸，一捅就破，话说写swift真的是好开心啊
一天不写，我就浑身难受 |
|
h*i
发帖数: 3446 | 38 这只能说明goroutine 适用范围小，要求driver必须是nonblocking的,我问的是，what
if driver是blocking的？你可能回答，go的driver都是基于fiber的。我说，这不就
是limitation么？
core.async不管下面是什么，多线程也好(Java),单线程也好（JavaScript),甚至fiber
也好，对用户来说是透明的，我不需要关心，我一样用，得到一样的async的功能。这
样的好处是巨大的，比如在浏览器端，core.async让clojurescript完全脱离了
callback hell。
至于下面的机制不同，context switch效率不同，这不是废话么，谁都知道。一般来说
，用户更关心能不能的问题，＂core.async不管什么环境都能，goroutine 只能在go环
境里能，所以core.async更好＂。
无论如何，"core.async is just a toy" is nonsense.
★ 发自iPhone App: ChineseWeb 8.6 |
|
l**********n
发帖数: 8443 | 39 单线程怎么和多线程比？你的思维真有趣。你肯定属于高智商人群。 |
|
c*********e
发帖数: 16335 | 40 多线程相互无关,那还不如单线程async来得快。 |
|
z****e
发帖数: 54598 | 41 我用vertx,目前x3除了语言还限于那四个以外，没遇到其它问题，各种协议支持得很好
，play主要搞http，没啥意思，挺浪费的，node是单线程，app建模不合适，go没有线
程，虽然底层也是，但是不能自己操作，也不合适，app并发经常需要用到线程
：虽然这是不同的东西。play 2 对web应用支持多，但很多东西mobile用不上。vert.x
更底层对web支持少（和akka比，但akka比较复杂） |
|
z****e
发帖数: 54598 | 42
疯了，楼主现在单线程程序都能跑3天，你凭啥认为会blocked？
要真blocked的话，这3天都怎么过来的？
如果3天不会blocked的话，爆出多个threads就会blocked了？
这好像也不对啊，目测多线程对于这种容错性更强啊，相对于一个thread而言
真要搞异步的话，vert.x也是天然异步处理，还q什么哦 |
|
t**r
发帖数: 3428 | 43 我没问node 只会想知道春天的线程模型 也是单线程还是不是？ |
|
z****e
发帖数: 54598 | 44 都可以用，vert.x只要你能启动spring，一样可以用spring注入，单线程也可以di，
spring与线程无关，只是多数时候spring管理的bean是singleton，如果有共享的field
或者叫变量，并发修改会出问题，这个做一个例子就懂了
：That is from software developer logical view point.
：From OS view point, The code you written are running in thread pool, right? |
|
T********i
发帖数: 2416 | 45 C/C++做I/O最优化的方案是每个CPU socket一个网卡(每个Socket都有独立的IOH)。
同时每个socket用一个core单线程处理I/O。
任何违背这个原则的方案都不是最优的，也就是说你增加网卡数量或者线程数量说明你
不合格。
我估计我的建议用处不大。我只能帮到这里了。 |
|
b***i
发帖数: 3043 | 46 我倾向与线程blocking,你倾向于单线程non blocking，那就不用异步了？
看起来，这个和我对待串口一样，用查询方案？具体咋写？我还是要用asio的，不想用
裸的C，asio不是跨平台嘛 |
|
b*******g
发帖数: 603 | 47 真有错的话我可以认。请你指出我说得哪里错了。
1. 太监写了个太监技术器，都不保证票能卖出去，被打脸。多线程实在搞不定，退回
单线程，死撑一定能行。qxc拿出机器，大家都等着实测，立马尿遁一年。
2. 出来之后叫板Nest只是它平台上一个应用，还不是最好的。现有的都是屎，被我发
现应用没人用，又尿遁一年。
3. 又出来后装成功企业家，被我发现应用还是没人用，平台然并卵。对XDA号称hobby
project。没funding。恼羞成怒撒泼中。跟网友征集黑材料，号称要报告HR，一会擦
Glock，一会说弄死我也是我应得的。
但除了在本版撒泼，没有任何实际行动。还不如10几年前让BBS血流成河，至少给MIT网
管打了小报告，look不得不关了一些盗版版面。
子" |
|
t**********1
发帖数: 550 | 48 别不要脸，我问过你很多次了，你号称计数器不支持transaction，造谣上百次，这回
换个说法继续造谣。
1. 计数器震荡是个小bug。当时马上就fix了。多线程fix以后遇到race就自动重试一次
而已。本来就是微秒级别的延迟，甚至纳秒。10核race相当罕见。因为马上无效请求就
会被cache机屏蔽。你看不懂是你自己的问题。单线程也没有问题。都是每秒5M以上票
数的。
现在我问你，你要是能证明我没有fix，那我公开道歉，再也不来。你要是不能证明，
那你自己自杀ID以后滚出去好不好？ Come on. Be a man!
你证明不了我没有fix。还继续散步谣言，污言秽语，我当然要搞你。反正我手头信息
足够。LOL
2. 3. 智能控温是我平台的应用。我和谁都是这么说的。你爱懂不懂。爱咋说咋说。我
不在乎。对我的business毫无影响。
今天打你，是因为上百次造谣计数器不支持transaction，连续两年持续造谣。我手头
信息足够。整你绰绰有余。反正我时间也足够。呵呵。
hobby |
|
t**********1
发帖数: 550 | 49 你别不要脸啊。多线程你看不懂。单线程那个，一个个顺序处理请求，要是不支持
transaction的话，是不是你智商有问题？
再问你一次，我的计数器支持不支持transaction？
还有，你的嘴怎么这么脏？厕所么？你看看你这些帖子，哪个不是口吐大粪？ |
|
b*******g
发帖数: 603 | 50 你的计数器是单线程的，所以不用锁，连 lockfree都不用。现在查询要改多线程吗？
LOL. 你丫真是最低的
常识都没有。 |
|
