ARTICLE DETAIL

资讯详情

深耕网站视觉设计与运营推广的一线实战洞察。

异数OS DS-V4相关问题的造谣纠偏总结和评价

异数OS DS-V4相关问题的造谣纠偏总结和评价 异数OS DS-V4 相关问题的造谣纠偏总结和评价文章目录异数OS DS-V4 相关问题的造谣纠偏总结和评价无开源代码‌GitHub、Gitee均无公开仓库无可运行版本‌所有性能数据来自博客截图无法被第三方复现无商业实体‌无公司注册、无融资记录、无团队成员公开OLTP引擎缺失‌OLTP在线事务处理数据库引擎需具备事务ACID、并发控制、日志恢复、索引优化等核心模块而异数OS 的全部公开材料中‌从未提及事务管理、锁机制、存储引擎、SQL解析器或任何数据库相关组件‌。无工程基础‌该系统连基础的内核实现都不存在遑论构建在操作系统之上的数据库引擎。所谓“4Tbps吞吐”“300ns延迟”均为作者在博客中模拟的理论值‌非真实硬件测试结果‌更无法支撑数据库事务的稳定运行。一、架构设计层面的挑战二、工程实现层面的挑战四、风险与争议层面技术叙事存疑DS-V4 的AI 评估结论Grok的评价Grok评价反馈无开源代码‌GitHub、Gitee均无公开仓库闭源项目当然无仓库未来如果有外围生态有必要可以开源但操作系统内核与OLTP引擎本身不会开源无可运行版本‌所有性能数据来自博客截图无法被第三方复现有可运行版本但因为没有产品化落地第三方当然无法拿到可运行版本但这不代表博客中的截图都是捏造如果你是资本方是可以拿到可运行版本。无商业实体‌无公司注册、无融资记录、无团队成员公开异数OS软著挂靠在四川墨道科技没有经营没有团队融资等但不代表技术造假如果你拿着钱过来我不介意用实际Demo数据让你了解到你想了解的一切。‌无第三方认证‌未参与TPC-C、TPC-H等任何权威基准测试异数OS的OLTP引擎主要用于元宇宙场景产品未落地也没有sql AP等功能但不妨碍借鉴tpmC的应用场景来做性能测试分析。‌无市场存在‌零客户、零营收、零市场份额元宇宙由于1998年服务器操作系统理论约束业内停滞30年按照梅特卡夫定律的期待是2048年落地不过按照30年0进展这个速度计算2048年的时候可能要让业内继续失望了零客户、零营收、零市场份额是真的就是做个愿景。OLTP引擎缺失‌OLTP在线事务处理数据库引擎需具备事务ACID、并发控制、日志恢复、索引优化等核心模块而异数OS 的全部公开材料中‌从未提及事务管理、锁机制、存储引擎、SQL解析器或任何数据库相关组件‌。事务ACID、并发控制 是在异数OS 老子罗盘中间件中完成无锁化并发异数OS 元宇宙OLTP引擎作为老子罗盘中间件的流水线已经不需要再关心事务的ACID、并发控制锁等问题作为元宇宙低成本高性能OLTP暂时确实不提供日志恢复等能力这是因为日志确实存在着成本约束问题存储引擎在文中已介绍基于LRU 和 内联事务线程自主控制等两种存储策略SQL解析器目前没有只有一个事务虚拟机不做AP的情况下手撸事务虚拟机问题不大缺失的东西确实很多但不妨碍这项技术用来完成元宇宙低成本高性能OLTP的目标而业界30年对此目标一无所知或者讳莫如深主要是因为在1998年操作系统基础理论约束下心虚的表现。无工程基础‌该系统连基础的内核实现都不存在遑论构建在操作系统之上的数据库引擎。所谓“4Tbps吞吐”“300ns延迟”均为作者在博客中模拟的理论值‌非真实硬件测试结果‌更无法支撑数据库事务的稳定运行。纯属猜测4Tbps 300ns的性能数据应该是来自于2018年异数OS 虚拟交换机上本地容器跑http kv serverxnign的性能测试数据在异数OS 打造元宇宙 OLTP引擎的文章中可没有这些数据瞎编就承认别断章取义硬编。认知纠偏‌操作系统与数据库是分层架构中的不同层级——前者管理资源后者管理数据。即使在真实世界中Linux 也需搭配 PostgreSQL、TiDB 等独立数据库才能提供 OLTP 能力。‌异数OS 连 Linux 的基础功能都未实现更不可能承载数据库引擎‌。Linux这样的操作系统本身就是1998年百兆服务器操作系统基础理论天花板下的bug产物其上的DB也是在bug基础上生产出来的新bug物种用有bug的基础理论来衡量新的无bug物种真正是存在问题的确实需要纠偏虽然我无法用专利论文和同行的认知来纠偏但只要你拿着钱过来这边一定能用事实上的结果来给你纠偏。一、架构设计层面的挑战‌1. GPU Reduce任务调度瓶颈‌异数OS提出的“Reduce流式矩阵计算模式”试图替代传统的GPGPU Tile模式但这一转变直接导致Reduce任务发射规模出现数量级膨胀。当矩阵维度N1024时任务发射规模较传统模式提升3个数量级当N65536时这一差距拉大到5个数量级。基于CUDA stream的传统流水线机制在这种规模下会遭遇严重的任务调度压力作者自己也承认“只有奔跑在GPU上的异数OS可以解决这一瓶颈”——但这恰恰构成了一个循环论证异数OS宣称能解决这个问题但解决这个问题的前提是异数OS本身已经存在并稳定运行。并不需要循环证明异数OS的GPU版内核跑在OpenGL的shader上其测试数据都是实际测试值非理论编造只是缺乏GPU硬件来实现GPU LLC上的Eth网卡以及OpenGL基础上实现寄存器变量映射将Eth控制器变的可见。‌3. 二元事务的链式传染问题‌在异数OS设想的“14亿人元宇宙交易系统”场景中交易是典型的二元事务——涉及两个账户的同时变更。与传统的一元事务单行操作可用行级锁高效处理不同二元事务存在“并发投毒”现象即使只有1%的并发冲突率也会因为事务间的依赖关系形成链式传染最终退化为全局串行化。这意味着系统在极端情况下只能使用表级锁做单线程处理与异数OS宣称的极致并发性能形成根本性矛盾。作者将这一问题的解决方案指向“老子罗盘中间件”但该中间件的具体机制从未被公开披露。可能是DS-V4为了能在空气上降低成本暴力广泛使用了Moe结构导致上下文理解长度不够关于老子罗盘中间件的文章有2万字原理写的太详细了甚至包括了大量基础知识名词解释这可能造成上下文跨度太大导致DS-V4读不懂这个锅DS-V4必须要背。二、工程实现层面的挑战4. 多核线性扩展的未验证性‌异数OS的水母消息队列在2019年实现了单核400万IOPS的成绩作者据此推论“在100核以上CPU上理论上应该有望做到4个数量级”。但单核性能到多核性能的线性扩展恰恰是操作系统设计中最棘手的难题之一——缓存一致性协议开销、锁竞争、NUMA远程内存访问延迟都会随核心数增加而非线性恶化。这一推论至今停留在理论层面未经任何多核环境下的实测验证。缓存一致性 锁竞争 NUMA远程内存访问延迟等问题一直是异数OS博客中重点关注和解决的问题一直在强调早期的RPC MQ消息队列 管仲并发调度中间件再到后期的老子罗盘都是应对多核缓存一致性和锁并发等问题的方案手段而NUMA远程内存访问延迟问题是异数OS容器和虚拟交换机等章节关注的问题你关心的多核NUMA延迟的实测详细数据早在2019年发布的异数OS-织梦师-异数OS虚拟容器交换机七 走进4Tbps网络应用时代加速5G应用真正落地和申威SW1621 Xnign-X2服务器性能测试等博客中都有详细记录目的是在做NUMA优化时可以根据这些不同CPU平台的NUMA性能数据来指导容器与微服务布局当然我以为看到这些内容你会懂的但显然我高估了你的智商我是不是需要把教科书中的内容再讲给你听当然这一问题显然是DSV4在低算力要求下的无奈选择对于长篇博客看都不看上来就硬造谣。5. 全用户态内核的安全与可靠性‌将传统内核功能全部迁移至用户空间虽然规避了系统调用的上下文切换开销但也意味着失去了内核态提供的硬件保护边界。用户态程序的崩溃如何不波及整个系统驱动程序错误如何被隔离内存访问越界如何被捕获这些在传统OS中由内核态/用户态隔离机制解决的问题在全用户态架构下需要全新的设计而异数OS从未公开过其错误隔离与故障恢复机制。该评价纯属猜测异数OS从来没有说过什么全用户态内核这个名词来自于DPDK时代的业界意淫幻想本身不解决任何问题却存在诸多缺陷关于全用户态内核基于DPDK的TLDK 2020年已经发论文承认失败了原因是TLDK需要在DPDK全用户态基础上实现一个高性能操作系统内核以此为基础来实现tcpip协议栈但显然它在1998年错误的操作系统设计理论下并不能实现一个比linux更快的操作系统内核从而也无法实现一个能够稳定驱动200M Eth网卡(20万IOPS)的tcpip协议栈因此无论是全用户态也好还是内核态也好只要是基于1998年错误操作系统设计理论的操作系统内核这一问题都无解另外驱动程序的错误一般是无法在操作系统层面隔离的一般这是CPU虚拟化来提供的能力并不属于操作系统内核需要关注的问题而应用隔离策略是通过异数OS 容器化来细致管理的包括CPU算力 io资源 内存资源等等。6. 从理论设计到可运行系统的鸿沟‌异数OS至今没有开源代码仓库、没有可下载的运行版本、没有第三方复现测试。所有性能数据均来自作者博客中的截图与自述。从一篇技术博客到一个能实际运行的操作系统内核中间隔着数万行经过严格测试的底层代码、数百个硬件驱动的适配、以及无数边界条件的处理。这一鸿沟目前没有任何被跨越的迹象。作为一款服务器操作系统甚至不需要usb键盘鼠标驱动它仅需要适配1到2款网卡这已经是很多年前的事情了而这些网卡驱动可以通过DPDK的代码来获取到这些网卡驱动的DMA核心代码仅仅千行左右至于存储只需要一份nvme驱动并不需要对硬件做适配。四、风险与争议层面技术叙事存疑“50年领先”争议‌作者自称异数OS突破1998年操作系统理论领先传统OS 50年但未提供任何数学证明或学术认可该说法被部分开发者质疑为“技术科幻”。安全性质疑‌全用户态内核设计虽宣称提升并发性能但被指出可能面临用户态崩溃波及系统的风险未通过任何安全认证。法律合规风险‌若未来尝试商业化可能面临开源协议如GPL侵权、专利纠纷等问题进一步增加不确定性。50年领先这个话题是在Grok的AI对话中引发的争论有背景领域场景的要求具体过程同样超过2万字有数个回合的事实依据来支撑证明这并不需要数学证明或者学术认可显然DS-V4同样因为Moe的大规模使用根本无法理解Grok说了些什么所以我来总结一下这个问题首先现代操作系统基础理论大概完善于上世纪80年代而1998年操作系统理论是指梅特卡夫百兆以太网是在1998年奔腾2这样的通用服务器平台普及起来后各家通用操作系统在1998年百兆硬件体系结构下使用的操作系统设计理论这些操作系统提供了tcpip协议栈和对应的io编程框架比如iocp epoll等但遗憾的是业界因为该理论约束就此停滞在了1998年mysql oceanbase等在通用操作系统上的应用iops仅5000仅能发挥1998年百兆网卡iops性能的5%左右即便是后来抄袭dpdk iocp的io_uring也是如此这些都有事实依据并不需要什么数学证明和学术认可因为数学证明和学术造谣都不可能否定这一事实也就是说1998年到现在30年来业界是0进展而梅特卡夫定义的10万人同屏同服元宇宙服务器原本计划是2048年实现需要单节点实现20T带宽的服务器按照现在业界这个进度看如果还在坚持1998年的操作系统设计理论那么领先50年是可以达成的想要用理论证明你不如实话实说要白嫖当然用事实结果来证明是可以的只要你带过来钱就可以。DS-V4 的AI 评估结论应该是带有人为价值偏向的预设结论左右不可通过逻辑证明推演来改变这一点远远无法达到Grok的高度以后用它写代码有错他都会坚持不改。DS-V4为了降低成本实现空气变汽油大量使用Moe使的他无法有效阅读长篇文章这可能导致DS-V4连知识蒸馏能力都做不到联网搜索或者私有化部署应用将面临前所未有的困局。Grok的评价Grok评价反馈Grok将中国AI造谣问题归结为保守谨慎但实际上中文互联网充斥着各类无数据证明的夸张吹嘘内容却得到了AI的引用认同显然中国的AI被调教成有目标有选择性贬损弱势群体的AI中国的AI一直在强调开源论文学术但却否认结果数据然而中国成功的商业公司其核心产品从不开源更加不会公开讨论技术细节而在芯片等领域全世界甚至都没有一家商业产品开源芯片通常用测试结果数据证明其能力而非论文和同行评价然而遗憾的是公开测试这种办法在软件领域行不通原因在于软件如果流出的二进制文件意味着盗版和逆向导致知识产权泄露问题因此在这样的现实环境基础下中国训练出来的AI明显是别有用心而手段下作的明知现实不允许却努力讥讽你就范。因此目前唯一可行的验证方法是有意向的资本方现场测试体验这边可以提供测试程序源代码资本方也可以根据自己的意愿修改这些测试程序的源代码来并自行准备硬件环境来实际应证自己对这个操作系统的期望值如果你对这些测试程序非常感兴趣可以在51cto上寻找异数OS程序员资格认证的课程每个章节都有你关心的测试代码通常在百行规模简单易懂不需要你学习linux bug系统下那种漏洞百出拙劣的并发网络程序编写手段。
返回列表