Go团队对NUMA调度的最佳实践并不十分了解,也不确定实现后是否能带来预期的性能提升。此外,没有其他编程语言有明确的NUMA调度经验可供参考。
Go团队对IO_uring的支持表示怀疑,认为即使实现了也可能不会比现有的同步非阻塞IO方案性能更好。他们还担心这可能会打破Go网络编程的向后兼容性。
Go团队更倾向于解决80%的需求,倾向于做一些能够带来大量影响的事情,如PGO、泛型和并发GC。他们更倾向于将边边角角的事情留给社区来做。
Go团队目前更关注profiling、tracing等工具链的开发,以帮助开发者更好地分析程序的性能瓶颈。他们似乎没有特别大的愿景或计划在Runtime中进行大规模的变动。
Go在标准库中新增了一个结构化日志库,名为slog(structuring log),这是社区长期呼吁的结果,旨在提供更好的日志记录和调试支持。
Go团队可能更优先处理内部成员的proposal,外部开发者的proposal有时可能会被延迟处理或不被重视。这种区别对待在许多组织中都存在,但希望未来能有所缓解。
Andy最大的收获是看到了一个健康的开源社区如何运作,外部贡献者基于自身业务需求反哺上游,推动语言的发展。此外,他也意识到Go团队目前更倾向于做一些工具链的优化,而不是大规模的Runtime变动。
Go团队目前更倾向于做一些外围的工具链优化,如profiling和tracing,以帮助开发者更好地分析程序性能。他们可能没有特别大的愿景或计划在Runtime中进行大规模的变动。
Go团队在WebAssembly的支持上没有明确的结论,讨论主要集中在32位和64位的支持优化上,但最终没有达成明确的解决方案,留下了开放式的结局。
Go团队对IO_uring的支持表示怀疑,认为即使实现了也可能不会比现有的同步非阻塞IO方案性能更好。他们还担心这可能会打破Go网络编程的向后兼容性。
大家好,你正在收听的是由欧长坤和杨文组织的购页聊购页聊是一档主要针对购语言发展史的技术讨论节目我们的宗旨是让更多人了解购语言的发展历史和未来规划希望大家在这里可以了解到购语言的方方面面如果你觉得购页聊做得还不错欢迎你推荐给身边的朋友如果你对我们有任何意见或建议请给我们来信我们的邮箱地址是 hi.toco.fm 我是杨文
大家好我是欧长坤大家好叫我 Andy 就可以了欢迎 Andy 来参加我们的这个节目我们很高兴可以邀请到 AndyAndy 的话是有多款开演项目可能大家有一些已经知道了有 GoLite 然后有 Ants 然后也有 GoPost 那近期欧长坤和潘少受邀 Go 团队参加了 Go 贡献者峰会那接下来我们就有请两位给我们分享一下他们在这里的所见所闻欢迎
因为其实听动可能不知道就是我现在跟 Andy 其实是坐在一起原因是因为我们一起来美国参加了那个贡献者峰会
然后我们不妨简单聊一聊这次贡献者峰会上面我们都有哪些经历吧要不 Andy 你可以分享一下这次贡献者峰会参加的经历感觉如何可以啊我主要参加了两个圆桌吧第一个就是就是那个 web assembly 然后还有一个就是 go go 的那个 run time 的 performance 啊第一个的话第一个因为因为
第一个的话因为我之前并没有在其实没有给也没有相关的这方面的一些研究或者说一些贡献的经历我主要是比较感兴趣所以去听了一下这个主要是听一些大佬之间在讨论这个问题然后他们主要是在讨论说怎么
怎么更好地去在 Go 里面去支持这个 web assembly 因为那个时间其实也只有不到半小时吧我觉得,而是 25 分钟所以那个时间其实也蛮短所以他们大概也就讨论了一两个话题主要集中在现有的那个现有的 Go 的那个对这个 web assembly
他们主要讨论 32 位跟 64 位的支持因为他们在想的是后面怎么去更好支持 64 位的这种最后是在讨论说如果要做这个东西那 64 位的应该要怎么去优化后来就又陷入到编译器这边怎么来提供支持
因为编辑这边有就为了大佬 Kiss Randall 作证所以最后一直在讨论编辑编辑就是说怎么能不能到底后面能不能说是为了来支持你的 web assembly 的适不适合来做改造我听下来的话
我听下来的话,Keith Randall 他分享了很多说一开始 Go 的那个设计这个 Go 的编辑器现有的一些就是为什么它的实现是这样,导致的说现在不太好支持
这个后面去优化这个这个 go 的在这个 web assembly 的上面那些东西当然他有一些很 solid 的碰撵就是就是一些有有价值的一些观点吧就是说一开始以前在做的时候为什么要这么设计那那那那那确实是没有办法那但是后来讨论到最后其实也没有一个好的一个结果就是就是就最后就是他
讨论下来之后其实大家也没有给说后面怎么去真正的去去做其实是留了一个开放式的一个结局吧就是大家啊现有的问题列出来然后以后要做一些东西又会带来什么问题就把它放出来那大家都没有一个很明确的一个观点说或者说一个很成熟的一个想法说后面可以怎么去做那这个是第一场那第二场的话第二场因为我这边跟那个
欧博这边是是一起参加的就是那个 gold run time performance 相关那我主要是我写了两个 topic 一个是那个一个是一个已经已经停滞了大概有十年之久的那个 new 吗
NUMA Scheduler 就是 Non-Uniform Memory Assessed 就是在这种架构的硬件下的 Go 的 Scheduler 因为大家如果对 Go 的这个 Go Routine 的这个鞋层调度有一定了解的话就知道其实它 Talent Time 它有它自己的一套 Scheduler 就是有一个调度器嘛那从
在我记得应该是 14 年吧 14 年那个 14 年就是就是够他现在的这个这个这个调度器后来成型了成型了这个调度器的这个设计者啊就是
那个人啊那个人的名字名字我不太会读好像是一个德国人吧是不是是个俄罗斯哦是一个俄罗斯人就是他他让我看他看到好像后来在德国那边对他在慕尼黑现在对就是他他那个单词我未拼用
我也不知道怎么读就是非常厉害的一位大神因为他其实我记得他好像他也不是 GoTeam 里面的人对他是 tooling 团队的应该是在 core 下面给开发者做工序链子然后以及安全的一个然后他后来应该是进了 Google 但他也没有进入 GoTeam 但是他早期的时候就
就是给那个帮忙打杂对也不是打杂了他他他做的工作已经是已经是那个非常广泛的就是他的就是他做的那些工作就是这些和就像说就是这个掉落器的整个掉落器就是后来就是他设计的
包括引入 P 形成了 GPM schedule 最终整个形式其实就是他设计的他做了很多东西他 2014 年的时候大概就提出了 NUMA schedule 当时他在 Google Docs 上面给了一份 Design Doc 我很早之前就看过
但是他那一份 design doc 就不是特别完整就大概是有一个大概的一个轮廓大概的一个思路当然中间有很多那个问题他自己其实也没有也相当于是遗留了一些点吧他自己也没有也没有完全的说提出提出说很详细的解决方案或者说是放在哪但我一直对这个东西就比较感兴趣然后
因为我以前有接触过像是说比如说像一些基础的一些一些人一些软件比如说数据库软件对吧像是 MySQL 它其实比较有意思的是就是以前看到过有人反馈过 MySQL 相关的一些 bug 后来发现是因为是 NUMA 的机器然后就导致了它的一些
因为 Niwa 它相当于是做了隔离,相当于不同的盒子间,有自己的 Local Cache,然后不同的区之间通过这种特殊的总线去进行通信。
就像是这种架构然后在这种架构下我以前看过那个那个那个买色口是买色口还是那个还是其他的数据库就是那个的一个 bug 反正就是在在在在在这种在这种这种牛马的这种机器下面的一个问题那后来就是他这个数据库他就支持了他就他就支持了这种这种牛马的这种这种
这种架构下的所谓的他相当于说在这一层在底层去支持着他这种然后在这种架构下能够有更大的一个性能提升后来看到 go 的这个东西的时候我就一直很感兴趣所以我这次在美国的他们 contributor summit 里面就写了这个东西
那 Runtime 的现在的,就是这一次来的,就 Runtime 这边的人大概是两个主持人吧,然后两个 Michael,他们两个都叫 Michael。
然后他们就在说这个东西,因为首先他们说他们对这个东西其实也没有一个很明确的一个答案,说到底应该怎么去做,就是怎么在现有的这个 schedule 已经有了这个情况下怎么去改造,然后把它说所谓的去支持你网的那种结构,他们也没有一个很明很明确的一个答案,说怎么去做这个东西。
而且就我自己听下来的话反正他们就是说其实他们也不是特别了解也不是特别了解说这种 NUMA 的这种调度的最佳实践是什么
对吧他当时是说其实他也不是特别了解就是他也不知道而且更重要的是他也不知道做完之后到底是不是真的会有就是大家预想中的那种那种那种收益对吧很大的一个性能集成是不是呢那也不清楚那基于这几点原因的话他就觉得他们现在也没有去没有打算去做那后来有另外一位在圆桌上面的另外一位同学就提了说有没有其他语言
其他语言其他编程语言是做了这种东西的那好像在在在员座上的各位好像也没有人说有这方面的经验说很肯定的说哎哪门语言他做了这个东西我们可以参考对吧我们可以去去去借鉴那好像也大家也都大家也都没有也没有想到说有有没有有其他人支持的这个东西所以就是
这个就第一个搁置了反正最后也无疾而终就是说暂时没有计划第二个我写的就是 Linux 在最新的几个版本应该也不是特别新可能也是有一段时间就是 IO 方面的也是又是网络 IO 的东西就是 IO-Uring 的这种新技术就像是一部 IO
因为以前 Linux 平台上面其实严格来说它是没有 EboL 的有一个但是也就是 AsyncL 但那个东西我自己没有没用过因为我看到社区里很多人在吐槽这个东西基本上基本上
基本上基本上是不能用的或者说是各种体各种方面的体验都特别差这基本上也没什么人用就是所以另一个上严格来说没有真正的一部 IO 当然那个 windows 上是比较早就已经有那另一个上一直就没有因为可能本身他这个一炮都是这种同步非主测的 IO 也基本上也够用了
对大部分那个场景来说其实也是够用的那后来就 Linux 里面有一个大神我忘了他的名字了应该也是然后他他做了这个东西吧就这个 IOU link 然后就相当于说是真正使 Linux 拥有了这个平台拥有了 Linux 这个平台上面真正拥有了这个 Ebo I/O 的这个技术那因为这个东西呢
EVOIO 然后可能跟之前的那种同步非主色的那个这个这种 IO 模式又不太一样那 Go 它在不同的平台包括 Linux 或者是那个 BSD 平台或者其他的其他的那种类 UNIX 的这种平台上面它
它现在一整套的 Runtime 里面的网络 IO 的这套机制它以前其实都是基于同步非组色 IO 在做的就是用的是 EPO 然后 BSD 系统上面是
然后其他的这这种然后他现在是以前的基本上都是 gc 套做了啊因为我是我是之前看到那个 go 的那个 github issue 上面有一个有一个人他提提了一个 proposal 他是希望说后面可以
go 在那个 Runtime 上面能够无感知的把那个现有的这个 epal 替换成 Linux 最新的这个 EVIO 就是这个 IOU link 这样的话会有比较大的一个性能提升嘛那当时我看了一个事其实很多人参与了讨论像是那个 Ian 他发表了一个比较重要的一个观点是说
基于现有的 Go 的这个 Durantime 已有的这个架构其实很难改造很难把它改造成那个就是这种 EvoIO 而且他也他也表示怀疑说他也表示怀疑说基于 Go 现在这种架构就算把它改造成这个 IoUring 的这种 EvoIO 的这个模式他也表示怀疑说不一定会比现在的这个方案现有的这个方案会更好性能会更好
他表示了这个怀疑但是他也不确定因为没有人真正测过啊所以我当时看到这个然后我就提了这个东西然后就也跟 run 他们的人沟通我就想说啊因为我看那个那个应该也是有一段时间没有不是就没有人讨论了所以我在想就是他们团队现在还有没有在关注这个事情
所以想提出来跟他们聊一下然后他们也他们从他们的反应来说应该他们也是最近没有太关注这个事情当然他们也发表了他们的观点就是说大致跟 Ian 最早在 Github issue 上面回复的一样
他们也比较怀疑说这个东西做了之后是不是就真的会有比较大的性能牺牲他们也表示怀疑而且还有一个就是还有一个另一个也是一样的观点就是说现在很难改造就基于现有的架构就是现有的 runtime 上面的对网络连接的管理的这一套架构来说已经很难改这总体来说我提的这两个
我提第二个其实我主要是有点担心如果他们真的要做的话会不会打破那个向后兼容性就是够的网络编程的模式相当于说是像是这种每一个网络连接起一个 goal routine 去读写去管理
就相当于说是用同步的方式写异步的逻辑我有点担心他后面会不会说打破这样的一种一种网络编程模式在构成那这个不就听起来很像是最近正在聊的那个 corrultingcorrulting 就相当于是说你在用异步的逻辑来写同步的代码对吧 corrultingcorrulting 写成对
最近不是 Ruscox 在提 Iterator 吗他写了一篇博客说怎么样在 Go 里面实现 corroutine 后来当时在圆桌讨论的时候各团队还聊到说
可能要在运行时里面加一套单独的 coroutine 为什么还要再加那个 coroutine 它已经有了自己 coroutine 和 goroutine 不一样了那可能这里面有一些具体的细节我也不是很明白啊我还没有 coroutine 如果是写成的话那它确实不是 coroutine 因为 coroutine 现在早就不是写成它现在早就可以主动
主动是想这样的所以它早就不是携手就不需要自己有就就就拍手自己如果他要那个后听是说就是完全是协作式的那种那确实是不一样的东西对那你感觉这次参加这个多元的峰会最大的收获是什么
或者说你对整个社区有更深进一步的了解了通过参加这个风险者峰会见到了平时在网络上见到的网友对第一个就是比如说第一个参加那个那个那个
那个 web assembly 的那个那个那个原则讨论的时候我就见到了社区里面这个 web assembly 的这个这个应该说是组成吧因为他给他贡献了很多那个代码我见到了他然后听他发表了很多他这么多年来一直在做做这个的那个心得其实他也是基于这方面的那这个场景就是他们其实就是那个 js 要去用这个这个 web assembly 然后他们之前用的就是 go 去编译的这个
这个 web assembly 在用所以他就因为是他是基于他们这边的业务驱动线上的业务驱动所以他后来就成为了那个 go 的这边的这一块那个贡献了很多代码所以他也分享了他的一些他们自己的这个是这个 web assembly 这个让我看到的就是说其实还是有很多这种 web 贡献者
就是给购就是看起来也不像是无常在做的其实他们也有很他们也有自己的需求他们也有自己的那个现实的那个压力对吧现实的那个业务的压力他们现实的一些场景他们需要用所以他们才会去
反补对吧反补那个上游对吧反补回这个社区这是第一个第一个我是觉得说这确实是一个很健康的一个开源一个社区对吧他不是说完全是有那个说所有的需求或者购物要做什么东西完全是有勾听关在会议室去讨论
对吧他们自己或者说他们基于 Google 内部的一些需求 Google 内部的一些使用场景然后再来其实还是会有一些外部的需求去反过来影响 Go 这门语言的发展包括他们在原则会议在讨论上面后续要怎么去用话其实我听下来也是感觉他也是说因为他们想要的一些东西他们自己要的一些东西所以需要希望能够去做
那这个一听下来我就觉得可能就是这就是勾听跟那个外部贡献者之间这样的一种循环的一种交流第二个就是我自己提的这两个 topic 都没有得到一个我很满意的一个回复我现在觉得做的那个这个 Runtime 这一块感觉以及怎么说呢就是现在他们更偏向于去做那个
这个我之前跟欧博说过他们现在的更更更更更侧重的点可能是更更想更多的想放在那些 profiling 然后就是这种这种系统分析然后还有这种 tracing 就是这种这种追踪这种追踪然后可以让用户更好的去去去
去分析他们的那个程序的那个性能瓶颈就借助这个 Runtime 提供的这些提供这些工具链然后去做这些东西我现在是觉得我现在是觉得这个 Runtime 这一块蛮久没有一个特别他们一些特别大的一些变动
可能现在可能现在就是渐进式的渐进式的就一点点的优化一点点的去去做一些改造现在没有一个他们可能沟听这边也没有一个太大的愿景吧或者说有什么大的 idea 他们现在正准备在 run time 里面去搞可能现在更更侧重于一些外围的一些
像我刚刚说的就是这些 profiling 啊这些 tracing 啊这些东西都在做我有一个比较担心的一个点是虽然说 go 它它肯定不能和 csc++对吧和和那个 RAS 去竞争去 pk 这种这种 cpu 密集型的这种程序的这种性能但因为 go 我我有点注意到就是 go 在近年来的一些社区里面的一些声音可能就渐渐会讨论会吐槽到他的性能其实
就是一直没有一个特别大的一个进展就是性能在这个程序性能方面那实际上从购物它最开始一出来的时候其实最多就是
就实际上实际上他虽然一直提的是 C++但是实际上他是跟 Java 其实在竞争这个事那现在其实到现在 Java 这一块就是那个 JVMJVM 他就是这种就一直也在做然后像那个 JIT 这种实时优化其实 JVM 那边已经做的现在也越来越好
那么其实我是有一点担心如果就是 go 这边的话会不会就是在信用这一块就慢慢甚至就别说跟 CIA 比了因为其实一直也一直也就没有比过那就是说跟加瓦的这样的
这种就是这种带机器的这个语言会不会慢慢就会越来越落后那么 go 最最大亮点他们最希望他们最主要的原则就是还是说是这个编译速度编译速度这也是最开始为什么要创建这门语言的那个最大的动机那么这个优势就是说这个编译的这个速度编译的这个速度确实现在他们还是以这个为最核心的这个这个原则
就是你任何的那个变动都不能破这个原则所以导致有很多这种编细技术方面的一些编译优化的一些东西其实够都没有加那么
那么它最终确实是实现了这个编译速度是非常快的一个优势那么这个优势还能不能就是说后面能不能 cover 说你性能方面的那个落后这个我有点担心吧对我们可以从另外一个角度来看 Go 团队其实相当于也是 Google 内部的一个由 OKR 驱动的一个团队了
所以其实你如果仔细观察 Go 团队里面成员他们想要做什么样的事情其实可以发现他们更多的是倾向于去挖一个大坑去做一个能够带来一个大量影响的事情比方说早年的比方说现在的 PGO 也好或者说引入 Generics 也好或者是
定发 GC 也好啊这些都是一些比较大的贡献然后但是他们解决的主要他们解决的是一个 80%的需求然后最后 20%的编辑效应他们可能更倾向于把这些事情边边边角事情留给社区来做所以呃
所以这也是我觉得可能构团队他们并不会为了某一个特殊的场景来做一个非常大的努力这样一个原因吧然后另外一个观察是构团队目前可以明显的感觉到他们其实是在为企业服务
这里面其中一个很大的原因是因为 Go 团队目前是从 Cloud 的部门向移动到了 Core 的部门向
然后那那他们整个团队的 OKR 就变成从从了以前的支撑云的那个 OKR 变到了支撑开发者体验那支撑开发者体验一个很大的收益来源其实是 2B 的业务那他们要怎么样让这个语言能够变得更好的支持企业的需求那对标的语言明显就变成了加瓦的然后那所以他们做的一些边边角角像是什么 tracingprofiling 这些这
这些工具链方面的 volume ability 方面的这些全都是关于企业的一些需求这也是你可以明显感觉到为什么这几年 NGO 团队开始慢慢的转向做一些从社区的角度来讲可能不是那么 exciting 的一些 feature 对
好,那我们聊了确实有挺多的关于 Runtime,Go 的相关经历以及我们这次参加购物员贡献者峰会的一个比较详细的体验那这次参加完这个峰会之后呢我们就要回到
日常的工作工作工作岗位上去了那那我们最后来聊一聊你最近都在做些什么可以啊我最近其实还是有在为为购这边去去更新一些代码我最近一个在购物方面比较感兴趣的一个点是购物他新加了一个
新加了一个日志库,就是在标准库里面新加了一个日志库,就是 slog,也就是 structing log,然后就相当是结构化的一个日志库,这个也是千呼万唤使出来,对吧?这方面也是被吐槽很多年了,就像饭行等了 10 年然后才出来,像我们以前可能做用购的话,可能做业务系统,
就有一个很重要的避不开的一个地方就是日志这个日志其实相当于说在任何现在这种互联网的业务上其实它都是一个重重之重的一个地方包括你的后续的回溯问题回溯对吧然后或者是线上问题 debug 就这种它都是一个极其重要的一个东西所以像我的话肯定也关注了这种日志库子比较久
那 Go 以前呢就是以前的这种结构化的这种日志库基本上都是第三方基本上都是第三方可能大家以前用过的一些比如说像那个什么 LockRans 啊还有包括现在那个 Uber 开源的那个 Zap 可能大家用用的最多的都都这几个那以前用的都这几个那后来这个也是因为社区的需求啊然后
呼声一直很高啊就大家一直很希望说就是购的官方这边能够推出一个他们自己的一个结构化的一个日裤那现在是千呼万唤使出来了嘛现在就是他就已经推出了那我觉得这个对整个购的那个日制日制裤的这个生态啊会有一个比较大的一个影响后续的话当然我自己也没办法预测他具体的那个方向
后面的话我不知道这些第三方的这些日志库怎么继续发展然后包括购了它这个官方的这个结构化的这个日志库后面能不能说逐步的取代现在这些已经很主流的这种社区的这种第三方的这个日志库
当然我觉得这是一个很有意思的一个点因为这个时候推出这个日志库的话现在是把这个市场或者说把这个领域这个市场又给搅活了后面的话我还是比较乐意去看到会有一些新的东西出来因为日志这个东西的话其实还是很重要的就我前面提到所以后面的话还是希望就是会有一些很有意思的一些东西出来吧
或者说对开发者更有益的一些东西因为现在日资的一些使用基本上这个模式都固化了所以说希望后面会看后面会不会有一些新的进展会不会有一些新的变化新的东西出现所以我最近就在关注这个东西这是第一个第二个就是最近我还在做还是 Linux
的那个 IO 零拷贝的一些工作之前说的就是我之前已经帮他们做过一个了就是支持支持那个 TCP socket 和那个 unix socket 然后零拷贝到那个磁盘文件这两条路径已经帮他们实现了那我后来提了一个 proposal 吧就引入也就相对是需要引入
比如新的 API 去支持新的这种 IO0 口碑的路径 TCP socket 到 unit socket 还有磁盘文件到 unit socket 这两条路径这边的话其实方案代码都已经写完了然后也已经提上去了然后现在就想来说基本上差不多了包括一些性能测试的一些数据
然后包括就是 review 我代码的那个 go teamgo team 的成员就还是一眼还是一眼胚了他这边应该也没什么问题了但是现在就是可能要等这个 proposal 就是被最终接受吧因为 go 的这种 proposal 提 proposal 的这个流程就是他会有经过几个 stage 吧就几个阶段然后我就想了说一开始是讨论
讨论完之后如果大多数人都同意的话那就通过那通过之后就是开始正式的这个代码预订吧然后预备完之后就可以合入那现在他这个流程走了有点慢我是觉得他们现在这个流程也不是特别规范因为现在好像也没有一套很明确的一个标准说到底是哪些会先被就是哪些 proposer 会先被那个
扣团队先看因为我这个其实已经半年了半年多了半年多了其实一直以来就只有那个 EN Taylor 他一直在跟我讨论我一直在想说在问其他人要不要一起参与进来讨论这个东西大人都没有人都没有人鸟我这也是我最近发现的一个够的
反对他们这边的一个我觉得不太好的一个地方就是对这种外部开发者来说不太友好的地方就是总会有区就是会有一点区别对待就是他们对自己自己团队沟听里面的人的 proposal 会更快的被被 reveal 然后其他外部开发者的话
可能有时候会不太受重视当然这种区别对待我感觉可能也正常可能是任何一个组织任何一个公司可能都会有这样的一个问题但是我还是希望说能够慢慢缓解至少也不说解决我感觉可能也解决不了可能还是团队内的 proposal 可能会还是会被优先对待
但至少我还是希望是能缓解一下持续的关注然后就是持续的尝试吧对这就是我最近主要在做的事情
那今天我们的分享也将近两个小时然后非常感谢这个 Andy 还有长坤的参与和分享那在最后的话我们有一个环节就是说可以给大家分享一下你最近在读的书或说听的播客或说任何你想要分享的内容给大家先从 Andy 开始可以啊
对因为读书的话其实这个还是一个蛮好的一个话题因为我我还是尽量让自己有一个就是希望能够一直坚持下去的一个习惯就是说每隔一段时间都读一本就是在自己的那个领域之外的一些
可以拓宽你自己的思想眼界就像我最开始讲的我印象最深刻的那个贡献的时候其实就是从加瓦那边对吧最后是从加瓦西加加 C 那边的其他的地方反补到在 go 那边的贡献这让我就是有一个很
觉得很有意思的一个一个点就是这样就是你很多你无意中在做的事情其实看起来好像没什么用对吧那后面可能会
在某一天突然就对你的生活或者是对你的工作各个方面就可能会有一个比较积极的影响我最近在看我说的就是写这种世界历史的一套比较经典的一套书就相对说全世界无左无包了我觉得还蛮有意思我以前其实也没有全部看完
就是以前跳跳的看的很多就是找自己感兴趣的一些国家一些地区然后去看然后现在可能就想想重新说整整本重新读一下因为就就这几年嘛其实这个全球的那个变化还还挺大的就是各种各样的那个风云变动所以我觉得现在这个就是这个时机来重新看一下感觉感觉可能会有一点疲义吧
我个人的一个感觉然后还有就是比如说可以推荐大家看就那个追风筝的人我不知道大家有没有看过这本书好像就以前还蛮我那个怎么说呢因为我很早之前在高中的时候应该就看过但是很难有什么感触但我后来就是我最近其实也不是最近可能是几个月前了
就重新看完之后就有一些新的一些感触对这个亲情啊这里面讲的亲情啊还有友情啊还讲这种时代的变迁然后就是这种有一句话怎么说就是时代的一粒灰嘛然后落到一个人身上就是一座山这里面讲的其实就是讲的是苏联对吧然后苏联的入侵对那个阿富汗就主人公的这个他他们一家人的那个生活发生了天翻地覆的那个变化
然后这里面其实挺感慨的就包括里面还有战争嘛然后其实对然后现在其实世界上的那个局势也也蛮紧张然后其实大家都都很害怕其实现在看重新看这本书的话我感觉也有一些新的一些感觉就是这种时代时代的变迁然后然后对普通人的这种这种普通人的这种无力感吧然后还有就是战争战争对对对对这种家庭的摧残啊
还有对很多人的人生的这种改变所以我觉得可以推荐大家看一下接下来欧博我可以聊一个我最近读到的一篇散文然后因为我博士期间的一些研究主要是关于个体智慧的一个 decision making
然后最近从我博士毕业之后我开始在逐步的关注一些关于群体决策群体智慧的一些相关研究然后我最近读到一篇 asset 是叫做 open decision making
这个可以在网上能够在 Google 上面能够直接能够收到的第一个结果就是它里面提到一个很有意思的观点是说怎么样在一个组织内部实现最优决策然后这里面其中有好几个比较重要的条件其中一个就是在参与决策的人当中大家需要有共同的目标然后以及信息必须要公开透明
然后如果能够实现这两个基本前提的话大部分情况下如果一群在一起讨论的人他们都是聪明人的话那么很快就能够达到一个最优角色这个是我读这篇 assay 的
得到了一个我觉得比较相对来说比较新颖的一个观点对于我来说比较新颖可能在可能在组织实践当中可能会这个这个结论不是那么的 surprise 然后但是但是我觉得比较就是还觉得比较
比较难得的一点是这篇文章里面还提到一个很有意思的点就是说实现最优决策在一个组织内部实现一个最优决策并不一定是需要做 open decision making 也就是说你需要做到信息全部的公开透明需要做到大家的目标一致不一定然后如果在一个组织内部它是独裁的那么它也是可以能够实现一个最优决策的
当然实现这一个最优决策的前提在独裁的情况下那么这个独裁者一定是需要永远是对的否则的话那他处置下面的人其实是可能很难去信服他的一个决策然后所以他那篇文章里面提到的观点是说如果一个组织他需要建立一个独裁体制的话那么他肯定需要培养员工的一个或者培养组织内部人员的一个信仰
然后能让大家盲目的去相信这个人的决策始终是最优的那么最后他们做执行的时候并不会去
问他质疑太多关于某个决策的正确与否而相相对于来说落实到执行上面那么事情总是还会还是会被能够执行出来的啊这个是我我最近读到一篇对我来说比较有启发的一篇文章吧如果大家感兴趣的话可以去读一读看看 OK 好的呃
我这边的话就是分享一下我之前看完的一本书可能有很多人已经看过了然后我这边也是非常推荐的就是叫 UNIX 传奇对然后是克林汉写的一本书
然后这本书其实看过的都知道整个优历史的一个传奇也可以看得到我们整个计算机发展史的一个蓬勃发展的一个过程我是觉得在这里面就是有讲到李奇和 Kinnemans 我觉得他们真的是太伟大牛人为什么是牛人是因为他们身边全都是牛人在贝尔实验室的时候
因为跟牛人之间他们技术大神包括刚刚 Andy 也有提到这些大佬们其实他们还是真的是专心在技术上面其实没有一些其他的一些
多多少少的这些东西然后我们看传奇这本书的话其实也有这样一个感受牛轮跟牛轮之间的话也不会去真正去烦心某一些事情而很沉得下心这本书其实从一开始去讲然后到后面的话百发奇幻百家证明的感觉非常的好我觉得就是基础的一个发展到
讲到我们包括我们现在所感受到的这一切的话觉得就是去读这本书的时候就能够让自己带入到那样一个氛围和感觉里面然后能感受到
这个技术从零到一和到现在这样一个演进的过程我觉得这本书非常值得推荐大家去看一看我可以再补充两个功极劲像是千亿千寻在看他的东西我发现就是这种作品在你十几岁的时候看跟你现在这个年龄阶段来看的时候
就发现都会有很大的不一样的那个题还有推荐一部我个人就是非常非常喜欢的当然不是那个不是龚启峻导演的是他写的那个剧本但是不是他导演也是我很喜欢的一部叫做《侧耳倾听》可能这一部不是特别有名就是稍微小众一点不一定有很多人看过所以
就想推荐给给大家去看一下他讲的就是就是这两个年轻人吧然后他们一开始就是怀揣着各种各样的梦想野心然后对自己是对自己是是是极度的自信就是他们以为自己在这个世界上是特殊的他们觉得自己是特殊了他们觉得自己是
天也也不能天才就是他们觉得自己是很有才华的人然后觉得他们的未来一定是光明的然后他们的未来一定是波澜壮阔的是怎么怎么样就是反正他们是以为自己在这个世界上应该是特殊就不是不是平凡人但后来真正当他们开始去去去进入到现实世界去真正去做这些事情的时候他们他们渐渐的认识到一个事实就是自己不是
自己在这个世界上其实并不特殊他们只只不过是千千万万人普通人中的一个两个并没有什么特殊的那这个很很吸引我的地方就是他表现的这种无力感就是就是他就当他们发现这个事实的时候这种窒息感这种无力感但是
但是他们又怎么说呢最终他们一个很重要的一个点就是最终他们跟自己和解这其实是我自己的一个我自己的一个很有感悟的一个观念就是人好像就是在成长在成长过程中其实你是不断地跟
不断的跟自己和解的一个过程对吧因为因为我还是觉得可能我们大多数人都还是普通人就是部分我们
就就像我说的就是我喜欢看这种历史上面的那种说这种各种帝王将相对吧然后就包括刚刚那个杨文这边说的说他看那个用那个传记码里面各个都是大佬各个都是天才那他们的人生太精彩了对吧太精彩了他们的他们的事业他们的事业太璀璨了那这样你后来就是将来说房呃就当当当当我们看反观我们自己的那个
我们自己的这个这个人生的时候其实就是可能就会有这样的一种一种一种不太积极的这种情绪但所以我看那个电影的时候就是这个侧耳倾听所以我我为什么非常喜欢其实这个词呃
也为什么这就是一定要推荐大家去看的就是大家有有有有兴趣啊有有兴趣可以去看一下就是就是他知道了这自己在这个在这个世界上就是并不并不特殊就他在这个世界上并没有他一个他不是一个很闪亮很闪亮的一个一个发光的一个对吧一个人或者说是一个一个点那这种无力感这种这种窒息感那后来
但是你总要去面对对吧你总要去去总要去和解所以他这个电影就讲讲这个主题最后他们就是说他们他们就成功的和和和过去的自己和解然后他们就是说找到了自己在这个世界上的位置找到了他们能够做的事情就是他们可能没有办法说并不像他们期待的以前想象中的那样
是那么的垂胆夺目那么的那个波涛汹涌他们的人生那但是他们最终也找到了自己可以做的事情找到了什么方式去参与到这个世界里面去这个我觉得是特别好就是非常的至于吧我觉得就是会就是现在因为大家都很焦虑嘛就是所以我很希望就是说因为我看完之后我很早的时候
很早的时候其实就看过了所以就是我那时候就特别震撼因为我没有看过这种类型的这种这种动画这种动画电影因为可能以前看的都是什么科幻啊玄幻啊就是特别特别光怪陆离的特别有视觉冲击的那种但看到这种就是娓娓道来的讲讲这样一个故事的时候我就特别特别特别震撼就是小时候可能就是你也会有这样的思想就觉得自己是特殊的自己是天才对吧自己是
中间有不平凡的一生对其实每个人都会平凡但是你小时候你会幻想自己就会成为一个就像这种会有这种波澜转阔的一个经历对吧波澜转阔的一个人生
那最后其实你慢慢成长的过程中,其实你就要找到一种方式和过去的自己进行那个和解,因为整个发展就是其实就跟你以前想就不一样,对吧?对对对,我确实说的很对。对,所以所以就是说我,所以这中间可能就是说我们需要不断的读书,不断的学习,不断去看,然后就能够
让自己可以跟过去的自己和解因为如果你一旦不能和解对吧一旦的抗拒一旦的去逃避那这样的话可能会是一种不太好的一种情绪那这样对你自己可能也会有一个不太好的意义
所以我是比较建议的希望大家如果有时间有兴趣可以去看一看觉得是非常好非常好的一部电影谢谢谢谢大家的推荐和想要跟大家说的话今天这期节目应该是有史以来时间最长的了非常非常的有内容然后也非常开心可以跟两位去聊一聊对我们今天这一期就到这里感谢大家好
好谢谢拜拜