水木社区手机版
- 主题:协程或线程库好写吗？
- 我看你的切换部分保存 FPU 状态。
听说调用函数时没必要保存 FPU 状态，是不是可以优化一下？
【 在 pfan117 (pfan117) 的大作中提到: 】
: 凑热闹，我搞过一个：
: https://gitee.com/pfan117/libmco
:
: ...................
--
FROM 117.24.206.* - 我老老实实地把 boost::context 的汇编抄过来。哈哈。
https://github.com/hgoldfish/qtnetworkng/tree/master/src/context/asm
可惜不支持龙芯，哪位大神去 boost 里面贡献一下吧。
【 在 javaboy (喝了咖啡就话多-_-;) 的大作中提到: 】
: #ifdef __x86_64__
: #else
: #error "platform no support yet"
: ...................
--
FROM 117.24.206.* - 还不如用 python + gevent，或者 asyncio 标准库。
【 在 billybear04 (billybear04) 的大作中提到: 】
: 我觉得不如干脆搞语言算了。Lua我想学，不知有没有lua+llvm，当然这个估计很大，但是可以先搞个crl - co routine language, 突出重点。:-)
--
FROM 117.24.206.* - 好几年积累下来的。一开始只是想做个简单的协程网络库，预计两三千行可以搞定，结果越搞越大。里面有好些部分对我的工作有用，能够提高生产效率。
1. libressl 的轻量包装原本是独立的项目，用于解决 java 加密库太矬的问题。
2. kcp 原本是想一个应用搞网络加速用，发现国内网络没效果。这个部分花了我很多时间，纯粹给自己用。反正已经做出来，就放进来了。
3. 有个 DataChannel 是山寨 QUIC，是我十年前 java 和 python 版本改过来的。
4. http client 原本也是没有的，直到我再次被 c++ 的各种 http client 库给恶心到。
有些事真是不去做就永远没有，比如我觉得合格的 http client 至少得有自动探测执行 redirect 、管理 session 的能力和支持 proxy 三个能力吧，太多库缺失这三项里面的一项了。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 我不太明白干嘛要去做这个轮子。
: 初中的时候我倒是挺喜欢折腾这些的...
--
FROM 117.24.206.* - 高性能 web server 当然不好搞。但大家经常需要做个 API 服务器什么的，嵌入一个免配置的 web server 很好用。python/java/nodejs 都会实现自己的 web server，作为应用服务器就是同样的道理。
【 在 billybear04 (billybear04) 的大作中提到: 】
: 我觉得新的Web server不好搞，因为我刚刚搜了下：
: Tengine是由淘宝网发起的Web服务器项目。它在Nginx的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。
: 它也没有从头开始写啊。
: ...................
--
FROM 117.24.206.* - libcurl 确实很完善，上面说的三个功能都能做到。就是得自己组装 query 什么的，以及要多写很多代码。
能用 libcurl 还是用 libcurl 吧，qtng 只是占个 API 简洁的便宜，不支持 HTTP2/HTTP3 什么的还是比较弱。http client 原本确实不该做出来，包装一下 libcurl 就好。
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: libcurl不好用么？
--
FROM 117.24.206.* - qtng 最早确实大半出于目的1而制作，原本只是为了让自己写 c++ 长连接服务端程序方便一些。后来又应用于几个桌面项目。确实啊，花费在这个项目里面的时间，已经比帮我节省的时间多多了。从这方面看，这个项目对我是得不偿失的。
不过从这个项目里面也学到了很多东西，至少我现在说我对网络底层有些了解，大家不会嘲笑我吧。我长期做一些跟网络有关的事情，早晚要补这个课的，不浪费在写 qtng 上面，就得浪费在 debug 上面。
核心之外的 http client, kcp 这些部分，我确实太浪费时间了，以后应该不会再投入太多。但核心部分，我敢说还是有价值的，哪天大家需要 c++ 协程网络库的时候，一看，我这个好用，那也不错对吧。
这个项目好像是在本版一次“大家想在今年做点什么”的活动中，我立下的flag. 好奇当时立 flag 的有几个人跟我一样完成了哈哈。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 做东西无非是三个目的。1、要么自己用的爽，2、要么寻找建功立业的机会，3、要
: 么就是好玩挖个坑然后不管了。
: 感觉你这些目标都在1，当然我以前也一样...就你说的这些事情大概15年前我基本
: ...................
--
FROM 117.24.206.* - 你这个说法我不太认同啊。。
我觉得只是个人所能控制的软件项目现在已经不多了，所以让你有一种软件技术已经没什么好搞的错觉。但如果能聚集起大批的开发者，我觉得有很多技术可以做，随便举几个例子：
1. 通用的编译型编程语言，生态位重合 java/c++/python/go. 候选有 kotlin-native 和 swift，不过似乎还是不够，这俩有各自的问题。julia 语言也有很多坑位要去填。不管我说的对不对，编程语言的发展还没到尽头，还有很长的路可以走。
2. 通用的实时操作系统。因为现在 CPU、内存、存储都已经很丰富了，估计在十年后会变得更丰富，已经完全能够负担起实时操作系统的开销。比如 CPU 有 128 核，拿 20 个核出来以最低频率功耗 100% load 专门处理键盘、音频、视频、IO可以吧。低延迟的系统对于手机尤其有用。所以 google 和 huawei 都打算抛弃 linux 内核重新基于实时微内核做手机操作系统，我觉得很有道理。
3. 更简单的并行计算。一是把 vulkan 的坑填起来，二是能够结合通用型编程语言，更简单地应用并行编程。现在只把编译技术应用在编译成native代码，其实是不够的。完全可以把网络上的每个节点看作是一个虚拟 CPU，应用编译技术把程序代码编译到这个分布式平台上运行是吧。这时编译出来的不再是汇编代码，而是 hadoop 指令与代码、pytorch 代码等等。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 基本上软件领域也没多少我没碰过的东西了，所以我现在写软件写的也少。最近爱上
: 了rust，正在折腾rust embedded，目前在折腾把gui塞进64K rom，8K ram的mcu里
: 面。
: ...................
--
FROM 112.47.122.* - 通用实时操作系统这个事不是 MCU 那么简单的。首先网络IO和视频都是重IO，非强大 CPU /GPU 没法处理。还有为什么 PC 发展到现在，游戏帧率不如游戏主机稳定呢。android 的游戏，无论怎么优化帧率都没办法做到像果子那么流畅稳定。这些当然不止是软件问题，但我觉得软件因素比较重大。
AI 语言翻译机太过于魔幻，你是认真的？
我举的几个例子都过于宏大，那小领域也有很多需要技术进步的地方啊。比如自动驾驶，直觉上这是一个正确的方向，但现在做不好。无人机快递也是一个正确的方向，也没做好。这些领域，可能只需要五个牛人加上车库就搞定了，可惜现在还没有出现呢。游戏开发者因为渠道被把控，也一直想要搞像以前的WEB页游一样方便推广与运行的H5引擎，可惜受限于国内的技术水平，也一直没搞出来。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 标 题: Re: 协程或线程库好写吗？
: 发信站: 水木社区 (Wed Jun 10 21:22:00 2020), 站内
:
: 能聚集起大批开发者那能干的事情太多了，你这个设想没啥意义。
: 叫我说能聚集起大批开发者那我就成立个中国版的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 语言也有很多坑
: 位要去填。不管我说的对不对，编程语言的发展还没到尽头，还有很长的路可以
: 走。
: : ...................
:
: --
:
: ※ 来源:·水木社区 http://newsmth.net·[FROM: 180.109.235.*]
--
FROM 112.47.122.* - gpt-3 我了解了一下，实在看不出有什么激动人心的东东啊。参数数量的巨大增长，带来的效率增长却微乎其微，让我想起巨大的飞艇。是否这个方向已经进入死胡同？
AI 本质是不太精确的统计学，求局部最优解。与编程语言的应用是不一样的，因为编程语言表述的是数学的推理行为，要求精确。我觉得有生之年看不到 AI 能代替编程语言。在我看来，编程语言是比数学更基础的表述语言，能用编程语言来描述 AI，不能反过来用 AI 来描述编程。我甚至怀疑，使用编程语言来重构数学体系，说不定能带来意外的收获。
x86/arm 因为是通用 CPU，所以实时性确实没法跟特殊设计的 CPU 相比。但是我觉得在民用领域应该是足够了。Android 的屏幕正在普及 120hz/144hz，问题是游戏帧率不稳定啊。底层不实时，一个网络IO或者磁盘IO很容易地就阻碍了游戏帧的输出。iOS 改自 bsd 的非实时内核，恐怕也非好榜样。
芯片制程接近物理极限，单核 IPC 难以提升，晶体管向三维增长，核心规模不断翻倍，这是全新的挑战。软件也该跟上了。
【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: 你可以去了解下GPT-3，看看一个语言模型现在能做些什么事情。
: 游戏主机的体系结构是特殊设计的，当年我给cell处理器写代码的时候可是被折腾的够
: 呛好不。近年开始用x86了，但那也不等于pc啊。
: ...................
--
FROM 112.47.122.*