l*********s
发帖数: 5409 | |
d****n
发帖数: 1637 | |
l*********s
发帖数: 5409 | |
w***g
发帖数: 5958 | 4 用plan9的库，里面有channel，但是是C的。
C++连个通用的producer/consumer库都没有。
boost里和网上能找到用户态的线程库，但一般都不支持multi-core，
对操作系统的阻塞也无法感知（go因为包了一层，所以能感知阻塞操作)，
open source的用户态light weighted线程，还能支持multi-core的，还要
支持job stealing啥的，这种牛B的库没有。
所以虽然go是C/C++写的，就线程高并发来说C/C++不如go。
但是，线程高并发只是一种写法。C/C++搞个几百个线程还是没问题的。
再要提高，就只能用event了。但是话说C/C++也没有好的event库能
支持multi-core, job stealing啥的也没有。event写东西又难debug。
总之C/C++要写超高吞吐量的，一般只能是牛B程序员手写。
就个人来说，我并不觉得C++需要go那种程度的线程高并发。
考虑到I/O阻塞啥的，每个core上放几十个线程也就够了，加起来也就是
几百个线程。线程数再多，overhead比例就升高了，反而不助于提高
吞吐量。如若不信，可以看下web server benchmark，吞吐量最牛B
的还是C/C++。
【在 l*********s 的大作中提到】
: rt
|
w***g
发帖数: 5958 | 5 那个golib有点意思。不知道操统的阻塞操作怎么处理。
就go而言，runtime应该能知道哪些操作会阻塞，然后可以自动切换goroutine。
但是如果用C/C++，直接调用操统接口，比如select，
golib怎么知道？
【在 d****n 的大作中提到】
: c++
: http://www.webr2.com/c-libraries-that-implement-go-goroutines-o
: C
: https://github.com/stefantalpalaru/golib (but I dont see it is ready for
: production, be caution bird)
: and why
: https://groups.google.com/forum/#!topic/golang-nuts/HroRSomDLlo
|
s*******m
发帖数: 58 | |
p***o
发帖数: 1252 | |
l*********s
发帖数: 5409 | 8 desktop不需要，windows服务器又没人鸟。
【在 p***o 的大作中提到】
: Windows的fiber也出来10多年了，有人用吗？
|
d****n
发帖数: 1637 | 9 我也不知到， 得花功夫去读人家code啊
【在 w***g 的大作中提到】
: 那个golib有点意思。不知道操统的阻塞操作怎么处理。
: 就go而言，runtime应该能知道哪些操作会阻塞，然后可以自动切换goroutine。
: 但是如果用C/C++，直接调用操统接口，比如select，
: golib怎么知道？
|
l*********s
发帖数: 5409 | 10 惨绝人寰！
【在 w***g 的大作中提到】
: 用plan9的库，里面有channel，但是是C的。
: C++连个通用的producer/consumer库都没有。
: boost里和网上能找到用户态的线程库，但一般都不支持multi-core，
: 对操作系统的阻塞也无法感知（go因为包了一层，所以能感知阻塞操作)，
: open source的用户态light weighted线程，还能支持multi-core的，还要
: 支持job stealing啥的，这种牛B的库没有。
: 所以虽然go是C/C++写的，就线程高并发来说C/C++不如go。
: 但是，线程高并发只是一种写法。C/C++搞个几百个线程还是没问题的。
: 再要提高，就只能用event了。但是话说C/C++也没有好的event库能
: 支持multi-core, job stealing啥的也没有。event写东西又难debug。
|
|
|
p***o
发帖数: 1252 | 11 老老实实用TBB把。
【在 l*********s 的大作中提到】
: 惨绝人寰！
|
p*u
发帖数: 2454 | 12
check out HPX and Qt
【在 l*********s 的大作中提到】
: 惨绝人寰！
|
l*********s
发帖数: 5409 | 13 Qt肯定没有。
【在 p*u 的大作中提到】
:
: check out HPX and Qt
|
w***g
发帖数: 5958 | 14 我猜是所有的I/O都不能用系统调用，而是通过libgo走，
然后libgo给在中间掐断。
【在 d****n 的大作中提到】
: 我也不知到， 得花功夫去读人家code啊
|
T********i
发帖数: 2416 | 15 C/C++做I/O最优化的方案是每个CPU socket一个网卡(每个Socket都有独立的IOH)。
同时每个socket用一个core单线程处理I/O。
任何违背这个原则的方案都不是最优的，也就是说你增加网卡数量或者线程数量说明你
不合格。
我估计我的建议用处不大。我只能帮到这里了。 |
d****i
发帖数: 4809 | 16 不会吧，除了标准的多线程pthread以外，不是有C的库libevent, libev, libuv这样的
event库吗？都是user space的lib，然后Node, Java的Future, Python的Twisted, PHP
的ReactPHP等都是基于这几个lib的吧。Go的channel的实现没有研究过，用的也是
pthread上面包了一层吗？还是libevent上面包了一层？
【在 w***g 的大作中提到】
: 用plan9的库，里面有channel，但是是C的。
: C++连个通用的producer/consumer库都没有。
: boost里和网上能找到用户态的线程库，但一般都不支持multi-core，
: 对操作系统的阻塞也无法感知（go因为包了一层，所以能感知阻塞操作)，
: open source的用户态light weighted线程，还能支持multi-core的，还要
: 支持job stealing啥的，这种牛B的库没有。
: 所以虽然go是C/C++写的，就线程高并发来说C/C++不如go。
: 但是，线程高并发只是一种写法。C/C++搞个几百个线程还是没问题的。
: 再要提高，就只能用event了。但是话说C/C++也没有好的event库能
: 支持multi-core, job stealing啥的也没有。event写东西又难debug。
|
d****n
发帖数: 1637 | 17 golang 根本没有libxxx
PHP
【在 d****i 的大作中提到】
: 不会吧，除了标准的多线程pthread以外，不是有C的库libevent, libev, libuv这样的
: event库吗？都是user space的lib，然后Node, Java的Future, Python的Twisted, PHP
: 的ReactPHP等都是基于这几个lib的吧。Go的channel的实现没有研究过，用的也是
: pthread上面包了一层吗？还是libevent上面包了一层？
|
l*********s
发帖数: 5409 | 18 知道原则就好很多了，谢谢
【在 T********i 的大作中提到】
: C/C++做I/O最优化的方案是每个CPU socket一个网卡(每个Socket都有独立的IOH)。
: 同时每个socket用一个core单线程处理I/O。
: 任何违背这个原则的方案都不是最优的，也就是说你增加网卡数量或者线程数量说明你
: 不合格。
: 我估计我的建议用处不大。我只能帮到这里了。
|
w***g
发帖数: 5958 | 19 pthread是包在OS线程外的。light-weighted thread需要用到用户态线程。
微软的fiber是用户态的，但是因为是windows世界的，不怎么招人待见。
在多核上做用户态线程是一件非常非常恶心的事情，GO最主要的贡献其实
就是把这件事做成了。主要的恶心之处就是怎么处理job stealing:一个
操统线程上面的任务都跑完了，就需要去别的操统线程那儿把活弄过来。
这就涉及到各种同步，各种locking。Locking多了，性能就下来了。
这种事情以前应该不少公司内部都有人做过，能做这个的人一般也都
屌得不得了。其实稍微对比一下就能知道multi-core有多难做：
node.js不支持multi-core，python折腾这么多年也还是个残疾。
如果你想更多地了解一下，可以从man makecontext
看起。每个用户态线程其实是一个context。然后底下每个操统线程负责
管一堆context。context切换主要靠cooperative scheduling，而不是操统
用的preemptive scheduling。也就是说一个context运行到某一步自己主动
把执行权让出来。Unix世界的一般没见过cooperative scheduling.
Windows 3.x是cooperative scheduling，所以线程跑一会就得调用yield
让出执行权。因为不可能要求程序员写几行程序就插入一个yield，所以
其实Windows很多UI和I/O的API都内嵌了yield。那些差的程序员不知道
这回事，有时候进入一个纯计算的循环没有在中间插入yield，就会导致
系统挂起。Unix世界从一开始就是pre-emptive的，操统API没有内嵌yield
这回事。手写程序隔几行插入yield也不可行。这就是unix世界的C/C++做
用户态线程几乎不肯能的原因。这也是为啥rob pike非要搞一个新的语言的
原因：在操统API外包一层，并且嵌入yield（还有就是GC)。GO在语言层面
上其实没有任何创新，甚至比好多现有的语言都要低级。如果从出发点来
看，GO的目的其实已经达到了。相比而言，Windows有在API
里面做yield的传统，这也是为什么这么容易搞出来fiber的原因。
C++11的thread API里有个莫名其妙的this_thread::yield，其实就是为了
给non-preemptive的runtime留下余地。理论上说，如果禁止调用操统API，
全都用C++的I/O库，C++是有可能做出来用户态线程的runtime的。有的嵌入
式系统本就没有preemptive scheduling, yield就成了必须得了。
PHP
【在 d****i 的大作中提到】
: 不会吧，除了标准的多线程pthread以外，不是有C的库libevent, libev, libuv这样的
: event库吗？都是user space的lib，然后Node, Java的Future, Python的Twisted, PHP
: 的ReactPHP等都是基于这几个lib的吧。Go的channel的实现没有研究过，用的也是
: pthread上面包了一层吗？还是libevent上面包了一层？
|
d****i
发帖数: 4809 | 20 大牛高，赞详解。我做了那么多年，不管是当年的Solaris, 还是现在的Linux，还是那
些众多的RTOS, 清一色的preemptive。pthread确切的说应该是user space created的
thread，但是under the hood由kernel thread来support的吧，
【在 w***g 的大作中提到】
: pthread是包在OS线程外的。light-weighted thread需要用到用户态线程。
: 微软的fiber是用户态的，但是因为是windows世界的，不怎么招人待见。
: 在多核上做用户态线程是一件非常非常恶心的事情，GO最主要的贡献其实
: 就是把这件事做成了。主要的恶心之处就是怎么处理job stealing:一个
: 操统线程上面的任务都跑完了，就需要去别的操统线程那儿把活弄过来。
: 这就涉及到各种同步，各种locking。Locking多了，性能就下来了。
: 这种事情以前应该不少公司内部都有人做过，能做这个的人一般也都
: 屌得不得了。其实稍微对比一下就能知道multi-core有多难做：
: node.js不支持multi-core，python折腾这么多年也还是个残疾。
: 如果你想更多地了解一下，可以从man makecontext
|
|
|
d****i
发帖数: 4809 | 21 发现一片很好的文章，解释了thread, coroutine, fiber之间的联系和区别，结论是
Use thread for sure if you can, 哈哈。
http://stackoverflow.com/questions/16765736/why-doesnt-linux-us
Coroutines, fibers and their ilk are thread-like execution contexts managed
by programming language runtimes or libraries, rather than by the operating
system, which regards them to be in one thread. They are of limited use;
nobody in their right mind uses such hacks when real threads are available.
【在 w***g 的大作中提到】
: pthread是包在OS线程外的。light-weighted thread需要用到用户态线程。
: 微软的fiber是用户态的，但是因为是windows世界的，不怎么招人待见。
: 在多核上做用户态线程是一件非常非常恶心的事情，GO最主要的贡献其实
: 就是把这件事做成了。主要的恶心之处就是怎么处理job stealing:一个
: 操统线程上面的任务都跑完了，就需要去别的操统线程那儿把活弄过来。
: 这就涉及到各种同步，各种locking。Locking多了，性能就下来了。
: 这种事情以前应该不少公司内部都有人做过，能做这个的人一般也都
: 屌得不得了。其实稍微对比一下就能知道multi-core有多难做：
: node.js不支持multi-core，python折腾这么多年也还是个残疾。
: 如果你想更多地了解一下，可以从man makecontext
|
d****i
发帖数: 4809 | 22 所以说rob pike搞了半天coroutine, 都是闲的蛋疼扯的，最后性能还是比不过thread
。所以plan 9也就作为贝尔实验室的试验而早就进了坟墓，不像同是出自贝尔实验室大
师的Unix得以千秋万代伟光正。
managed
operating
.
【在 d****i 的大作中提到】
: 发现一片很好的文章，解释了thread, coroutine, fiber之间的联系和区别，结论是
: Use thread for sure if you can, 哈哈。
: http://stackoverflow.com/questions/16765736/why-doesnt-linux-us
: Coroutines, fibers and their ilk are thread-like execution contexts managed
: by programming language runtimes or libraries, rather than by the operating
: system, which regards them to be in one thread. They are of limited use;
: nobody in their right mind uses such hacks when real threads are available.
|
w***g
发帖数: 5958 | 23 coroutine主要是有语法上的好处，跟性能没关系。比如下面这个语法就很漂亮。
def fab(max):
n, a, b = 0, 0, 1
while n < max:
yield b # 不是线程调度那个yield
a, b = b, a + b
n = n + 1
for n in fab(5):
print n
C/C++要实现coroutine也是用类似context的方法，以至于有一些人就直接把
coroutine和context等同了，光从性能上来考虑问题，忘了语法上的好处。
再说C/C++没有语法糖，就是用coroutine也写不出漂亮的程序。
managed
operating
.
【在 d****i 的大作中提到】
: 发现一片很好的文章，解释了thread, coroutine, fiber之间的联系和区别，结论是
: Use thread for sure if you can, 哈哈。
: http://stackoverflow.com/questions/16765736/why-doesnt-linux-us
: Coroutines, fibers and their ilk are thread-like execution contexts managed
: by programming language runtimes or libraries, rather than by the operating
: system, which regards them to be in one thread. They are of limited use;
: nobody in their right mind uses such hacks when real threads are available.
|
l*********s
发帖数: 5409 | 24 佩服的5体投地！
【在 w***g 的大作中提到】
: pthread是包在OS线程外的。light-weighted thread需要用到用户态线程。
: 微软的fiber是用户态的，但是因为是windows世界的，不怎么招人待见。
: 在多核上做用户态线程是一件非常非常恶心的事情，GO最主要的贡献其实
: 就是把这件事做成了。主要的恶心之处就是怎么处理job stealing:一个
: 操统线程上面的任务都跑完了，就需要去别的操统线程那儿把活弄过来。
: 这就涉及到各种同步，各种locking。Locking多了，性能就下来了。
: 这种事情以前应该不少公司内部都有人做过，能做这个的人一般也都
: 屌得不得了。其实稍微对比一下就能知道multi-core有多难做：
: node.js不支持multi-core，python折腾这么多年也还是个残疾。
: 如果你想更多地了解一下，可以从man makecontext
|
d****i
发帖数: 4809 | 25 不要虚假的fancy华而不实和语法糖，要实用要简单要易懂要性能，这是Unix的宗旨和
哲学。
【在 w***g 的大作中提到】
: coroutine主要是有语法上的好处，跟性能没关系。比如下面这个语法就很漂亮。
: def fab(max):
: n, a, b = 0, 0, 1
: while n < max:
: yield b # 不是线程调度那个yield
: a, b = b, a + b
: n = n + 1
: for n in fab(5):
: print n
: C/C++要实现coroutine也是用类似context的方法，以至于有一些人就直接把
|
l*********s
发帖数: 5409 | 26 佩服的5体投地！
【在 w***g 的大作中提到】
: pthread是包在OS线程外的。light-weighted thread需要用到用户态线程。
: 微软的fiber是用户态的，但是因为是windows世界的，不怎么招人待见。
: 在多核上做用户态线程是一件非常非常恶心的事情，GO最主要的贡献其实
: 就是把这件事做成了。主要的恶心之处就是怎么处理job stealing:一个
: 操统线程上面的任务都跑完了，就需要去别的操统线程那儿把活弄过来。
: 这就涉及到各种同步，各种locking。Locking多了，性能就下来了。
: 这种事情以前应该不少公司内部都有人做过，能做这个的人一般也都
: 屌得不得了。其实稍微对比一下就能知道multi-core有多难做：
: node.js不支持multi-core，python折腾这么多年也还是个残疾。
: 如果你想更多地了解一下，可以从man makecontext
|
l*********s
发帖数: 5409 | 27 re
【在 w***g 的大作中提到】
: coroutine主要是有语法上的好处，跟性能没关系。比如下面这个语法就很漂亮。
: def fab(max):
: n, a, b = 0, 0, 1
: while n < max:
: yield b # 不是线程调度那个yield
: a, b = b, a + b
: n = n + 1
: for n in fab(5):
: print n
: C/C++要实现coroutine也是用类似context的方法，以至于有一些人就直接把
|
l*********s
发帖数: 5409 | 28 扯淡，你写java的时候怎么不说。
【在 d****i 的大作中提到】
: 不要虚假的fancy华而不实和语法糖，要实用要简单要易懂要性能，这是Unix的宗旨和
: 哲学。
|
w***g
发帖数: 5958 | 29 我有段时间老搞不明白plan 9有啥牛B的。后来才发现plan 9提出的不少新概念已经被
Linux借鉴了。Plan 9是80年代的东西，Linux是90年代的东西。我知道plan 9是2005
年，自然是见怪不怪了。话说我当年在的实验室有个plan9的拥趸，说起来就是
"pthread is broken"。当时我们做的project底层是一套不知道从哪儿搞来的
用户态plan9的库。
就像现在读阿西莫夫的小说，自然读不出任何新鲜的东西。
thread
【在 d****i 的大作中提到】
: 所以说rob pike搞了半天coroutine, 都是闲的蛋疼扯的，最后性能还是比不过thread
: 。所以plan 9也就作为贝尔实验室的试验而早就进了坟墓，不像同是出自贝尔实验室大
: 师的Unix得以千秋万代伟光正。
:
: managed
: operating
: .
|
z****e
发帖数: 54598 | 30 所谓的fiber其实就是一个suspendable thread
就是加了一层
加了这一层好处就是可以提升效率，同时不用搞各种恶心的cb
但是随着这一层技术的成熟，这些东西对于用户将会是透明的
java已经抄了这些功能，基本上简化到了一个annotation
@Suspendable之后就ok啦
不过现在还需要用javaagent，其实差不了太多
另外并发用immutable足够了，用msg
managed
operating
.
【在 d****i 的大作中提到】
: 发现一片很好的文章，解释了thread, coroutine, fiber之间的联系和区别，结论是
: Use thread for sure if you can, 哈哈。
: http://stackoverflow.com/questions/16765736/why-doesnt-linux-us
: Coroutines, fibers and their ilk are thread-like execution contexts managed
: by programming language runtimes or libraries, rather than by the operating
: system, which regards them to be in one thread. They are of limited use;
: nobody in their right mind uses such hacks when real threads are available.
|
|
|
z****e
发帖数: 54598 | 31
当线程和内存都被很好滴管理起来之后
你们写c的还有市场吗？
【在 w***g 的大作中提到】
: 我有段时间老搞不明白plan 9有啥牛B的。后来才发现plan 9提出的不少新概念已经被
: Linux借鉴了。Plan 9是80年代的东西，Linux是90年代的东西。我知道plan 9是2005
: 年，自然是见怪不怪了。话说我当年在的实验室有个plan9的拥趸，说起来就是
: "pthread is broken"。当时我们做的project底层是一套不知道从哪儿搞来的
: 用户态plan9的库。
: 就像现在读阿西莫夫的小说，自然读不出任何新鲜的东西。
:
: thread
|
p***o
发帖数: 1252 | 32 除非这些code就你一个人写一个人维护, 要不然后面接手的人要骂娘。
【在 l*********s 的大作中提到】
: 知道原则就好很多了，谢谢
|
z****e
发帖数: 54598 | 33
vert.x已经把各种傻瓜化做到了极致
线程托管，内存托管，硬盘托管，跨平台
能搞的各种脏活累活都被它搞了
vert.x之后，关注底层的都是傻逼
你只需要关心上层逻辑就可以了
底层会越来越抽象，最后简化成几个数字而已
随着这些技术的成熟
社会对于c这种东西在server side的需求会大幅降低
而对于java的需求会大幅升高，因为vert.x打好了一个平台
然后java之后，其他脚本怎么搞，那就看domain了
物理层的封装接近完成
现在都有很成熟的方法来封装物理层面的部件了
【在 l*********s 的大作中提到】
: 扯淡，你写java的时候怎么不说。
|
z****e
发帖数: 54598 | 34
vert.x把这些概念全部屏蔽了
现在连dont block me这一条黄金准则都被vertx sync给干掉了
以后你写商业逻辑，只需要估算一下
如果执行时间久的话，放一个annotation
@Suspendable上去，thread就会自动切换component/verticle
不需要操心了，如果不知道到底执行多久
对于所有的verticle里面的方法，全部放@Suspendable
【在 d****i 的大作中提到】
: 不要虚假的fancy华而不实和语法糖，要实用要简单要易懂要性能，这是Unix的宗旨和
: 哲学。
|
p***o
发帖数: 1252 | 35 cooperative multitasking这类和asynchronous io是互补的，这么多年的历史
看来只要大家被后者的callback hell恶心的不行了就会来鼓捣前者。
【在 z****e 的大作中提到】
: 所谓的fiber其实就是一个suspendable thread
: 就是加了一层
: 加了这一层好处就是可以提升效率，同时不用搞各种恶心的cb
: 但是随着这一层技术的成熟，这些东西对于用户将会是透明的
: java已经抄了这些功能，基本上简化到了一个annotation
: @Suspendable之后就ok啦
: 不过现在还需要用javaagent，其实差不了太多
: 另外并发用immutable足够了，用msg
:
: managed
|
z****e
发帖数: 54598 | 36
这个就跟gc什么一样
托管了就好，就看有没有轮子了
如果手动去搞，就比较麻烦
有托管的，就会有很多人去用
开自动档舒服啊，适合我这样的懒人
【在 p***o 的大作中提到】
: cooperative multitasking这类和asynchronous io是互补的，这么多年的历史
: 看来只要大家被后者的callback hell恶心的不行了就会来鼓捣前者。
|
p***o
发帖数: 1252 | 37 这你可真不用担心，像vert.x这么简单易用的轮子概念清楚的话上手快得很。
【在 z****e 的大作中提到】
:
: 这个就跟gc什么一样
: 托管了就好，就看有没有轮子了
: 如果手动去搞，就比较麻烦
: 有托管的，就会有很多人去用
: 开自动档舒服啊，适合我这样的懒人
|
d****i
发帖数: 4809 | 38 你扯啥，Java就是C和C++的正宗嫡传和马甲，Java的多线程完全是wrap的pthread和
Win32 thread, 完全一样。
【在 l*********s 的大作中提到】
: 扯淡，你写java的时候怎么不说。
|
l*********s
发帖数: 5409 | 39 java让程序员从内存管理中解放出来， golang让程序员从线程管理解放出来，一样亲
儿子亲闺女， 你觉得go不行只能说你品味太差。
【在 d****i 的大作中提到】
: 你扯啥，Java就是C和C++的正宗嫡传和马甲，Java的多线程完全是wrap的pthread和
: Win32 thread, 完全一样。
|
w***g
发帖数: 5958 | 40 一个东西做到清楚明白了，其实寿命也就差不多到了。
vert.x做的无非就是写网站后台。不知道你们有没有看前两天关于meteor的讨论。
再过两年，大部分网站后台的活可能都没有了。
搞IT的，只听说做一票买卖退休的，还真没啥金饭碗金技术能养人一辈子的。
vert.x vs C，50步100步而已。
【在 p***o 的大作中提到】
: 这你可真不用担心，像vert.x这么简单易用的轮子概念清楚的话上手快得很。
|
|
|
l*********s
发帖数: 5409 | 41 然而这和java程序员没啥关系。java和c命运差不多，成熟了也就没啥搞头了。
【在 z****e 的大作中提到】
:
: 这个就跟gc什么一样
: 托管了就好，就看有没有轮子了
: 如果手动去搞，就比较麻烦
: 有托管的，就会有很多人去用
: 开自动档舒服啊，适合我这样的懒人
|
l*********s
发帖数: 5409 | 42 exactly, it行业火的原因就是不断的推陈出新，一个技术吃一辈子根本就是个坏事。
【在 w***g 的大作中提到】
: 一个东西做到清楚明白了，其实寿命也就差不多到了。
: vert.x做的无非就是写网站后台。不知道你们有没有看前两天关于meteor的讨论。
: 再过两年，大部分网站后台的活可能都没有了。
: 搞IT的，只听说做一票买卖退休的，还真没啥金饭碗金技术能养人一辈子的。
: vert.x vs C，50步100步而已。
|
T********i
发帖数: 2416 | 43 其实这个C++库我有做。
但是，
第一，我最早要今年11月2号以后才能公开。
第二，我现在没有任何开源的计划。
现在，欢迎继续和我叫板指控我吹牛。 |
d****i
发帖数: 4809 | 44 放屁，你要当IT的妓女没人拦着你，要当医生就得有像wdong和goodbug这样的人。
【在 l*********s 的大作中提到】
: exactly, it行业火的原因就是不断的推陈出新，一个技术吃一辈子根本就是个坏事。
|
l*********s
发帖数: 5409 | 45 大势如此，你同不同意有个蛋用？
【在 d****i 的大作中提到】
: 放屁，你要当IT的妓女没人拦着你，要当医生就得有像wdong和goodbug这样的人。
|
d****i
发帖数: 4809 | 46 大势个屁，你看狗的go再过几年消失的无影无踪了都有可能，这种自我折腾真是妓女的
本质偏好，一天换个主，三十后变黄脸婆。
【在 l*********s 的大作中提到】
: 大势如此，你同不同意有个蛋用？
|
l*********s
发帖数: 5409 | 47 得了吧，你觉得自己是明星大碗，看客们只会觉得这么老了还要和小鲜肉抢客源真真可
怜。
【在 d****i 的大作中提到】
: 大势个屁，你看狗的go再过几年消失的无影无踪了都有可能，这种自我折腾真是妓女的
: 本质偏好，一天换个主，三十后变黄脸婆。
|
g*****g
发帖数: 34805 | 48 那是写 CRUD, 商业逻辑总得有人来做。到给个需求机器人就给实现之前，码农的活不
会变少。
【在 w***g 的大作中提到】
: 一个东西做到清楚明白了，其实寿命也就差不多到了。
: vert.x做的无非就是写网站后台。不知道你们有没有看前两天关于meteor的讨论。
: 再过两年，大部分网站后台的活可能都没有了。
: 搞IT的，只听说做一票买卖退休的，还真没啥金饭碗金技术能养人一辈子的。
: vert.x vs C，50步100步而已。
|
w***g
发帖数: 5958 | 49 话说把网络I/O做得超快对我等平民百姓有啥实际应用？请科普下。
我看了你的帖子有点中毒了，想写点啥东西玩玩。
【在 T********i 的大作中提到】
: C/C++做I/O最优化的方案是每个CPU socket一个网卡(每个Socket都有独立的IOH)。
: 同时每个socket用一个core单线程处理I/O。
: 任何违背这个原则的方案都不是最优的，也就是说你增加网卡数量或者线程数量说明你
: 不合格。
: 我估计我的建议用处不大。我只能帮到这里了。
|
p*u
发帖数: 2454 | 50
check out Intel DPDK
【在 w***g 的大作中提到】
: 话说把网络I/O做得超快对我等平民百姓有啥实际应用？请科普下。
: 我看了你的帖子有点中毒了，想写点啥东西玩玩。
|
|
|
d****i
发帖数: 4809 | 51 你也老大不小了，怎么还这么喜欢装嫩，愿做妓女请自便。
【在 l*********s 的大作中提到】
: 得了吧，你觉得自己是明星大碗，看客们只会觉得这么老了还要和小鲜肉抢客源真真可
: 怜。
|
w***g
发帖数: 5958 | 52 DPDK我知道。但是用来干嘛？
刚刚看了篇USENIX 2015 best paper，用software distributed shared memory
做大数据处理。里面有个图显示RDMA比TCP要快两三倍。
感觉最后都是拚硬件。InfiniBand一根网线就要上百，
网卡上千，交换机一个好几万。都是大投资啊。
相比之下，花千把块钱买个Titan X就可以玩deep learning了，
要平民化得多。
【在 p*u 的大作中提到】
:
: check out Intel DPDK
|
T********i
发帖数: 2416 | 53 我也想不出来对你有啥实际应用。
对有些产业应该有用。比如微信之类聊天服务，IoT接入设备之类的，一台Server几十G
throughput支持上千万长连接。节约几十倍的硬件你说有用没有用？
关键的是，现在绝大多数孩子不理解常识。你和他说常识他认为你扯淡。你告诉他有时
候单核单线程最优他就是不理解。呵呵。
【在 w***g 的大作中提到】
: 话说把网络I/O做得超快对我等平民百姓有啥实际应用？请科普下。
: 我看了你的帖子有点中毒了，想写点啥东西玩玩。
|
z****e
发帖数: 54598 | 54 vert.x让你从内存，cpu，硬盘，线程管理中解放出来
这个纯粹就是看封装程度，vert.x已经把封装做到了极致
剩下的就是提供统一接口给不同的脚本语言
并且在这个基础之上，发展各个领域自身的脚本
【在 l*********s 的大作中提到】
: java让程序员从内存管理中解放出来， golang让程序员从线程管理解放出来，一样亲
: 儿子亲闺女， 你觉得go不行只能说你品味太差。
|
z****e
发帖数: 54598 | 55
once again
不是网站的后端，是所有东西的后端
包括socket, streaming这些
甚至还有file system
如果你现在还认为这个东西只能做website的话
那就太凹凸了
另外，front end的东西一直都在变，这个很正常
但是back end的东西，20年前的java，10年前的spring
都在被大面积使用中，你没写过企业软件，这个是硬伤
java的大部分东西都是一层一层往上累积
跟front end三十年河东三十年河西不是一回事
back end从java开始，每次新潮流涌现
都会从中抽取几个做得特别好的留下来
然后寻找其他部分的互补，目前看
back end几乎所有部分都被很好滴填补上了
要说还有什么没有，那就是各个domain自身的scripts还比较缺乏
比如r，很多领域都缺少r这样的脚本
而将来jvm和vert.x统一backend之后
需要做的就是在这个基础之上，作出各种脚本引擎来
实际上vert.x已经朝着这个目标大幅迈进了
os->jvm->vert.x->scripts，这个就是一个进步
跟website的一天到晚就做http还有webpage不是一回事
vert.x对于java的强化，就类似java对于os以及c的强化一样
这次强化过去之后，这些东西就慢慢不再重要起来
就变成了纯粹的数字
我们从来没有人认为it有什么技术可以吃一辈子
但是我们也同样认为，有些东西是永远不会被淘汰的
就像20年前的java，10年前的spring那样
而不是每隔十年重构一次系统，backend从来不是这种搞法
backend是搭积木，frontend是涂写板
两回事，不要用frontend的思路来看待backend的大系统
还是那句话，你没写过企业软件，这个是硬伤
【在 w***g 的大作中提到】
: 一个东西做到清楚明白了，其实寿命也就差不多到了。
: vert.x做的无非就是写网站后台。不知道你们有没有看前两天关于meteor的讨论。
: 再过两年，大部分网站后台的活可能都没有了。
: 搞IT的，只听说做一票买卖退休的，还真没啥金饭碗金技术能养人一辈子的。
: vert.x vs C，50步100步而已。
|
z****e
发帖数: 54598 | 56
我个人认为
语言到了java这一个level
基本上就是极致了
剩下的通过类库扩展
而不是在语法上翻来覆去地改
拜托，类库也可以实现语言内置的功能点好不好
就像quasar之于java
只不过有些语言直接做到了语言本身中去
有些语言通过类库扩展
这就像ide，你觉得是插件的ide比较流行呢
比如eclipse, idea
还是以前那种，给你一个ide，然后什么都有流行？
比如jbuilder
现在都是通过扩展来做了，语言只负责最核心的内容
类似的，vert.x也只负责最核心的部分
剩下的通过扩展来搞，你们这种换一个场景就换一个语言的搞法落伍了
【在 l*********s 的大作中提到】
: 然而这和java程序员没啥关系。java和c命运差不多，成熟了也就没啥搞头了。
|
z****e
发帖数: 54598 | 57 换一个场景就换一个语言
就好比某些公司
一开始ror，然后node，然后scala，再后来go
这些系统单个已经很恶心了，凑一起最后都是屎坑
在不同的语言的eco中切换，人的大脑会厌烦这些切换
卢森堡就是一个三语言国家
结果很多小孩子满脑子都是单词
最后出不了文学大师
同样道理，你同一个功能用不同语言实现
看上去很酷，其实都是屎坑
维护起来，心中草泥马各种奔腾而过
擦过屁股的应该都深受其害
没擦过屁股的猴子不是好猴子 |
g*****g
发帖数: 34805 | 58 吹牛逼的时候有用。show鸡鸡的时候然并卵。
十G
【在 T********i 的大作中提到】
: 我也想不出来对你有啥实际应用。
: 对有些产业应该有用。比如微信之类聊天服务，IoT接入设备之类的，一台Server几十G
: throughput支持上千万长连接。节约几十倍的硬件你说有用没有用？
: 关键的是，现在绝大多数孩子不理解常识。你和他说常识他认为你扯淡。你告诉他有时
: 候单核单线程最优他就是不理解。呵呵。
|
T********i
发帖数: 2416 | 59 就知道你这个傻逼会跳出来。
我说有傻孩子不懂常识，你就出来认领。
你问问wdong，这个是不是常识？
再次问候你父母。这个家教lol。
【在 g*****g 的大作中提到】
: 吹牛逼的时候有用。show鸡鸡的时候然并卵。
:
: 十G
|
d****i
发帖数: 4809 | 60 魏老师息怒，你和好虫都是这里我敬佩的人。说说你的IoT的backend的方案吧，怎么增
加throughput，如果用单机的话，用什么协议。
【在 T********i 的大作中提到】
: 就知道你这个傻逼会跳出来。
: 我说有傻孩子不懂常识，你就出来认领。
: 你问问wdong，这个是不是常识？
: 再次问候你父母。这个家教lol。
|
|
|
g*****g
发帖数: 34805 | 61 超过1万并发用户，每上一个数量级都会有新的问题和解决方案。连1000用户都没见过
，成天装逼我这千万并发用户单机怎么处理，太监里的战斗机而已。不服拿app store
里下载数目大家看看就是。尼玛用户还有吹出来的？
【在 d****i 的大作中提到】
: 魏老师息怒，你和好虫都是这里我敬佩的人。说说你的IoT的backend的方案吧，怎么增
: 加throughput，如果用单机的话，用什么协议。
|
w***g
发帖数: 5958 | 62
C10K是10年前的问题了。现在流行的是C10M。这10M个用户大部分只是连在那里而已，不
是所有用户同时都拼了命地在发数据。而且也不肯能是啥复杂到要读写数据库的应用，
参考这个
http://c10m.robertgraham.com/p/manifesto.html
$1200的单机的性能参数(文中没说是啥机器，我估计是一个router或load balancer之
类的东西)
- 10 million concurrent connections
- 10 gigabits/second
- 10 million packets/second
- 10 microsecond latency
- 10 microsecond jitter
- 1 million connections/second
不过用java写的话估计到不了。
store
【在 g*****g 的大作中提到】
: 超过1万并发用户，每上一个数量级都会有新的问题和解决方案。连1000用户都没见过
: ，成天装逼我这千万并发用户单机怎么处理，太监里的战斗机而已。不服拿app store
: 里下载数目大家看看就是。尼玛用户还有吹出来的？
|
g*****g
发帖数: 34805 | 63 这种 benchmark意义不大。有几个应用是不用连数据库的？一连数据库你再看你能支持
多少。
再说了，根本的是你有机会面对那么多用户。意淫自己有屠龙术就是装逼而已。
，不
【在 w***g 的大作中提到】
:
: C10K是10年前的问题了。现在流行的是C10M。这10M个用户大部分只是连在那里而已，不
: 是所有用户同时都拼了命地在发数据。而且也不肯能是啥复杂到要读写数据库的应用，
: 参考这个
: http://c10m.robertgraham.com/p/manifesto.html
: $1200的单机的性能参数(文中没说是啥机器，我估计是一个router或load balancer之
: 类的东西)
: - 10 million concurrent connections
: - 10 gigabits/second
: - 10 million packets/second
|
T********i
发帖数: 2416 | 64 很多用户同时收发这种系统throughput一般能达到网卡的极限带宽。毕竟仅仅是存储转
发而已。
一般一个two way server total throughput达到40G没有问题。
你算算，双CPU，每个CPU 12 cores。只有一个Core管I/O收发。给OS留一个core就好了
。还有10个Core，能干多少事？
那个蠢货就让他一直蠢下去好了。毕竟他这种没脸没皮的，就算我系统摆在他面前，他
也不会去死。家教问题，无解。
，不
【在 w***g 的大作中提到】
:
: C10K是10年前的问题了。现在流行的是C10M。这10M个用户大部分只是连在那里而已，不
: 是所有用户同时都拼了命地在发数据。而且也不肯能是啥复杂到要读写数据库的应用，
: 参考这个
: http://c10m.robertgraham.com/p/manifesto.html
: $1200的单机的性能参数(文中没说是啥机器，我估计是一个router或load balancer之
: 类的东西)
: - 10 million concurrent connections
: - 10 gigabits/second
: - 10 million packets/second
|
g*****g
发帖数: 34805 | 65 你单机把银河系都做了也是然并卵。见过1000个并发用户再来吹吧，太监中的战斗机。
【在 T********i 的大作中提到】
: 很多用户同时收发这种系统throughput一般能达到网卡的极限带宽。毕竟仅仅是存储转
: 发而已。
: 一般一个two way server total throughput达到40G没有问题。
: 你算算，双CPU，每个CPU 12 cores。只有一个Core管I/O收发。给OS留一个core就好了
: 。还有10个Core，能干多少事？
: 那个蠢货就让他一直蠢下去好了。毕竟他这种没脸没皮的，就算我系统摆在他面前，他
: 也不会去死。家教问题，无解。
:
: ，不
|
w***g
发帖数: 5958 | 66 应用不一样。我做的服务，有时候单机每秒处理10个请求就不错了。
你肯定也觉得没用。
比如cloudflare, riverbed这种，C10M还是很有用的。这块也能算得上
一个industry了。
【在 g*****g 的大作中提到】
: 这种 benchmark意义不大。有几个应用是不用连数据库的？一连数据库你再看你能支持
: 多少。
: 再说了，根本的是你有机会面对那么多用户。意淫自己有屠龙术就是装逼而已。
:
: ，不
|
T********i
发帖数: 2416 | 67 你的毛病是听不懂人话。家教下做。估计当年五胡乱华，八国联军的时候祖上家里都没
留人。lol。
【在 g*****g 的大作中提到】
: 你单机把银河系都做了也是然并卵。见过1000个并发用户再来吹吧，太监中的战斗机。
|
g*****g
发帖数: 34805 | 68 我说的很明白，重要的是做，不是装逼。要吹 能做C10m, 就拿个产品出来，否则有卵
用。傻逼太监都丢人两年了，还是屁都没有。12306做成计数器，谁信谁傻逼。
【在 w***g 的大作中提到】
: 应用不一样。我做的服务，有时候单机每秒处理10个请求就不错了。
: 你肯定也觉得没用。
: 比如cloudflare, riverbed这种，C10M还是很有用的。这块也能算得上
: 一个industry了。
|
T********i
发帖数: 2416 | 69 你这种无知无耻的。还有脸上来找抽。
是不是家族遗传受虐狂？
【在 g*****g 的大作中提到】
: 我说的很明白，重要的是做，不是装逼。要吹 能做C10m, 就拿个产品出来，否则有卵
: 用。傻逼太监都丢人两年了，还是屁都没有。12306做成计数器，谁信谁傻逼。
|
g*****g
发帖数: 34805 | 70 LOL，傻逼太监就别出来现了。尼玛没鸡鸡就没底气呀。
【在 T********i 的大作中提到】
: 你这种无知无耻的。还有脸上来找抽。
: 是不是家族遗传受虐狂？
|
|
|
T********i
发帖数: 2416 | 71 说过了，你这种不要脸的，即使系统摆在你面前你也不会去死。
你说过，这种高性能IO你认为没有可能，白纸黑字的证据。
现在又让我做出来给你看。太把你自己当回事了。
从你成天像只苍蝇一样恶心人的表现看。你爹妈家教的责任比较大。欢迎知情的私信给
我。我倒要看看这一家人都是怎样的极品？呵呵。
【在 g*****g 的大作中提到】
: LOL，傻逼太监就别出来现了。尼玛没鸡鸡就没底气呀。
|
g*****g
发帖数: 34805 | 72 你丫1000个用户都没见着，一千万用户撑不撑得起有蛋用。傻逼还嘴硬。
【在 T********i 的大作中提到】
: 说过了，你这种不要脸的，即使系统摆在你面前你也不会去死。
: 你说过，这种高性能IO你认为没有可能，白纸黑字的证据。
: 现在又让我做出来给你看。太把你自己当回事了。
: 从你成天像只苍蝇一样恶心人的表现看。你爹妈家教的责任比较大。欢迎知情的私信给
: 我。我倒要看看这一家人都是怎样的极品？呵呵。
|
T********i
发帖数: 2416 | 73 操你妈，你说的是人话么？难道你爹妈你全家都是这种说话方式？
简直是水浒里面的泼皮牛二。
牛二道：“怎么杀人刀上没血？”杨志道：“把人一刀砍了，并无血痕，只是个快。”
牛二道：“我不信，你把刀来剁一个人我看。”杨志道：“禁城之中，如何敢杀人？
你不信时，取一只狗来杀与你看。”牛二道：“你说杀人，不曾说杀狗！”杨志道：“
你不买便罢，只管缠人做甚么？”牛二道：“你将来我看。”杨志道：“你只顾没了当
，洒家又不是你撩拨的！”牛二道：“你敢杀我？”杨志道：“和你往日无冤，昔日无
仇，一物不成两物，现在没来由杀你做甚么？”
【在 g*****g 的大作中提到】
: 你丫1000个用户都没见着，一千万用户撑不撑得起有蛋用。傻逼还嘴硬。
|
