我不太明白干嘛要去做这个轮子。
初中的时候我倒是挺喜欢折腾这些的...

【 在 hgoldfish 的大作中提到: 】
: 协程切换分为三步：1. 保存当前协程的寄存器 2. longjmp 3. 恢复目标协程的寄存器
: longjmp 只是其中一步，所以不能简单地用于实现协程。
: swapcontext() 是 unix 通用(但android不实现)，但问题是会陷入内核，效率不高。SwitchToFiber() 不清楚，Windows 接近微内核，估计 SwitchToFiber() 不会陷入内核。
: ...................
--
FROM 49.94.92.*

不是嘲笑，我一直是相当鼓励不断深入底层的。
但事情要两方面看，深入底层熟悉细节很重要，但也不用太纠结底层的事情花费过
多的精力，除非你的目标是要在这方面建功立业。

所以我更喜欢看到好玩就挖坑然后弃坑，以拓宽自己知识的疆域为目标，而不是一
定要做个什么东西出来。毕竟什么年龄做什么事情，我初中的时候轮了个gui库在当
时可能很有价值，现在再去轮这个就没啥意义了。

【 在 hgoldfish (老鱼) 的大作中提到: 】
: qtng 最早确实大半出于目的1而制作，原本只是为了让自己写 c++ 长连接服务端
程序方便一些。后来又应用于几个桌面项目。确实啊，花费在这个项目里面的时
间，已经比帮我节省的时间多多了。从这方面看，这个项目对我是得不偿失的。
: 不过从这个项目里面也学到了很多东西，至少我现在说我对网络底层有些了解，
大家不会嘲笑我吧。我长期做一些跟网络有关的事情，早晚要补这个课的，不浪费
在写 qtng 上面，就得浪费在 debug 上面。
: 核心之外的 http client, kcp 这些部分，我确实太浪费时间了，以后应该不会
再投入太多。但核心部分，我敢说还是有价值的，哪天大家需要 c++ 协程网络库的
时候，一看，我这个好用，那也不错对吧。
: ...................
--
FROM 180.109.235.*

能聚集起大批开发者那能干的事情太多了，你这个设想没啥意义。
叫我说能聚集起大批开发者那我就成立个中国版的spacex跟musk竞争去了，who
care这些无聊的细节。

比如为啥一定要一个语言打天下啊？现在这样不挺好的。整个ai语言翻译器实现各
语言转换不更general嘛。

至于实时操作系统，讲真瓶颈不在os这里，而是在x86系统体系上。而且你cpu都128
core了，那我丢128个mcu，每颗mcu 5块钱只干一件事情，不比你这个简单方便实时
性还高的多？

并行计算这个也可以靠ai级的语言翻译器搞定嘛。

而且你这几个目标都是乌托邦级的，基本就是个“我全都要”的大而全思路。这套
思想本身就不是终极哲学，为啥就一定要往这个方向走呢？

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你这个说法我不太认同啊。。
: 我觉得只是个人所能控制的软件项目现在已经不多了，所以让你有一种软件技术
已经没什么好搞的错觉。但如果能聚集起大批的开发者，我觉得有很多技术可以
做，随便举几个例子：
: 1. 通用的编译型编程语言，生态位重合 java/c++/python/go. 候选有 kotlin-
native 和 swift，不过似乎还是不够，这俩有各自的问题。julia 语言也有很多坑
位要去填。不管我说的对不对，编程语言的发展还没到尽头，还有很长的路可以
走。
: ...................
--
FROM 180.109.235.*

你可以去了解下GPT-3，看看一个语言模型现在能做些什么事情。

游戏主机的体系结构是特殊设计的，当年我给cell处理器写代码的时候可是被折腾的够
呛好不。近年开始用x86了，但那也不等于pc啊。

早年android流畅性不如水果的问题只是个路线倾向性选择而已。你觉得这是一个问题，
其实不是，或者说android有更重要的问题需要解决。类似的水果早期功能缺陷也非常
多，两者只是初期道路选择的不同，现在也殊途同归了，android都在推120fps了好不
好。

总之你说的这几个问题的解决需要对整个体系结构有完整的认识。x86是为了throughput
目标设计的，latency和throughput永远是鱼和熊掌不可兼得的。并不是一句简单地软件
问题就能解决。我就说一个实际的例子，工控领域有无数人试图用x86来做运动控制器，
但所有的x86方案的运控都是低端货。

