s***o
发帖数: 2191 | |
t*****n
发帖数: 2578 | 2 几个疑问：
1 java写的scheduler如何比OS native的performance好？
2 不靠底层汇编或机器码如何让java实现context switch？
3 他这套到底比java自己的thread实现强在何处？没看出来 |
z****e
发帖数: 54598 | 3 尝试着回答一下这个问题
1）做不到比os native的更好，但是问题在于，有些操作系统根本就没有cooperative
sheduling，比如linux，如果有的话，直接做一层包装就好了，但是没有的话，就只能
让语言来做了
2）不靠机器码，但是靠字节码，基本上就差不多了，光靠当前java的api，是不够的，
需要加多一个context参数，参考kotlin的coroutine实现，或者是通过java agent_织
入_一些context代码，这就是quasar的实现，这也是loom名称的由来
3）强在哪里呢
嗯，这个说来话长，说说我的理解
wdong有一篇回帖，解释了os层面cooperative scheduling和preemptive scheduling的
区别，有空自己去找，但是我觉得他说得复杂了，当然也因为后来用户层面框架的发展
，比如actor model有关系，看看我能不能解释清楚，这一块涉及的东西太多，os&jvm
和vert.x/actor model乃至开发者自身，都有需要配合的部分，任何一个部分不能掉链
子，所以解释起来不容易
先说os&jvm层面，这个是这样，unix和windows都有用户态线程，就是协程啦，一个虚
拟线程，这个其实60年代就有了，也不是什么新的东西，需要在这一层面做到的是，对
于虚拟线程，协程，能够suspend，然后过一段时间之后，再将其resume，resume的时
候，这个虚拟线程里面的东西不能丢掉，尤其是在执行方法的时候，比如
func test(){
....
var i = 1;
//suspend
...
//resume
print(i)//这里不能为空
...
linux按照wdong的说法，是没有用户态线程的，所以这里定义的i = 1是放在thread的
stack里面，resume的时候就挂了，那怎么办？很简单，在这里定义一个context，任何
在方法里面定义的变量都放到context里面去，就是一个map啦，然后suspend的时候，
存起来，然后resume时候再取出来，期间thread去执行其他coroutine里面的代码，要
做到这一步，linux没有这一步，怎么办？jvm来实现，其他windows和unix有，直接做
一层包装就好了，当前java还没有这个东西，所以这个人要做的就是在jvm层面上，实
现这个东西，kotlin已经实现了，你用java调用kotlin的coroutine/suspend方法，你
就会发现多了一个参数，这个参数就是context
这是第一步，做到这一步之后，那就是什么时候resume的问题了
这个不能交给os/jvm来做，否则搞不好又得加锁，虽然协程开销少，我们也不希望协程
成千上万一起出现，这样lock就多，那怎么办？交给actor model和异步来搞
vert.x就是actor model的一种实现，用actor model和异步的好处就是线程数大幅减少
，原来比如一千个并发访问，需要启动一千个线程去处理，用了异步之后，对于io
bound的应用，只需要几个线程便可解决，然后这一千个通过某种方式排队进入这几个
线程，这样做的好处就是lock大幅下降了，但是这样做同时对用户提出了要求
这就是vert.x里面对使用者的要求：dont block me
还记得这个黄金原则吧？只要你能做到不block eventloop，区区几个线程就可以很轻
松地应付大并发访问的需要，然后再回头来看coroutine的作用，coroutine可以将线程
挂起并resume，太好，将其apply进我们的vert.x线程模型，能够解决什么问题呢？能
够让我们的callback代码变成跟同步代码一样的写法，然后因为lock数量的下降，性能
损耗也就少了，对比callback，大概是3%-5%的损耗
所以性能估算是这样
1）同步代码，比如分值是100，假设是io bound的程序，大量的crud，业务代码
2）那么改成异步之后，提升是几十倍甚至更多，我们实际测试，有说40倍，有说100多
倍的，这个不一定要看io bound程度，但是一般业务系统几十倍的提升一般都有，big
data engine另说，这个是cpu bound，一般提升不了多少，那就算是40倍吧，得分就是
40*100=4000
3）异步callback api引入了callback hell的问题，要解决该问题，引入了coroutine
，那么coroutine引入之后，对比未引入之前，损耗是3%-5%，算5%吧，那么就是4000*
（1-5%） = 3800
太好了
vert.x 3.5就要release了，新版本会加入kotlin的coroutine的native support，所以
coroutine其实要配合eventloop, actor model ,async api使用才能真正发挥价值，如
果无脑将所有thread全部改成coroutine，那么lock还是一大堆，性能还是上不去，这
就是wdong说的，lock多了，性能就下来了，所以感谢vert.x，打开了一扇新世界的大
门，看懂了vert.x再回头来看这些东西，都珍珍有价值啊
总结一下：
os&jvm需要实现的是用户态线程，coroutine，遇到io可以suspend
vert.x等框架需要实现的是，actor model，减少线程或者虚拟线程数量，减少lock
用户使用时候需要注意的是：不要写blocking code，否则第二点会受到影响
三者缺一不可，任何一步掉链子，这个性能优化就会出问题
但是实现起来也没有那么困难了，对于用户来说，尤其是vert.x的用户
本来就有要求不能随便block住eventloop，这个要求不变
greview时候看radle/maven里面任何的依赖，尤其是第三方类库要注意使用
尽量用vert.x自带的api，这样就不太可能blocked，然后对现有代码复杂度要有概念
上来一个n^2的复杂度，很容易就blocked，做到这两点
基本上就没有啥问题了，可以堆代码了
好了，上班了
【在 t*****n 的大作中提到】
: 几个疑问：
: 1 java写的scheduler如何比OS native的performance好？
: 2 不靠底层汇编或机器码如何让java实现context switch？
: 3 他这套到底比java自己的thread实现强在何处？没看出来
|
z****e
发帖数: 54598 | 4 其实一路走来
同步转异步，lock free，减少线程数，不要乱开线程，这很重要
遇到callback hell
解决callback hell，通过promise/future方式->高阶函数
高阶函数->reactivex，感觉不方便
coroutine出现，改进写法
这么一串下来，理解起来就很容易
还是要跟着vert.x一起成长 |
z****e
发帖数: 54598 | |
z****e
发帖数: 54598 | 6 coroutine可以看一下kt的解释
其实就是一个状态机
suspend之后，定期去check一下是否可以resume
这个放在eventloop里面就特别方便
因为eventloop本来就是一个无限循环的线程
每一次loop去check一下就是了
因为有这一步的消耗，所以性能会损耗3%-5%
我估计就是这么来的
但是当前java要实现这个，关键是方法内部的状态
在suspend之后，线程转去执行其他操作之后
这个状态会丢失，用reflection也解决不了这个问题
还是需要存context，如果os支持，直接wrap一层
如果不支持，则需要jvm／java自己实现
ceylon这个语言估计很快也会有coroutine了
这个feature快烂大街了 |
s***o
发帖数: 2191 | 7 zhaoce回来了，看你在知乎上整天忽悠年轻妹子们，还以为乐不思蜀不来这了：）
【在 z****e 的大作中提到】
: coroutine可以看一下kt的解释
: 其实就是一个状态机
: suspend之后，定期去check一下是否可以resume
: 这个放在eventloop里面就特别方便
: 因为eventloop本来就是一个无限循环的线程
: 每一次loop去check一下就是了
: 因为有这一步的消耗，所以性能会损耗3%-5%
: 我估计就是这么来的
: 但是当前java要实现这个，关键是方法内部的状态
: 在suspend之后，线程转去执行其他操作之后
|
e*******o
发帖数: 4654 | 8 zhaoce 回来了 好虫还会远么？
【在 s***o 的大作中提到】
: zhaoce回来了，看你在知乎上整天忽悠年轻妹子们，还以为乐不思蜀不来这了：）
|
w***g
发帖数: 5958 | 9 赵策和魏老师竟然同时出现了. 本版这是要复兴的节奏?
【在 s***o 的大作中提到】
: zhaoce回来了，看你在知乎上整天忽悠年轻妹子们，还以为乐不思蜀不来这了：）
|
c******n
发帖数: 16666 | 10 哈哈 他id是哪个 我去尾行下
【在 s***o 的大作中提到】
: zhaoce回来了，看你在知乎上整天忽悠年轻妹子们，还以为乐不思蜀不来这了：）
|
|
|
s*******m
发帖数: 58 | 11 https://github.com/Tencent/libco
腾讯的Linux coroutine library, 很小 |
d*******r
发帖数: 3299 | 12 zhaoce还在坚持推广vert.x, 执着啊, 是觉得 kotlin对vert.x有帮助? |
z****e
发帖数: 54598 | 13 java现在打出来的包，也不比qq啊，chrome啊大啊
安装包才几十兆，qq的安装包都比jvm打出来的安装包大
假设都没有图片等资源的前提下
【在 s*******m 的大作中提到】
: https://github.com/Tencent/libco
: 腾讯的Linux coroutine library, 很小
|
z****e
发帖数: 54598 | 14
vert.x过去两年大发展啊，早已今非昔比了
这两年错过vert.x的是一个巨大的损失，不是我说
准备技术输出了，然后噱头就是
比spring mvc快几十倍
生态比go好几十倍
市场买不买这个账，不知道，管他呢，反正就是宣传
至于kotlin对vert.x的促进作用，看上面讲的coroutine部分
这个中国人贡献的代码已经merge进官方库了
马上就release了，就能用了
3.5的新增功能包括
kotlin的coroutine原生支持
rxjava 2.0的升级
jdbc client的callback的简化
强烈建议马上升级
ceylon贡献给了eclipse之后，也会加入coroutine
java这个还需要时间
现在项目中，java, kotlin, groovy都有，因为idea社区版加入了scala的滋持
所以准备上scala了，至于js本来就有，但是gradle里面一般都放在resources目录下
最近搞了下ruby，感觉挺好玩的，拿ruby和另外一个中国人写的脚本到时候来做演示
展示一下这个随便选一个脚本就能用来开发项目是怎样一番光景
太有趣了
vert.x最大的意义就在于，理清楚了actor model是如何利用少量线程
host住大量吞吐的情况，然后异步带来的callback hell
是如何解决的，这个问题算是解决了一半
主要是利用高阶函数来map
但是这样写起来很恶心，fp的东西毕竟受众没那么大
所以现在趋势都是coroutine，kotlin的coroutine已经有中国人在上面问了啊
他说他想用在游戏服务器上，现在是experimental，是不是合适用？
kotlin官方说，可以用的，所以
dumbcoder，你想做的游戏，现在怎样了？
这么好的一个游戏服架构，不想试试？
回头给你看一个东西，快做好了
【在 d*******r 的大作中提到】
: zhaoce还在坚持推广vert.x, 执着啊, 是觉得 kotlin对vert.x有帮助?
|
z****e
发帖数: 54598 | 15 java的coroutine 阿里的jvm已经做出来了
不过这也不是什么黑科技，能做出来的大把
而且不配合actor model的话
lock还是很多，性能还是上不去
只有配合了actor model，把线程数降下来
这样lock数量才会减少，而且引入immutable才会变得合理起来
否则满天飞的immutable，性能也还是上不去
但是这样要求不能写blocking code
这个只要有coroutine，书写难度就降下来很多
要不然一大堆高阶函数，哪有办法
map来map去的，很多人搞不定
coroutine之后，fp这一波热潮也差不多该到头了
最早是用来解决callback hell的方式
现在不用了，那高阶函数存在感会大幅下降
monad这些估计根本就没啥市场了
基本上跟之前预测的很像
就是知道什么是immutable，什么是1st class citizen这些
然后懂得用lambda，可以了
足够了，coroutine会接管剩下的部分
有了coroutine，就可以调用异步api，如同同步api一样
而且kotlin会在idea里面，给你加上一个绿色的小箭头
非常好玩 |
z****e
发帖数: 54598 | 16
看这个
http://www.mitbbs.com/article_t/JobHunting/33351471.html
想到什么没有？
给你发私信
【在 d*******r 的大作中提到】
: zhaoce还在坚持推广vert.x, 执着啊, 是觉得 kotlin对vert.x有帮助?
|
z****e
发帖数: 54598 | 17
净说些没用的，探讨一下高性能的架构
你上次说的cooperative scheduling的主要问题就是lock
lock多了性能就下来了，对吧？
这个问题可以通过actor model解决
而且一定要手动挡，不能自动让os去考虑resume这些问题
什么时候suspend，什么时候resume，要暴露给框架去使用
语言和os系统层面，不用管，只需要提供接口就好了
要不然actor model威力发挥不出来
现在一般是io时候，才会使用suspend，callback之后resume
然后actor model要确保跟cpu cores匹配的线程数运行
不能造一大堆线程，线程数下降了，并发修改的lock就减少了
然后要求线程之间的通信，全部是immutable的
这样lock就彻底干掉了，用户线程专心执行交给它的代码就好了
那么coroutine有一个重要作用，就是执行之后要能够suspend
我们把遇到io的api全部做成异步和suspendable的
然后在verticle中使用coroutine，这样一来，就不要求cooperative sheduling有什么
lock了
不管是怎么实现的，哪怕是很傻的实现，都能满足要求了
没有lock嘛，只要有办法suspend和resume就行
这就减轻了os的设计压力，所以也就不需要什么“牛得不得了的人”来设计了
否则一堆lock，这个很难
所以actor model的意义在于降低线程数，减少lock，让线程之间immutable，从而彻底
干掉lock
然后coroutine提供suspend和resume两个api，这样os只需要做到能够暂停，能够恢复
剩下的是框架的事，这个要求就降低太多了，加多一个context就能搞定
而且是这样，coroutine只有在我们需要的时候，才用
所以不管是thread还是coroutine，数量都会下降
那这个对于os的调度压力来说，那是小太多太多了
所以好马配好鞍，如果没有actor model，哪怕有了coroutine，也是混乱不堪
有了actor model这种reactor模式，匹配上core数量的线程数
然后手动暂停和恢复，那os或者jvm只要提供suspend和resume两个api，就可以了
至于lock，我们不用lock嘛，就没有损耗了
【在 w***g 的大作中提到】
: 赵策和魏老师竟然同时出现了. 本版这是要复兴的节奏?
|
z****e
发帖数: 54598 | 18 其实coroutine对于我们来说，只是锦上添花的作用而已
性能相比起callback和高阶函数来说，性能要牺牲个3%-5%
但是好处是可以让普通程序猿，用他习惯的方式来写代码
而不用去搞fp那一套 |
w***g
发帖数: 5958 | 19 有理. cooperative threading有助于降低lock contention.
但是你有没有想过, 如果OS thread lock了, 这个thread上面所有的
coroutine就全都挂起了. 我实在不愿意用coroutine这个词,
因为你们说的其实就是cooperative user-space threading.
真正的coroutine好几十年前就已经死了. 主流语言没一个支持
coroutine的. python的yield勉强算半个吧.
我上次说这个都好几年前了吧. 我现在改行做machine learning了.
【在 z****e 的大作中提到】
: 其实coroutine对于我们来说，只是锦上添花的作用而已
: 性能相比起callback和高阶函数来说，性能要牺牲个3%-5%
: 但是好处是可以让普通程序猿，用他习惯的方式来写代码
: 而不用去搞fp那一套
|
z****e
发帖数: 54598 | 20
ml那个东西到底怎么赚钱，business model至今无法验证
ng又跑回去开课赚钱了，这个风险太大
但是这种性能提升对于客户价值来说意义甚大
开支马上降下来，效果立竿见影
这些年异步(lambda)，callback(node.js)，coroutine(go)都在摸索
到现在这个阶段，算是一个大成了，总算是解决了这个问题
不管是性能上的提升，保证可读性这些，各方面都有了一个能够接受的答案
这是我在vert.x上用kotlin的感受，那下面就是推广了
【在 w***g 的大作中提到】
: 有理. cooperative threading有助于降低lock contention.
: 但是你有没有想过, 如果OS thread lock了, 这个thread上面所有的
: coroutine就全都挂起了. 我实在不愿意用coroutine这个词,
: 因为你们说的其实就是cooperative user-space threading.
: 真正的coroutine好几十年前就已经死了. 主流语言没一个支持
: coroutine的. python的yield勉强算半个吧.
: 我上次说这个都好几年前了吧. 我现在改行做machine learning了.
|
|
|
z****e
发帖数: 54598 | 21
是啊，所以要求用户不能block住eventloop
这样来保证所有的用户thread都lock free
这个也是很麻烦的一件事，在工作中，很多人搞不清楚到底什么时候会block
解释半天，听不懂的很多
这里面涉及到复杂度，io这些
听得懂，工资就贵，听不懂的就便宜，这世界上没有两全的事
那要解决这个问题，那现在是这样
gradle的依赖全部控制住，不允许随便乱加第三方类库
如果要加，要review，gradle有一个build.gradle，所以定期review这个文件就好了
然后尽量用异步库，拿到异步库之后，用coroutine包装成类似同步的suspend方法
这样用起来就无压力了，这个还不会就直接火掉了
用这种方式来解决问题
os thread的lock，控制不了，这个也无能为力
只能看os自身的搞法了，但是对于要实现coroutine的jvm来说
这个实现的难度就降低很多了
coroutine是当前主流说法，只能从众
【在 w***g 的大作中提到】
: 有理. cooperative threading有助于降低lock contention.
: 但是你有没有想过, 如果OS thread lock了, 这个thread上面所有的
: coroutine就全都挂起了. 我实在不愿意用coroutine这个词,
: 因为你们说的其实就是cooperative user-space threading.
: 真正的coroutine好几十年前就已经死了. 主流语言没一个支持
: coroutine的. python的yield勉强算半个吧.
: 我上次说这个都好几年前了吧. 我现在改行做machine learning了.
|
w***g
发帖数: 5958 | 22 你再去看看多年前我的贴, 可能对go会有新的认识.
http://www.wdong.org/goshi-zen-yao-lai-de.html
【在 z****e 的大作中提到】
:
: 是啊，所以要求用户不能block住eventloop
: 这样来保证所有的用户thread都lock free
: 这个也是很麻烦的一件事，在工作中，很多人搞不清楚到底什么时候会block
: 解释半天，听不懂的很多
: 这里面涉及到复杂度，io这些
: 听得懂，工资就贵，听不懂的就便宜，这世界上没有两全的事
: 那要解决这个问题，那现在是这样
: gradle的依赖全部控制住，不允许随便乱加第三方类库
: 如果要加，要review，gradle有一个build.gradle，所以定期review这个文件就好了
|
x***4
发帖数: 1815 | 23 你在vertx里怎样访问db？手写sql？有没有可以偷懒的方法？
【在 z****e 的大作中提到】
:
: 是啊，所以要求用户不能block住eventloop
: 这样来保证所有的用户thread都lock free
: 这个也是很麻烦的一件事，在工作中，很多人搞不清楚到底什么时候会block
: 解释半天，听不懂的很多
: 这里面涉及到复杂度，io这些
: 听得懂，工资就贵，听不懂的就便宜，这世界上没有两全的事
: 那要解决这个问题，那现在是这样
: gradle的依赖全部控制住，不允许随便乱加第三方类库
: 如果要加，要review，gradle有一个build.gradle，所以定期review这个文件就好了
|
z****e
发帖数: 54598 | 24
又看了一遍，对vert.x的认识又加深了一层
对go反而没啥感觉
你说到在多核上做用户态线程是很恶心的一件事
假设是真的
那么vert.x就更加合理了
因为vert.x对比node.js，就是把原来单核的事
变成了多核的事，由multiple reactors来解决这个问题
所以等到它找到coroutine的时候
coroutine只需要考虑单核情况就可以了
就类似node.js
所以actor model越看越不可或缺，如果没有actor model
光靠语言一个来做，够呛
你说go做成了，嗯
只能说道路不同，go想做的更多
但是这样做的效果如何，目前看，觉得它做的一般
从benchmark上看，并没有表现出多少优势
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
【在 w***g 的大作中提到】
: 你再去看看多年前我的贴, 可能对go会有新的认识.
: http://www.wdong.org/goshi-zen-yao-lai-de.html
|
z****e
发帖数: 54598 | 25
用pg和jsonb类型，这样就不用写太多sql了
国内有人在做vert.x上的orm
说很快就要发布了，你可以等一段看看
我现在用async client，这个scala写的client，调用的是pg的异步api
http://vertx.io/docs/vertx-mysql-postgresql-client/java/
【在 x***4 的大作中提到】
: 你在vertx里怎样访问db？手写sql？有没有可以偷懒的方法？
|
d*******r
发帖数: 3299 | 26 哦，看到了. 现在有哪些大厂在用vert.x?
【在 z****e 的大作中提到】
:
: 用pg和jsonb类型，这样就不用写太多sql了
: 国内有人在做vert.x上的orm
: 说很快就要发布了，你可以等一段看看
: 我现在用async client，这个scala写的client，调用的是pg的异步api
: http://vertx.io/docs/vertx-mysql-postgresql-client/java/
|
z****e
发帖数: 54598 | 27
回你私信了
【在 d*******r 的大作中提到】
: 哦，看到了. 现在有哪些大厂在用vert.x?
|
O***b
发帖数: 104 | 28 哪些大厂用 vert.x 也保密啊，赵总也回我一个呗
【在 z****e 的大作中提到】
:
: 回你私信了
|
z****e
发帖数: 54598 | 29
发了，回头记得转我100伪币
【在 O***b 的大作中提到】
: 哪些大厂用 vert.x 也保密啊，赵总也回我一个呗
|
g****t
发帖数: 31659 | 30 Python function参数如果是mutable,不是每次调用的时候
有trick吗，例如
def f(..,x=[0])
我经常用x放上次函数被调用时候的信息。算是显式的yield。
Python 自己的yield我不用，因为它跟c实现的很多yield不太一样。
这些东西其实都是内存快照加上一些goto
: 有理. cooperative threading有助于降低lock contention.
: 但是你有没有想过, 如果OS thread lock了, 这个thread上面所有的
: coroutine就全都挂起了. 我实在不愿意用coroutine这个词,
: 因为你们说的其实就是cooperative user-space threading.
: 真正的coroutine好几十年前就已经死了. 主流语言没一个支持
: coroutine的. python的yield勉强算半个吧.
: 我上次说这个都好几年前了吧. 我现在改行做machine learning了.
【在 w***g 的大作中提到】
: 你再去看看多年前我的贴, 可能对go会有新的认识.
: http://www.wdong.org/goshi-zen-yao-lai-de.html
|
|
|
O***b
发帖数: 104 | 31 我潜水太多了，一共才9.4个伪币……
【在 z****e 的大作中提到】
:
: 发了，回头记得转我100伪币
|
c******n
发帖数: 16666 | 32 伪币已发 之前看你帖子 关注了vertx 还没机会做出东西
纯好奇下这个方向
【在 z****e 的大作中提到】
:
: 发了，回头记得转我100伪币
|
O***b
发帖数: 104 | 33 我去看了一下 vert.x 3.5的 roadmap，好像这个版本不会加入coroutine吧
cooperative
【在 z****e 的大作中提到】
: 尝试着回答一下这个问题
: 1）做不到比os native的更好，但是问题在于，有些操作系统根本就没有cooperative
: sheduling，比如linux，如果有的话，直接做一层包装就好了，但是没有的话，就只能
: 让语言来做了
: 2）不靠机器码，但是靠字节码，基本上就差不多了，光靠当前java的api，是不够的，
: 需要加多一个context参数，参考kotlin的coroutine实现，或者是通过java agent_织
: 入_一些context代码，这就是quasar的实现，这也是loom名称的由来
: 3）强在哪里呢
: 嗯，这个说来话长，说说我的理解
: wdong有一篇回帖，解释了os层面cooperative scheduling和preemptive scheduling的
|
x***4
发帖数: 1815 | 34 我个人感觉：
FP和immutable data能够让相当一部分业务逻辑容易理解，也容易测试。
但是用FP写async也不比callback hell好太多，还是非常繁琐难理解。
async/await，coroutine能让你的code长得跟同步的code差不多，能让async程序白菜
化。
最后插一句，static typing，容易做refactoring，bug也小。
所以我最喜欢fp+static type+coroutine。
【在 s***o 的大作中提到】
: http://mail.openjdk.java.net/pipermail/discuss/2017-September/004390.html
: Ron Pressler就是quasar的作者，我很佩服的一位牛人
|
z****e
发帖数: 54598 | 35
kotlin的coroutine在3.5中会加入
这个我可以跟你保证
如果没有你来找我，我给你多少伪币都行
那个pr已经merged
viet还会写一个blog介绍具体怎么使用
其实你自己加都无非那么一回事
关键的类是那个中国人写的coroutine dispatcher
主要是让coroutine run在vertx thread上就行
因为kotlin官方coroutine api支持的那几个fork&join, single thread啊这些
就少一个eventloop，用context.run on context就可以搞定了
顺便说一下，vert.x的kotlin那个主要贡献者，就是jetbrains的人
kotlin这个语言的支持，那个毛子贡献了三年
【在 O***b 的大作中提到】
: 我去看了一下 vert.x 3.5的 roadmap，好像这个版本不会加入coroutine吧
:
: cooperative
|
z****e
发帖数: 54598 | 36 import io.vertx.core.Context
import kotlinx.coroutines.experimental.CoroutineDispatcher
import kotlin.coroutines.experimental.CoroutineContext
open class VertxContextDispatcher(val vertxContext: Context, val vertxThread
:Thread) : CoroutineDispatcher() {
override fun dispatch(context: CoroutineContext, block: Runnable) {
if (Thread.currentThread() !== vertxThread) vertxContext.
runOnContext { _ -> block.run() }
else block.run()
}
}
关键的一个类，确保coroutine在vertx thread上运行
3.5中这个东西会放入vertx中，通过.dispatcher()可以直接获取
通过内置对象可以直接获取
所以就不需要自己去实现了，但是原理是这样
有了这个，剩下的就很简单了
其实就算官方不做，有了这个类，你自己都能做出来
当然啦，有官方支持是最好的，不容易写错 |
z****e
发帖数: 54598 | 37 看了下，文档已经写得差不多了，应该这两天就会release
github.com/vert-x3/vertx-lang-kotlin/blob/master/vertx-lang-kotlin-
coroutines/src/main/asciidoc/kotlin/index.adoc |
z****e
发帖数: 54598 | 38
immutable还是有用的，verticle之间需要immutable，用cglib做immutable object
type无所谓，用verticle封死就无所谓到底是static还是dynamic，就那点代码，随便玩
然后coroutine/async/await
实践中，对于java程序猿，没有接触过其他环境的java程序猿，纯后端出身的程序猿
我们一般建议先从groovy开始接触其他环境，一般半个小时后就能开始写了
动态类型并没有什么问题，前提是写verticle，然后元数据编程很好用
一个@immutable就能作出immutable了，都不需要自己倒腾cglib了，虽然cglib也不难
如果是以前做安卓的，则建议从kotlin开始接触其他环境
最近idea社区版支持scala啦，开始逐步接触尝试尝试
同时建议写点ruby啊什么的，来锻炼一下脚本的语法糖，蛮好玩的
目标成就：vert.x上全语言制霸
【在 x***4 的大作中提到】
: 我个人感觉：
: FP和immutable data能够让相当一部分业务逻辑容易理解，也容易测试。
: 但是用FP写async也不比callback hell好太多，还是非常繁琐难理解。
: async/await，coroutine能让你的code长得跟同步的code差不多，能让async程序白菜
: 化。
: 最后插一句，static typing，容易做refactoring，bug也小。
: 所以我最喜欢fp+static type+coroutine。
|
s***o
发帖数: 2191 | 39 这么多回帖，还以为又打起来了。我觉得这个project意义还是很大的，quasar早就有
人在用了。但是因为要挂agent，做bytecode manipulation，很多人有顾虑。如果有了
jvm level native support，估计会有新一堆的framework出来。 |
z****e
发帖数: 54598 | 40
听得懂的人自然懂
甚至是秒懂
第一个回帖就会同意我的看法
听不懂的人，死活就是不懂
还在lock上纠结
没戏
我觉得这是某些人傲慢的态度决定的
我说了中间少了一步
让他们去看，我觉得他们不会认真去研读的
包括wdong在内，其实压根就没看我在说什么
一副老子懂得比你多的傲慢态度
这样说下去就是鸡同鸭讲
没戏，放弃了，不用浪费时间了
你跟他们说，我们要的coroutine，就是一个简单的suspend&resume的功能
他们会说，这个不是coroutine，真正的coroutine是怎样怎样blablabla
至于这你妹是不是coroutine，话克，谁在乎？这不过一个定义而已
看过那个笑话吧？
老罗说，我要这个中杯
对不起先生，这个是大杯，左边这个是中杯，这个是大杯，这个是超大杯
……
我上视频吧哈
https://www.youtube.com/watch?v=ZdpiaZaZaDU
【在 s***o 的大作中提到】
: 这么多回帖，还以为又打起来了。我觉得这个project意义还是很大的，quasar早就有
: 人在用了。但是因为要挂agent，做bytecode manipulation，很多人有顾虑。如果有了
: jvm level native support，估计会有新一堆的framework出来。
|
|
|
g****t
发帖数: 31659 | 41 你是不是没读stdio帖子里的那个email?
第一行就是讲要user mode thread
后面也讲了对scheduler的设计约束
新线程模型的设计约束
: 听得懂的人自然懂
: 甚至是秒懂
: 第一个回帖就会同意我的看法
: 听不懂的人，死活就是不懂
: 还在lock上纠结
: 没戏
: 我觉得这是某些人傲慢的态度决定的
: 我说了中间少了一步
: 让他们去看，我觉得他们不会认真去研读的
: 包括wdong在内，其实压根就没看我在说什么
【在 z****e 的大作中提到】
:
: 听得懂的人自然懂
: 甚至是秒懂
: 第一个回帖就会同意我的看法
: 听不懂的人，死活就是不懂
: 还在lock上纠结
: 没戏
: 我觉得这是某些人傲慢的态度决定的
: 我说了中间少了一步
: 让他们去看，我觉得他们不会认真去研读的
|
w***g
发帖数: 5958 | 42 大家这么折腾, 主要原因是.
用户态线程切换比操统线程切换(都在同一个进程内)要快几百倍. 这个我理解是有两点
.第一进出操统syscall本身比较慢. 第二linux的thread是偷懒版的process,实现比较
低效. windows线程据说比linux线程更慢. 但windows有fiber.
因为只有切换时才有速度差别, 所以一般用户态线程库的优势需要起大量线程, 并且经常
切换才能体现出来. 这种情况发生最多的就是各种web服务器. 别的情况基本没这个需
求.
*起大量线程*这个需求很大程度上是被用户态线程的拥趸为了benchmark需要生造出来
的.
所以答案是:
1. 不是scheduler好. 而是线程切换快. 楼主贴的那个proposal里面也说研究sheduler
不是目标. 这个符合我一直说的用户态thread在多核上schedule难做的观点.
2. 通过jvm支持一套倒腾寄存器的机制, 新增一条context switch的jvm指令. 这个必须
在jvm里面做,并且需要尽可能直接地映射到处理器的context switch指令.
3. java的thread就是操统thread.
最后, 线程是有代价的. 特别是JVM这种stack machine上的线程, 每个都得有一个
stack.
线程多了内存占用会大. 而且程序的不稳定因素也会变多. 总体throughput提高的结果
可能
是每个请求响应时间变长, 而且响应时间长短不平衡加剧. 甚至schedule得不好会导致
CPU负载不均衡导致throughput也降低.
不是每秒处理上千个请求的服务, 根本犯不着上user-level thread.
每个请求都要去db转一转的服务, 基本上也犯不着上user-level thread, 因为一旦
扯上db, 速度都不会太快.
综上, 在安卓上用user-level thread我觉得没有实际意义.
欢迎反驳.
【在 t*****n 的大作中提到】
: 几个疑问：
: 1 java写的scheduler如何比OS native的performance好？
: 2 不靠底层汇编或机器码如何让java实现context switch？
: 3 他这套到底比java自己的thread实现强在何处？没看出来
|
g****t
发帖数: 31659 | 43 网上有go scheduler的design spec
不过那种东西都是学了穷三代
用户态线程上下文简单，不确定性少
所以肯定切换快
OS线程要覆盖的东西多
所以切换慢
倒不是算法的问题
OS要考虑和处理的不确定性多很多
但是如果用户太线程不是在非常限定的情况下用的化，
性能一定会下来。我没仔细看过，但是我感觉迟早会有
Good part of Go channels 之类的新宝书出现给
: 大家这么折腾, 主要原因是.
: 用户态线程切换比操统线程切换(都在同一个进程内)要快几百倍. 这个我
理解是
有两点
: .第一进出操统syscall本身比较慢. 第二linux的thread是偷懒版的
process,实
现比较
: 低效. windows线程据说比linux线程更慢. 但windows有fiber.
: 因为只有切换时才有速度差别, 所以一般用户态线程库的优势需要起大量
线程,
并且经常
: 切换才能体现出来. 这种情况发生最多的就是各种web服务器. 别的情况
基本没
这个需
: 求.
: *起大量线程*这个需求很大程度上是被用户态线程的拥趸为了benchmark
需要生
造出来
: 的.
: 所以答案是:
【在 w***g 的大作中提到】
: 大家这么折腾, 主要原因是.
: 用户态线程切换比操统线程切换(都在同一个进程内)要快几百倍. 这个我理解是有两点
: .第一进出操统syscall本身比较慢. 第二linux的thread是偷懒版的process,实现比较
: 低效. windows线程据说比linux线程更慢. 但windows有fiber.
: 因为只有切换时才有速度差别, 所以一般用户态线程库的优势需要起大量线程, 并且经常
: 切换才能体现出来. 这种情况发生最多的就是各种web服务器. 别的情况基本没这个需
: 求.
: *起大量线程*这个需求很大程度上是被用户态线程的拥趸为了benchmark需要生造出来
: 的.
: 所以答案是:
|
w***g
发帖数: 5958 | 44 10年前这个是显学. 现在风头过去了.
不过也还算基本知识.
,
【在 g****t 的大作中提到】
: 网上有go scheduler的design spec
: 不过那种东西都是学了穷三代
: 用户态线程上下文简单，不确定性少
: 所以肯定切换快
: OS线程要覆盖的东西多
: 所以切换慢
: 倒不是算法的问题
: OS要考虑和处理的不确定性多很多
: 但是如果用户太线程不是在非常限定的情况下用的化，
: 性能一定会下来。我没仔细看过，但是我感觉迟早会有
|
z****e
发帖数: 54598 | 45
其实这个东西很容易回答
我们只要它作出20分的成绩，至于它的目标是60分还是100分
不重要，重要的是20分就够用了，因为其他的40分有加成
考20分就过线了，但对于go来说，可能要60分才能过线
因为go没有加成，而我和其他看得懂的人说的就是有了这40分的加成之后，20分轻松过线
而你或者wdong说的，都是没有这个加成时候该怎么办
两回事，两回事，所以都是鸡同鸭讲
还在思考怎样从0出发去考及格，你们已经落后了
你们在用10年前的思考方式在思考这个问题
最后就变成了，别人说可以做到
你们不理解，就说，怎么可能？牛得不得了的人都没做到
blablabla，哎，vert.x+kotlin，你不服你自己去看看它是怎么做的咯
你不信你自己可以跑一下benchmark嘛，vert.x常年在techempower上排行靠前
你就没想过去看看为什么？去做这事比你在这里放空头炮要强很多吧？
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
我觉得嘛
我老是教育你，一来你也不爽，就算教育了你
你也不感激我的好，感激我曾经教会你东西
反而会记仇，记得我曾经怼过你，算了吧
何苦呢？
【在 g****t 的大作中提到】
: 你是不是没读stdio帖子里的那个email?
: 第一行就是讲要user mode thread
: 后面也讲了对scheduler的设计约束
: 新线程模型的设计约束
:
:
: 听得懂的人自然懂
:
: 甚至是秒懂
:
: 第一个回帖就会同意我的看法
:
: 听不懂的人，死活就是不懂
:
: 还在lock上纠结
|
z****e
发帖数: 54598 | 46
经常
停止这种无意义的blablabla吧？
我们上点能够测量的
我就这么说vert.x+java性能可以超过go，vert.x+kotlin应该也行
但是会略弱于vert.x+java，但是可读性会超过vert.x+java（现阶段）
其次vert.x&go不管在什么时候，都可以吊打其他任何一个同步api的系统
用异步或者协程肯定比同步快，快很多，尤其是在io bound的时候
再来，我们可以保证，用vert.x，可以把用户线程控制在很少量的几个上
具体是cpu available cores * 2
比如1core就是2个线程就够了
再来，在线程数有限的前提下，coroutine要做的事很少，就是suspend&resume
我相信go的coroutine要做的更多
木有错，所以go很有可能做得不好，所以性能比不过vert.x
说这些，都需要证据，不要没事blablabla，证据就在这里
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
我个人认为啊，vert.x和异步，再加上coroutine，基本上是到了极限
不用coroutine，更快，但是用了coroutine，也慢不了太多，官方给出的是3%-5%
是不是，你自己写个代码跑跑试试就知道了
这样做比go都快
具体benchmark看上面链接
其次coroutine有存在的意义，因为我们可以用这个机制来摆脱高阶函数
实现《去你妈的纯函数》
既然有人对此有意见，这说明这里有存在的空间，所以我们会采用这个东西
因为我们也觉得fp不好搞，所以愿意牺牲这3%-5%来保证更加优质的可读性
所以wdong，你要是不信，没有关系，你尝试着去做一个比vert.x更快的机制
然后将其实现，放到techempower上去测试，然后把源代码公开出来
让别人也验证一下，反正techempower也是公开的竞赛，你为啥不上去试试？
你要是不相信jvm上也能搞一个coroutine，而且比go更快
那为什么不试试呢？vert.x+kotlin，我已经告诉你会比go更快了
难道你不想知道这里面的奥妙？你曾经认为要牛得不得了的人才能做出来的东西
jetbrains做出来了，难道你不想去了解一下？
说到底就是别人怎么做的，你其实是不懂的，我又看了一遍
嗯，虽然你在故弄玄虚，但是应该还是不懂
在此之前，我们会选择vert.x，并开开心心滴抛弃fp那些东西，因为太难用了
为了抛弃fp，不惜换语言啊，连java都能换成kotlin啊，为啥？
就是不想用fp的高阶函数嘛，太难用了嘛
而对于java来说，要做的也很简单，就是抄kotlin咯
没有kotlin的coroutine之前，很多人就在用quasar了
但是有了coroutine之后，那kotlin的用户就变多了
那java感觉到了竞争的压力，所以也打算搞这么一个东西
至于能不能抄成，哈，抄都抄失败，这个好像难度也不小
【在 w***g 的大作中提到】
: 大家这么折腾, 主要原因是.
: 用户态线程切换比操统线程切换(都在同一个进程内)要快几百倍. 这个我理解是有两点
: .第一进出操统syscall本身比较慢. 第二linux的thread是偷懒版的process,实现比较
: 低效. windows线程据说比linux线程更慢. 但windows有fiber.
: 因为只有切换时才有速度差别, 所以一般用户态线程库的优势需要起大量线程, 并且经常
: 切换才能体现出来. 这种情况发生最多的就是各种web服务器. 别的情况基本没这个需
: 求.
: *起大量线程*这个需求很大程度上是被用户态线程的拥趸为了benchmark需要生造出来
: 的.
: 所以答案是:
|
s***o
发帖数: 2191 | 47 vert.x已经把multi-core的问题解决了，再用coroutine来解决callback hell还有各种
恶心的async问题，performance还不受影响。这个组合感觉会非常不错
【在 z****e 的大作中提到】
:
: 经常
: 停止这种无意义的blablabla吧？
: 我们上点能够测量的
: 我就这么说vert.x+java性能可以超过go，vert.x+kotlin应该也行
: 但是会略弱于vert.x+java，但是可读性会超过vert.x+java（现阶段）
: 其次vert.x&go不管在什么时候，都可以吊打其他任何一个同步api的系统
: 用异步或者协程肯定比同步快，快很多，尤其是在io bound的时候
: 再来，我们可以保证，用vert.x，可以把用户线程控制在很少量的几个上
: 具体是cpu available cores * 2
|
g****t
发帖数: 31659 | 48 你要有问题，可以尽管讨论。不要无缘无故一再的往人身上扯。
我从不跟人套这种近乎。
过线
【在 z****e 的大作中提到】
:
: 经常
: 停止这种无意义的blablabla吧？
: 我们上点能够测量的
: 我就这么说vert.x+java性能可以超过go，vert.x+kotlin应该也行
: 但是会略弱于vert.x+java，但是可读性会超过vert.x+java（现阶段）
: 其次vert.x&go不管在什么时候，都可以吊打其他任何一个同步api的系统
: 用异步或者协程肯定比同步快，快很多，尤其是在io bound的时候
: 再来，我们可以保证，用vert.x，可以把用户线程控制在很少量的几个上
: 具体是cpu available cores * 2
|
