@lujie2012 #20
@Leonard #26

屠龙技罢了，你学了 TCP 七层有个屁用，你又不是去 Google 搞 BBR，话说在协议栈锤炼的程序员有几个，行业分工决定了 99%的人 在封装好的黑盒上做应用，1%的人去从事基础技术体系的开发。

35 岁的问题从来不是人的问题，而是 IT 技术行业本身是一个不断降低自我门槛的行业，因为 IT 技术它是用来服务社会的，不是给你去搞研究跟底层开发的行业，你说我写个日常的记账软件，非得从你调度算法+TCP 协议栈开始搞起，那特么还搞个屁的开发。

不是有 B 哥吗？

@qwertyssp #14 我个人对二进制编译 可能认知是 C/C++这种直接展开成 IR，然后基本上可以将高级语言跟汇编直接对应起来的这种方式，但是 golang 并不是如此。

@qwertyssp #14

传统的线程池并发模型有一个缺点就是线程的开销太高，而且由操作系统掌控，另外线程由 CPU 的 ring3 权限切换到 ring0 权限，需要切换 MMU 的内存页表，可能还不能利用上 L0 L1 缓存，CPU L0 L1 主存之间分别读取数据的时间差距是指数级别的，这些也就是通常网上俗称的内核态切换开销，如果用一个线程专门去处理其它线程的 IO 调用，例如 epoll 关键字就可以大幅度降低 CPU 在内核态跟应用态的切换开销，而且原本因为系统调用而进入阻塞的线程 就不用再阻塞了，只要让其它的协程代码继续在这个线程上跑起来即可，这样可以节省很多开销。

@qwertyssp #14 另外虚拟机这个概念太笼统，因为 golang 并不是完全的按你写的代码去编译二进制代码的，中间会插入很多代码 作为运行时的 GC 还有 goroutine 用的，据我之前查的资料结合我对系统 IO 的理解，在应用层面实现协程，golang 是把所有同步系统调用接口全部在内部改成了异步实现了 这样就可以利用操作系统的 epoll 跟 select 调用 实现 IO 多路复用，这样可以使用较少的系统线程去实现 golang 语言层面的协程，因为在引用层面的协程调度，其实只有代码走到系统调用之后，就可以改变协程的状态，此时线程可以交给另外一个协程去 run，等 epoll 调用返回的时候，然后再使用调度器让之前触发系统调用的协程 run 起来就好了，这本身并不是一件很难的事情，在 c/c++里面都有类似的协程实现，但是头疼的是选择调度算法，像 Java 反正语言层面受限，所以干脆拿线程池死扛就是了。

@qwertyssp #14 有虚拟机的，内存回收 二进制系统 ABI 接口 都是靠虚拟机实现的，当然不是传统意义上的那种 运行时对代码进行编译成二进制的这种方式..

@MrTreasure #10 市面上高性能计算平台之间的 交叉编译就是个伪命题.. 交叉编译本来就是用来给低性能嵌入式设备编译二进制代码用的.. 如果你的目标设备 在市面上大面积都能买到，而且性能足够编译..那么何必在 linux 下编译 windows 的二进制包，在 windows 下编译 linux 的二进制包.. 不是脑子有病？而且现在云化 deploy 一个 linux macos windows 有这么难？

@Juszoe #8 不存在的，golang 2.0 之前貌似没有对体积优化的进度表，主要是这玩意设计的时候就没考虑过中国的嵌入式环境，另外中国嵌入式这个行业 又比较死脑筋 特别封闭，跟其它的 IT 技术圈子基本上没什么交流跟沟通，都 0202 年了，还在那里用死扣门的硬件+爷爷辈的技术 C/C++，实际上这两个东西除了高性能的底层部分需要，写应用层用这些简直就是浪费人的脑细胞，另一方面是出货量大的话，rom 小一点确实能节省不少钱，但是话又说回来了，用以前那套玩意搞，还不如用新的技术搞，招人也方便，不过以前搞嵌入式的人都占着茅坑，自然市场上的产品也是那老一套的思维，另外中国人力成本不值钱，其实硬件节省的那点钱根本算不了什么，用新技术 python golang java 来搞的话，从市面上招人能省很多钱，开发起来速度也快，但是奈何人力成本摆在那里，根本不算什么，所以死扣硬件还是能省出不少钱的，但是现在很多小公司做嵌入式硬件就开始慢慢用新技术 /硬件了，因为他们很多时候招不到合适的人，你要用 QT GTK 来画 UI，你可能环境还没搭好，人家这边用 vue+前端把活都干完了。

@Juszoe #2 go 的交叉？ 很多库都不是跨平台的.. go 目前应用比较广的就是服务端了.. 嵌入式环境由于硬件产业死脑筋，万年 4M ROM 的设备 + C 语言搞得飞起，go 交叉编译的 mips 版本 基本上就是个半残废.. 市面上大部分能买到的 mips 架构的路由器 rom 就没几个大到能装下 golang 虚拟机的

https://detail.tmall.com/item.htm?id=613171046888&spm=a1z09.2.0.0.2c392e8djLmUx4&_u=q3cnhvkca4d

戴了几天，还行，价格也很实惠，舒适度比原厂那就是一句话 好多啦

写这种代码的直接打死吧，service 所有变量的引用 只在栈上，调用完了 自动弹出 自然就不会被 GCRoot 引用，而且微服务也通常不需要将 引用部署到类的成员变量上面，这样的话 服务本身就是存在状态的，而通常服务都是要被设计成无状态，可以随时被替换 被重启的。

@0x11901 #5 主要还是 C++ 编译器太难实现了...

@cwr31 #25 服务端 基本上只要有钱就能加并行算力，无非是堆多少机器的问题，有些算法本来就不是可见的时间内能完成的那种运算与其搞新制程把核心频率搞上去，还不如发展量子计算机，手机端的算力在大部分场景也是够用的，除非你硬是要在这一小块屏幕上玩高清高特效游戏，目前很多手机也是能做得到的，无非是电池续航的问题，

算力跟游戏是一样的，你发现这些年，很多 3A 游戏虽然 Duang Duang Duang 但是很多玩家已经不怎么愿意买账了，就是因为游戏特效画面做得再好，缺乏游戏性跟可玩性，还是没法大卖，我觉得未来的游戏，应该是全 AI，所有剧情都是 AI 时间随机触发导向的，但目前强 AI 还是在画大饼。

@odi #2 其实技术发展到后面，已经没什么用了，现在已经是大部分场景算力过剩的时代了，当然你要把制程搞下去，把算力 /能耗 搞上来，感觉没什么必要，还是等电池技术突破吧..