至于下面小领域...自动驾驶这不是小领域...而且你说的这几个事情统统是光靠软件解
决不好的。这也是为啥我很早就跳出了软件领域。

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 通用实时操作系统这个事不是 MCU 那么简单的。首先网络IO和视频都是重IO，非强大
CPU /GPU 没法处理。还有为什么 PC 发展到现在，游戏帧率不如游戏主机稳定呢。
android 的游戏，无论怎么优化帧率都没办法做到像果子那么流畅稳定。这些当然不止
是软件问题，但我觉得软件因素比较重大。
: AI 语言翻译机太过于魔幻，你是认真的？
: 我举的几个例子都过于宏大，那小领域也有很多需要技术进步的地方啊。比如自动驾
驶，直觉上这是一个正确的方向，但现在做不好。无人机快递也是一个正确的方向，也
没做好。这些领域，可能只需要五个牛人加上车库就搞定了，可惜现在还没有出现呢。
游戏开发者因为渠道被把控，也一直想要搞像以前的WEB页游一样方便推广与运行的H5引
擎，可惜受限于国内的技术水平，也一直没搞出来。
--
修改:lvsoft FROM 180.109.235.*
FROM 180.109.235.*

你这个视野就不对，事物是讲究量变和质变的，两者相辅相成缺一不可。

GPT-3表面上看是堆钱，实质上是一种让AI规模看齐人脑的尝试。当然目前GPT-3依然距
离人脑的规模很远，但起码这次玩的足够的大。

什么地方激动人心？那是你没仔细看吧。作为一个语言模型，它不只是单纯给写写故事
造造句子，它可以回答一些没见过的数学问题。看看这些它生成的内容，里面它甚至还
生成了代码。
https://raw.githubusercontent.com/openai/gpt-3/master/175b_samples.jsonl

当然，目前这些都做的不够完美，只能从中一瞥似乎有一点智慧的感觉而已。目前也说
不清楚这些令人惊讶的结果是它记住了还是它真的具备理解能力了。但至少GPT-3通过暴
力提升规模的方式，在不需要fine tuning的前提下，确实的在几个领域上超越了目前最
好的成果。之前的成果你可以说都是调出来的，这次就不能这么说了。我觉得这就是质
变。也许规模大到一定程度确实就是这样，如同人脑并没有人来给你调参一样。

至于参数规模，别为这个巨大增长而担心，cell处理器的故事是把15年前的top500级超
级计算机塞进一颗指甲大的芯片。ai领域类脑计算我认为也会有类似的故事的。

至于你这个ai不精确的描述，其实人都是不精确的，但并不阻碍千千万万个人都活的很
好，甚至说不定还可以认为这是一种自由意志的表现。精确那是计算机太过于擅长的事
情，对这个说法不太感兴趣了。

你说的游戏的实时性其实也没啥意义。游戏领域100fps也就是每帧10ms而已，linux-rt
我自己达到的最好结果是可以做到最大4us延迟的实时性。但在工控领域4us还不够好，
只是250Khz频率而已。mcu是很容易达到几百ns的latency的，交互频率达到MHz级别并不
难。游戏领域更大的问题还是要处理的问题规模比较的大，但区区100Hz级的频率真心轮
不到谈“实时”两个字。

【 在 hgoldfish (老鱼) 的大作中提到: 】
: gpt-3 我了解了一下，实在看不出有什么激动人心的东东啊。参数数量的巨大增长，
带来的效率增长却微乎其微，让我想起巨大的飞艇。是否这个方向已经进入死胡同？
: AI 本质是不太精确的统计学，求局部最优解。与编程语言的应用是不一样的，因为编
程语言表述的是数学的推理行为，要求精确。我觉得有生之年看不到 AI 能代替编程语
言。在我看来，编程语言是比数学更基础的表述语言，能用编程语言来描述 AI，不能反
过来用 AI 来描述编程。我甚至怀疑，使用编程语言来重构数学体系，说不定能带来意
外的收获。
: x86/arm 因为是通用 CPU，所以实时性确实没法跟特殊设计的 CPU 相比。但是我觉得
在民用领域应该是足够了。Android 的屏幕正在普及 120hz/144hz，问题是游戏帧率不
稳定啊。底层不实时，一个网络IO或者磁盘IO很容易地就阻碍了游戏帧的输出。iOS 改
自 bsd 的非实时内核，恐怕也非好榜样。
: ...................
--
修改:lvsoft FROM 180.109.235.*
FROM 180.109.235.*