普通视图

就是要用not exists

2026年1月24日 08:30

我知道有一个大表,我也有这个大表其中了一些数据的小表,我需要筛选出除了小表以外的数据,思路非常清晰,但实际上要用Excel里面的SQL实现却好像异常困难。在一些高级数据库里,有特殊的函数实现这个功能,有些用的是except,有些用的是minus,但是Excel里没有。如果可以用except或者是minus,这将意味着可以对大小表全列对比,但是如果用其他方法,只能选取其中一些。刚好我要操作的表有一列刚好是多个列信息的集合,所以用那一列作为标识刚好,但如果我根本没有那一列呢?难道我还得先造一列出来,然后再进行操作吗?无论是用not exists或者not in的方式去进行这种筛选,都只能选取其中的某一列操作。如果是用not in的方式,还得要注意,如果那个小表是空的时候,会导致筛选失效。如果用not exists的方式,则不需要考虑小表是空的情况。

一开始想实现这种功能,我想到的不是这两个,而是用count。先去计算那些有重复项的行,然后针对不同计数结果分别处理。就思路来说很清晰,但就实现来说,很啰嗦。但虽然啰嗦,还是能得出我想要的结果。第一天我用这种计数的方式得到了我想要的结果,但我依然觉得应该有一些更直接一点的方法,于是第2天我就想用not in或者not exists的方式去实现。

not in的方式总算是做到了,但是效率不高,感觉耗时是用计数方式的两倍。in和exists相比,我感觉exists的效率更高,但关键是实际上我使用的是not in和not exist,所以估计还是挺麻烦。虽然就语句来说,不过是多了一个not而已。exists的实现耗费了我不少时间,理论上我的写法没有任何问题,但关键是就会报错。折腾了一个下午都无果。晚上洗澡的时候,我突然想到可能是引用数据简写那里出了状况。在使用not exists子查询的时候。我依然是用经典的a和b简写,但实际上在这个子查询引用的数据里面就曾经出现过a和b。如果某一句查询里面的简写a和b是同一个层次的,没什么问题,但关键是子查询这种操作有递归的感觉,主查询跟子查询不是一个层次。VBA弹出来的报错窗口说某个简写可能指向多个数据。后来我觉得大概是因为之前我就已经有用过a这种简写,层层嵌套之下,exists的子查询不知道我指的到底是哪一层的a。洗完澡以后,我赶紧找文件测试,把主查询的a改为了之前从来没用过的c。果然,not exists子查询通过了!多次测试对比发现not in跟not exists的性能确有区别,not exists会快一点点,但是跟计数相比,好像计数依然是三者之中最快的。从好理解的角度而言,not exists最为复杂,最好理解的我觉得是计数,但是就语句使用的长短而言,not exists和not in最简单的。最后我采用的是not exists的方案,但是not in跟之前计数的方案我都只是把它们注释掉了,没有删除。

如果Excel里面的SQL能与时俱进,我能用一些那些高端的函数,我根本不需要这么大费周折。别人有现成的模块,连个线就能用,但我什么都没有,所以哪怕是一个螺丝,我都得从零开始手搓。

虚拟机 VMwa re Workstation Pro 恢复快照 导致 找不到 vmdk 文件致虚拟机损坏无法启动

2026年1月18日 22:02

这破Bug坑我好几回了,全球没个活人研究一下这玩意?

本文大部分只是抱怨的废话,非Bug详解。

Bug复现步骤什么的我制作了视频并贴在了文中,本文中没有文字复现步骤,只有视频。没认真写,也没认真做,反正人家又没给我钱。

顺便骂一句:比垃圾Win10更垃圾的还有垃圾Win11


文首提醒

警告:请勿在你正在使用的虚拟机上尝试问题复现!此问题可能损坏你的虚拟机数据。

遭遇此问题

如果你是本博客的老读者的话,可能读过我2021年的一篇老文章《在 2021 年在虚拟机里安装 Win7》,文中提到了我因为 VMware Workstation Pro 的未知 Bug 导致我的 Win7 虚拟机损坏。

图片自:《在 2021 年在虚拟机里安装 Win7》

其实我虚拟机用得不是很多,大部分时间在 Linux 能完成我手头的大部分需求,遇到需要沙盒环境也有 Docker 这种强力工具,而打游戏我则直接用实体机上的 Win10,虽然 Win10 很烂但是仅仅打游戏而不用其他功能的话还是凑合的。老模拟器有抽搐的问题但是新模拟器还是专门对 Win10 做了优化的,至于老PC游戏那就真没辙了。再说虚拟机那性能更不可能用来打游戏 。虚拟机我基本上还是用来跑网银或者QQ这种国产流氓应用,或者是用来做录制视频的环境,或者作为沙盒环境用来跑一些来历不可靠的应用,用完就删了。

2021年的时候虚拟机炸了一次,当时我也没明白怎么回事,那个阶段 戴尔 VMware 博通 仨玩意一缸屎,VMware官网三天两头嗝屁,后来被Broadcom收购后,先是炸了整个 VMware 的知识库,之后又误封账号,反正基本是不可用状态,就当是VMware死了吧。

我当时也以为是我调整配置的时候把文件搞坏了,或者是硬盘空间不足导致硬盘文件丢了,反正锅都是 VMware 的,但是没心情深究。

后来也遇到过此这个 Bug,不过因为我当时留了 Win7 的 OVF 文件,所以没啥太大影响。


又被坑

再后来微软停止支持垃圾Win10。

垃圾Win10

(Win10就从带着一堆Bug出生,一直到带着一堆Bug入土)

本来我有些时候录制 Windows 下视频时用 Win7 就一直有人在视频底下骂:

  • 都202X年了竟还有人用 Win7
  • 有问题那肯定是 Win7 的错
  • 作者是不是有病竟然在 Win7 下用 XXXX

然后这些评论都是 秒得一赞 。(是不是太悲哀了)

地球上从来不缺奇葩人,只是所谓的偏偏都被我遇到罢了。

可以很清晰的预见到时候就算我在主机上用 Win10 录视频,肯定还是会有这种 秒得一赞 的评论。

索性不如干脆准备个 Win11 虚拟机。

然后就被垃圾微软的垃圾Win11恶心到了。

在虚拟机里跑Win7的感觉,有点像在自己的旧电脑里跑Win7,其实没啥太大体感区别,单机械硬盘无显卡加速的感觉,就是稍微慢点,但是所有功能都正常可用。(其实即使有固态硬盘,垃圾Win10的启动速度已经有一种在老电脑上用XP的感觉了)

垃圾Win11可就垃圾多了!

咱不说什么安装必须联网和必需有 TPM2.0 加密这些。事实上即使是2025年9月末发布的最新版25H2版本,断网并拔了TPM照样能用。安全性个鸡鸡。

问题是Win11的那个UI,明显的同时山寨了苹果的 MacOS 和 Ubuntu Unity ,然后用 Andorid 这种因移动端小屏幕而不得不妥协成单会话的形式在大屏幕上呈现出来,我当时在 Win10 的时候就骂过了 Windows 你不是 a-Window ,结果 Win11 只是个更加垃圾的 Win10 罢了。

【比垃圾Win10更垃圾的还有垃圾Win11】 https://www.bilibili.com/video/BV141421k721/

更别说 Win11 自带和国产流氓厂的全家桶,还不好使,各种奇葩Bug。仅是天气这一个功能这块,他用IP尝试定位用户物理位置,出错在所难免但是正常都会预留个手动选择地理位置的功能,但这个功能有很高概率崩溃。就更别提有些人根本不想在录视频或共享屏幕的时候暴露自己的实际地理位置了(国外隐私泄露和网络暴力可比中国的成熟太多了)。再说谁他妈的天天看股票!

企业版 Win11 的体验更接近于 200X 时代自带病毒木马的全家桶 GhostXP,或者更像是装满了各种弹窗广告的老年人安卓机。

【老年人的牛皮癣手机】 https://www.bilibili.com/video/BV14EUhBHE46/

 

就更别说性能问题了。Win11的性能跑分在 Windows 历史上最低。他的破UI视觉效果也是全系列最烂。你要知道即使是Win95也是支持设置高亮颜色以及移动任务栏的,Win11没这功能。

至于 Win11 的专属 Bug 数量,那真是 Win10 永远都没法超越的。

作为一个从Win95用上来的老年人,有时候看着这些晚辈没吃过一口饭,上来就只吃这种Win11屎,还要不停的维护他们根本不存在的可怜自尊,遗憾又无奈。

扯远了。

简单来讲,我就是在虚拟机里装了一个 Win11,除了录制视频之外没有任何其他用途。事实上如果需求不是特定Windows系统的话,我宁可在 Linux 下直接录制,刚才也说了,Win11那个天气功能我甚至没法成功将其默认设置改为哈尔滨。就更别提,Win7虚拟机启动也就几分钟(200X年的低配单盘主机的感觉),而Win11的启动速度需要几十分钟,桌面亮了不代表启动完成,仅是右键套皮这个设定更像是WinXP时代的各种第三方美化工具,但是XP皮上套皮只是个玩具,Win11则是强制的,性能差到如同死机。

更别提其占用的硬盘空间实在是太离谱了,即使是历史上最为诟病的塞满了错误的驱动文件的 Vista 都要退却。所以我根本没备份 OVF 文件。上哪给这破玩意准备几十G的文件存这一坨屎。

然后这个虚拟机因为 VMware Workstation Pro 的 Bug 炸了。

2026-01-14_21-23-00

厕所爆炸!

(我这还一虾仁呢)


我一怒之下怒了一下

我从 VMware Workstation Pro 5.x 开始深度使用。到后面 VMware Workstation 开始抛弃没虚拟化功能的CPU时,其实我就觉得有些不爽了,毕竟早些时候我的老奔腾 T2130 配合虚拟机是做过不少事情的,结果直接放弃支持实在是不爽。

但是被这个 Bug 坑却是 2020 年后的事情了。

2021年的时候因为 Win7 虚拟机炸了的时候我就在网上搜过,好多人都遇到这个问题,但是基本没任何下文。当时 VMware 官方基本已经死了,更是什么内容都没有。

从2021到2025也是遇到过好几次。

这回又遇到,是2026年,用的还是比较新的 VMware Workstation Pro 17.6.4。能确定这恶心 Bug 一直存在。

再上网搜索,发现互联网已经死了。

能搜到的有效内容,一部分是 Broadcom 最近两年的用户发帖,另一部分则是国际版百度贴吧一样存在的 Reddit,还有少量的 Linux Mint 社区(没有Fedora/CentOS和Ubuntu社区就很神奇,这俩玩意桌面版用户基本死透了吧。Arch用户估计根本不用虚拟机吧),以及其他国际营销号网站。

那结果自然就很明显了,Broadcom都是装死的评论,贴吧能有多少不是狗屎,Linux Mint 社区更是XY问题高手,营销号网站当然是重启重装换机器三件套。


最后还是靠自己

至此我已经十分确定:

  • 此 Bug 确认存在,而不是用户环境或用户误操作导致
  • 此 Bug 确认在日常的界面操作中即可触发,非罕见的特殊操作,非手工修改配置文件导致
  • 此 Bug 长期存在于多个版本中
  • 活跃的 VMware Workstation Pro 虚拟机的用户已经很少了

那我就不客气了。

【[VMware] 虚拟机 VMware Workstation 恢复快照和编辑虚拟机设置 导致找不到 vmdk 文件,虚拟机损坏无法启动,亦无法使用快照功能恢复】
https://www.bilibili.com/video/BV1RorxBeEPp/

If you can’t read Chinese, try this YouTuBe video:

【VMware Workstation vmdk file not found after restoring snapshot and editing virtual machine setting】https://youtu.be/58QdSdrpDQ4

(文字复现步骤我就不写了,省得到时候被AI爬。我当然不担心被AI爬,AI看视频的终点和人类一样,都是变痴呆)

真TM草台班子。

这个 Bug 在 HDD 下更容易出现,但是在 SSD 上也不是完全不出现。只要特定操作就有概率出现,但又不是 100% 必现(视频里只录制了必现的情况,实际上不是100%的)

大厂开发者的嘲讽:你没有全固态的主机吗?


结论

IT行业的时代结束了,现在是草台班子占台抢你钱的时代。

The post 虚拟机 VMwa re Workstation Pro 恢复快照 导致 找不到 vmdk 文件致虚拟机损坏无法启动 first appeared on 石樱灯笼博客.

修电脑

2026年1月7日 08:16

电脑突然点不亮,如果是我,我会怎么办呢?

首先我不会怀疑是自己的显示器或者数据线有问题,因为显示器和数据线突然坏掉的几率不高,哪怕是坏掉也不可能是一刹那之间突然就不行。如果是在开机的时候不行,但上一次还可以,那么我觉得大多数情况之下是主机的问题,哪怕主机的电源灯能点亮,拆开面板发现里面的风扇都在运转。如果是软件系统的问题,理论上显示器不会点不亮,顶多是出现一堆英文。以前的电脑一定会出现一堆英文,因为进入不了windows系统,但windows系统之前的那些是可以的,所以界面就是一堆英文。那堆英文在win7以前的那些系统下是比较常见的,尤其是在win95、win98和XP的时候,但之后那堆英文我感觉出现的概率越来越低,但正是因为后面出现的状况是屏幕直接不能点亮,所以连显示那一堆英文告诉你到底是哪里有问题的路径都没有了。

我还记得一开始使用电脑的时候,哪怕主机没有内置的音箱,但是一旦出错,主板会响,会用各种长短结合的提示音告诉你是什么方面的问题。有可能是内存,也有可能是显卡,也有可能是其他东西。那些提示音有长有短,你只需根据长短多少下,然后查相关资料就知道是哪里的问题,但我觉得后来基本上机子都不响了,是直接没有了那个设备还是其它原因?还记得大学和大学之前,我和我的同学用的那些主机过上一段时间就会莫名其妙不能开机,响警报音。绝大多数情况之下响警报音都没什么问题,基本上是内存太脏了,把它拆出来,清理一下金手指,清理一下内存槽,然后再插回去。内存没有坏,只是那个东西太脏了,需要定期清理。再早一点的时候,电脑的电源也不太好,但这也有可能是我家那个时候的电压不太稳,反正各种因素叠加就是我家那台电脑的主机电源经常会挂掉。如果拆开面板发现主机里面的东西完全没反应,无法点亮,短接电源依然无法开机,这就意味着电源坏了,没有任何办法,只能换一个。后来我发现,可能主板CPU内存硬盘光驱又或者其他设备的更新换代已经到达了一个瓶颈期,不会再有非常大的更新,所以对电源的需求也没有继续暴涨下去,感觉后来基本上主机的电源不会突然挂掉,不仅仅是我家的那些不会,单位那些组装机、品牌机也不会。

一开始饭堂师傅跟我说他的显示器不能点亮,他直接就在显示器那方面想问题了,但实际上不应该这么处理。他把显示器拿到我那里测试,已经证明了显示器和那根HDMI线没有问题。显然就是他主机的问题,主机有什么问题呢?插上电源发现电源是可以点亮的,CPU显卡以及机箱风扇,还有里面的跑马灯也都是动的,他插上了鼠标,鼠标是亮的,错误的地方是没有插键盘,如果键盘也插上去,插上去了键盘可以点亮,那些大写又或者Num Lock可以控制,就意味着主板CPU也基本没什么问题。什么原因导致显示器无法点亮呢?有两个是不花钱就能纠正的,一个是内存,一个是显卡。内存拔出来,查一下金手指,清理一下内存槽,再插回去。因为他的主板没有显示器输出,所以用的是独立显卡,独立显卡跟内存可能有同样的问题,也是金手指脏了也是那个插槽仓了,所以清理这两个东西,不花钱又绝大多数情况之下都能排除故障。但显然师傅没往这方面想,他考虑的是独显是不是有问题了,独显上面有4个插口,三个DP,一个HDMI,万一HDMI那个口坏掉了呢?但实际上,独显的HDMI插口坏掉的几率我感觉非常低,除非出厂就有问题,如果出厂没有问题,你只是把它静止放在那里使用,要让它突然出问题这实在太难。除非师傅的运气真那么好,但如果他有那么好的运气,估计可以去买彩票了。

别人电脑坏了,想的是找谁去修,我的电脑坏了,我会自己去找原因,当我实在没办法的时候才求助别人,这也只是电话或者微信求助。到真不行的时候,我才会让别人帮我修,但是到了那种程度,基本上已经病入膏肓了,直接放弃以旧换新比较合适。

显示器无法点亮

2026年1月6日 08:22

2026年的第1个工作日,我选择一大早就把被子晾到3楼的露台,然后把床上用品都洗了,之所以这样是因为我知道接下来几天都是大晴天,还有就是12月我的床上用品没洗过,所以得抓紧这个好机会。因为我感觉2026年的1月晴天不会持续的太久,很快阴雨就会袭来。

一切都在按计划进行,傍晚当我把被子的被套拆掉,扔到洗衣机,正在换新的被套的时候。饭堂的师傅敲响了我的宿舍门。他就住在我对面,只隔了一条走廊。我回来的时候看到他拿了个显示器。他敲我的门是因为他知道我有台式电脑,他想试一下他的显示器,因为他说他的电脑连接显示器,显示器毫无反应。过程很简单,就是HDMI接口连到我的主机上,结果很快就把显示器点亮了,这就意味着他的那条HDMI线没有问题,显示器也没有问题。如果这两个都没有问题,那么估计就是他的主机有问题了。主机有问题,比显示器或者那条HDMI线有问题更麻烦。

我去他那里看一下,的确主机已经亮起来,无论是CPU、机箱还是显卡风扇都在转。估计那是一个专门用来打游戏的主机,所以里面的走马灯五颜六色,但是显示器一点反应都没有。我让他把键盘和鼠标插上,他只插了鼠标,鼠标是有电的。然后我就提了个建议,要不把他的电脑插在我的显示器上看一下有没有反应,结果还是那样,机箱风扇在动,但显示器没反应。

他用的那个显示器的牌子,我从未听过,那个主机一看就知道肯定是个组装机。主板很小,接口让我觉得挺神奇。主板我觉得性能可能不太好,但是那个独显貌似不便宜。他的HDMI线插在独显上,但是主板后方我就没有看到有显示器接口。为什么居然有这样的板子呢?不仅仅是显示器,连无线网卡的接口也没有。为什么要无线网卡呢?我记得他那里是有路由器的。让我觉得很神奇的是,他的那个主机后面板上还有一个绿色和紫色的鼠标键盘插口,在我印象之中只有非常老的机子才有这个东西。可以说如果那个东西还配有这两个接口,估计主板的年纪在10年以上。那个时候我的第一个反应是独显可以拆掉,如果你的主板上有显示器接口的话,直接接到那个地方,但显然他的主板根本没有。没有了独显貌似就没办法操作了,那个独显我之所以觉得比较高级,是因为那玩意有4个接口,三个是DP,一个是HDMI,他怀疑HDMI那个口有问题,但问题是他的显示器只有两个接口,一个是HDMI,另外一个是VGA,所以可以怎么办呢?最简单的方式是找一个有DP接口的显示器试一下。现在主流的显示器HDMI跟DP接口估计都有,而且据说高版本的DP传输效果会更好,所以那些游戏狂人估计连接的都是DP。我让他找一下跟他一起打游戏的那些人,估计他们就有,但他居然跟我说,他都不知道谁在打游戏。以前我记得有人会去他那里打游戏,或者他会去别人那里打游戏,但我不知道为什么他说不知道。

我办公室的电脑就是DP接口,显示器跟主机是用DP线连在一起。那套戴尔的品牌机除了DP以外,还有VGA。机子买回来的时候配了这两条线,但是这套机子是没有HDMI接口。我没有印象单位的其它电脑用DP线,除了我那台机还用DP线以外,虽然科室里还有一个跟我同款的显示器,但是那个之前跟电脑连接的用的是VGA,因为那个主机只支持VGA和HDMI。我没办法让师傅跟我回办公室用我的显示器做测试,因为我的显示器跟我的主机把线预埋得非常到位,要拆出来很困难,但我能不能找到其它DP线呢?几年前除了我那台机以外,科室里面还有两台机用的是DP线,但关键是那两台机都已经退役了。退役的那两条线去哪里了谁也说不清。

我觉得师傅可以做的是在网上随便买一个DP转HDMI的试一下,那个东西不贵,便宜的话买个转接头就好了,如果要效果好一点,买个线可能稳一些。

微软操作系统在2025年12月才开始支持NVMe协议

2026年1月4日 21:23

垃圾微软又一次成功的刷新了我对其垃圾程度的认知。


技术简介

首先为不了解技术名词和技术原理的朋友简单讲一下。

传统的存储设备中,机械硬盘都是靠电机+磁头的方式工作,光驱也是靠相似结构的电机+激光头工作。这就意味着这种类型的设备在同一时间内只可能完成一个查询请求(CRUD,增删查改),不存在并发查询的可能性。

img_BV1iT4y1k7G7-1

(希捷 Exos X18 18TB氦气硬盘开盖结构)

img_BV1U8411s7Mh-1

(希捷双磁臂硬盘工作方式)

img_BV1iT4y1k7G7-2

(希捷双磁臂近照)

图片来自:

而对应的存储设备的 接口/传输协议:SATA,是专门为这些存储设备设计的,也仅支持单并发。

(因本人目前能查到的SAS接口的技术详情有限,本文不讨论SAS接口)

  • 2003年的SATA 1.0 版本原始带宽为 1.5Gbps,传输速率约 150MB/s
  • 2004年的SATA 2.0 版本则翻倍,原始带宽为 3Gbps,传输速率约 300MB/s
  • 2009年的SATA 3.0 版本则继续翻倍,原始带宽为 6Gbps,传输速率约 600MB/s

而2025年,机械硬盘最高的持续传输速率大概也只到 300MB/s 左右。

img_sata_hdds

(3.5寸机械硬盘和2.5寸机械硬盘的接口。注意,短的那个才是SATA接口,长的那个是电源接口)

img_SATA_ports

(SATA数据线和SATA插座)

固态硬盘开始普及后,一开始固态硬盘使用和2.5寸机械硬盘相同的硬件外观,使用标准SATA接口。体积太大!没那个必要。后来开始用mSATA协议,体积缩小,但是仍然受限于SATA的单并发查询限制。行业新定义了m.2接口,更小。同时定义了新的传输规范 NVMe,其支持固态存储的并行查询能力,理论上一次支持最多64000个并发查询。其他优点我在这里就不讲了。

img_MSATA_SSD_vs._2.5__SATA_drive

(2.5寸SATA接口硬盘 与 mSATA接口硬盘)

img_M2_and_mSATA_SSDs

(mSATA固态硬盘(左) 与 m.2固态硬盘(右))

注意:m.2 接口同时有 SATA 版本和 NVMe 版本,SATA 版本是走 SATA 协议的,仅支持单并发查询。所以正常人都在你买固态的时候,推荐你买 m.2 接口走 NVMe 协议的固态。SATA 接口的固态主要还是为了供给那些只有SATA接口的老电脑和老存储服务器使用,m.2 接口走 SATA 协议的版本同样也只是为了迁就过渡时期有 m.2 接口却不支持NVMe协议的旧主板。至于奸商的歪理邪说我就不提了。(固态硬盘的成本都在颗粒上,协议和接口对价格没太大影响)

小总结

讲到这里其实就已经很清晰了。

  • 给机械硬盘设计的 SATA 协议不支持并发查询
  • 给固态硬盘设计的 NVMe 协议支持并发查询

用支持 NVMe 的固态硬盘就对了。(除非旧电脑没有硬件条件)


垃圾微软

NVMe 协议比 SATA 协议性能好,这本身就是个很简单也很容易理解的道理。

然后傻逼的微软就开始搞笑了。

NVMe 协议开始于 2011 年,大约在 2015 年前后,包括 ChromeOS 和 iOS 在内的多数操作系统都添加了对 NVMe 的原生支持。而 Linux 更是早早的在 2012年就已经在内核中添加了对 NVMe 的支持。

而2025年12月份,微软才正式官方支持 NVMe 协议,而在这之前,微软的所有操作系统是 把 NVMe设备 当作 SCSI设备 处理的

也就是说:微软操作系统(包括最新版的Win11,以及服务器版的 Windows Server 2025)都不支持 NVMe 协议。插上去的支持 NVMe 的固态硬盘被当作旧 SCSI 协议的机械硬盘一样对待。(来源:微软官方,链接使用了 文本片段(Text Fragment) 功能以通过 URL 高亮特定的文本,但微软官网会清除对应的高亮,垃圾微软)

screenshot_on_b85m_by_flameshot_at_2026-01-04_20-52-52

screenshot_on_b85m_by_flameshot_at_2026-01-04_20-51-54

说实话,虽然只有东亚国家和俄罗斯会使用 黑色方框示亡号,但是看到 Microsoft 上带个黑框,感觉微软也早就死了

个人猜测:理论上NVMe协议可以让固态硬盘直连CPU,在延迟性能上要比需要经过SATA控制器的SATA硬盘好得多。但由于微软的废物逻辑,由操作系统产生的硬盘操作指令是SCSI指令,还要再由CPU翻译成NVMe指令,其延迟性能可能比有原生SATA支持且有单独处理芯片的SATA性能还差。

也就是说你的 Windows系统 的 电脑/服务器,固态硬盘插 m.2接口 还是插 SATA接口,走 NVMe协议 还是 SATA协议,性能都是一样烂的。


其他补充

关于SAS

虽然研究不够深,但是对于泛用于企业级硬盘的SAS接口,情况相同:

SAS(Serial Attached SCSI)同样仅支持单队列,与SATA情况相同,只不过其队列深度比SATA要高。

关于AHCI

其实我没太搞明白AHCI和SATA之间的关系。

 

如果你有更全面的参考资料的话,可以分享。


参考资料


结论

垃圾微软!

The post 微软操作系统在2025年12月才开始支持NVMe协议 first appeared on 石樱灯笼博客.

wps也沦陷了

2025年12月24日 08:30

office的ADO+SQL跨表查询挂掉已经一周有余。虽然在这期间微软又出了更新,但据说那个更新并没有把这个问题解决掉。就在这周二,有人在论坛上说wps也中招了。之前一直好好的,但突然间就中招了,他并没有说错误代码是什么,是不是跟我们遇到的相同,但可以肯定的是,wps也中招了。office跟wps是两个不一样的东西,所以如果两边都中招的话,就意味着这个bug可能出在windows上,因为绝大多数情况之下,大家都是用windows系统,可能是win10也可能是win11。我用的是win10,所以我用回滚的方式就暂时没有问题了。之所以这样,是因为我没有参加安全延长计划,所以理论上我的win10是不可能再更新的,但win11不一样。谁知道那个wps中招的电脑是不是win11,是不是周一或者周二进行过自动更新。更新那些东西有时候会让你重启,所以你有感觉,但有时候是静默的,所以你根本不知道已经更新了。

就在网友的wps宣告沦陷之前,Office2024批量版也中招了,但是他中招的时间比我们这些当前频道零售版的晚一点点。从他的那个版本号可以看出,他的office已经更新到最新版本,就那个时间来说,跟让我们中招的那个版本差不多,所以我猜测那个版本更新搞倒了一大片的人,无论你是零售版当前频道,beta频道,企业半月更新频道,又或者是批量版。唯一有可能不受影响的是Office2019,因为跟win10一样,理论上那应该已经被微软停止支持,但如果那个Office2019装在win11的系统上,这又变得有点难说。Office2024批量版中招的那个人。他还不知道自己已经更新到最新版本,但从截图我一眼就看出,他没有禁止office更新,同时版本号也预示着他的确已经被自动更新了。office的更新跟windows的更新有些许不一样,因为office除了一些非常大的版本你会有感知以外,其它都是静默更新。

当wps网友宣告他的也沦陷以后论坛的大佬出来了,论坛的大佬测试一番说,最新版本的wps没有问题。wps也是比较神奇的存在,最新版本到底指的是哪个呢?个人版?企业版?专业版?付费版?还有一些针对特殊群体的版本。简单来说就是wps版本的复杂程度我觉得跟微软的office有得一拼。可以肯定的是,office的版本虽然多,但是你还是能在网上找到各种版本的来龙去脉,但是wps能不能查到我不知道。跟office不一样,很多版本的wps还停留在32位。所以到底中招那个人在用什么版本的wps?是32位的还是64位的?是不是针对特殊群体的版本?这都很难说。对普通人来说,哪个版本不中招用哪个版本就完了,但是对一些电脑数控的单位来说,无论是回滚office还是回滚wps,又或者是装另外一些版本的wps都是很困难的。

方法有很多,但是很多时候是人的所谓“安全”限制了我们的想象力。

经历了3次bug

2025年12月19日 08:41

我大概是从2023年夏天开始用各种方法进行跨表查询的,最后留下来主力是ADO+SQL。在这两年多的时间里,我感觉经历过三次说不准什么毛病的毛病。

第1次是不知道为什么,部分VBA运行不了,但貌似只在我的电脑上不行,在别人的电脑上可以,而我的电脑可能重启一下又可以了。这个现象很奇怪。在我办公室的电脑出现概率比较高,因为用得最多,家里的电脑偶尔也会这样,但无论是哪一款,可能重启一下就好了,但也可能重启也不好,因为这个是偶发性的,当我想他重复出现的时候他不出现,当我不想他出现的时候它就来了,所以很无奈,什么都没做过一段时间它自己又好了。当时我没有去深究这到底是什么原因。因为复现效果不好,也不知道该如何描述,但从后来的情况看来,可能这是因为windows或者office的某个更新引发了某个bug,但那个bug在往后的某次更新里又基本上被修正了回来。

第2次出现状况是在今年的夏天。情况就是一直使用的那些查询文件突然需要很长时间才能完成查询,查询是可以完成的,但是需要的时间比正常情况之下多很多。那个时间就比较神奇,是12秒的倍数,这个12秒不同的电脑可能不一样,我办公室的那台电脑是12秒,我家里的那台电脑可能不是12秒,可能需要更长的时间,因为家里那台电脑的cpu性能差一点。为什么会这样呢?这一次我是有研究过的,也在论坛上跟网友们分享过,他们也给出了临时的替代方案。临时的替代方案也不是不行,反正我就一直用那个替代方案,顶多是一开始的时候很麻烦,得把数据源挪出查询文件。微软到底是花了多少时间才修复那个bug我不知道,因为我已经按照替代方案的指引把我的文件都整理了一遍。以至于那个bug根本没办法继续伤害我,但某一次我又闲着,打开测试文件的时候发现那个bug没了,微软不知道什么时候修复了。

接下来就是这一次。这个bug和上一个bug我感觉有点类似,起码我用同样的测试文件就可以把它们都揪出来。上一次网友还可以给出提供替代方案。在不改变office版本的前提下,依然能让查询正常的运行,但这一次,简直就是个未解之谜,而且是封杀掉所有跨表查询。所以这一次好像唯一的做法就是暂时回滚,但回滚了以后,我怎么知道微软什么时候修复了那个bug呢?难道我还要在电脑里装个虚拟机,虚拟机那里用最新的版本?我没办法跟他们耗,首先是因为不能跨票查询就直接把我搞死了,其次是这件事情发生在年末,我没有时间耗。跟Excel打交道的人,年底的数据是最让人疯狂的。所以大概我就只能寄望于其它使用365或者Office2021售版的人给我继续做测试。当他们使用的当前频道可以正常运行测试文件,那么那个时候大概我就可以把365的禁止更新取消掉了。

为什么2025这种bug会出的这么频繁呢?其实我也不意外,因为不仅仅是office,windows的bug也很多。win11几乎每次更新都会带入幺蛾子,现在的微软已经不是以前可以完全信任的巨硬了。

回滚office

2025年12月18日 09:07

用之前的文件做测试以后,其实我已经基本锁定这一次ADO+SQL查询失败的原因。我个人猜测是因为进行了某项封堵,只允许指针到达的那个地方进行数据格式化查询,另外那个用绝对地址引用的东西没办法转化为同样的数据库。这个现象只是从我的电脑里面发现的,我不知道其他人是不是也这样。我的那个测试文件刚好对数据源进行了各种各样的枚举,所以刚好碰巧可以用来测试。如果有人在6种情况下都可以顺利运行,基本确定他的office是不受这一次升级影响。非常有可能他一直停留在某个版本没有升级,也可能他使用的不是当前频道,而是批量版的长期频道或者beta频道。因为我的电脑用的都是当前频道,所以我需要大家一起来测试不同频道是不是同样存在这个问题。我用的是Microsoft 365其它版本的office,比如2021、2024或者2019会不会也受到影响?我个人感觉可能2019没有受到影响,因为和win10一样,在2025-10-14开始就已经停止支持,但因为我的win10在11月依然进行了两个升级,所以2019会不会也受到波及我觉得有点难说。

帖子发布了一天之后,终于迎来了大佬的关注。可能大佬正在使用的那个电脑也受到了这个的影响,而他的电脑又或者他使用的office可能不仅仅是一个版本,所以他可以明确指出某个版本的office不行,但是某个版本可以。他的解决方案是要不等待微软更新解决这个bug,要不重装回旧的那个版本。哪个版本可以他也已经说出来了,装回那个旧的版本以后你还得禁止自动更新,否则还是不行。装回旧的版本我感觉是一定可以解决问题的,但是要怎么装回旧的那个版本呢?登录微软的账号,365那里的确有离线安装包,但是下载安装得花费很多时间,而且那里只会给你提供最新的版本,除非之前就已经把旧版本的离线安装包存下来,否则几乎无解。

大佬都这样说,意味着这一次的bug估计不是修改某个注册表就能解决的。几个月前的那个bug,如果把VBA的文件从xlsm降级为xls,也就是2003版本的那种Excel文件,就能避免查询时间很长的问题。如果只是一个查询文件,降级没有问题,但如果那个文件里面带有大量的格式,这样的降级就会让那个文件面目全非。这一次我也尝试过把xlsm文件降级为xls,没有效果。

之前我从未试过把office降级,但是我曾经试过卸载windows的更新文件。在控制面板里就可以卸载windows的部分更新文件,但office的在哪里呢?显然不在那个位置,于是我就去搜索如何把office回滚到旧的版本,结果出乎意料原来如此简单。

打开office任意软件-文件-帐户-更新选项-禁止更新
windows搜索cmd,管理员模式打开
粘贴
cd %programfiles%\Common Files\Microsoft Shared\ClickToRun\
回车
粘贴
officec2rclient.exe /update user updatetoversion=16.0.19328.20244
回车
等待

16.0.19328.20244是Microsoft 365当前频道的版本,回滚后SQL跨表查询恢复正常。更多office版本请搜索微软官网。

365更新版本的官方链接是:https://learn.microsoft.com/zh-cn/officeupdates/update-history-microsoft365-apps-by-date
更多版本的做法请看:https://www.bilibili.com/opus/1136898381847724034

一波操作后就可以了。我选的时候2510的大版本,让我出状况的是2511版本,在我印象之中,北京时间2025-12-14之前我一直没有问题,而让我出问题的那个2511是属于大版本里面的第2个版本。我选择跳过了2511的第1个版本,为的是更稳妥一些。当我把2510,19328.20244装回去以后。点击查询,VBA正常了,接着我赶紧把这个方法让同事也操作一遍。因为SQL的跨表查询无法进行将严重影响我们的工作。试验证明她的电脑也没有问题了,我们两个的版本都是365。

之后我赶紧回到ExcelHome论坛,把这个简单的回滚方式分享给大家,跟卸载office重新安装比起来这个回滚简单很多,速度也很快,只要你的网速靠谱。因为我感觉其实对office来说,它内部就是卸载了一个补丁,然后再填补一些东西,而并不需要整个office都翻新。单位的网络是很神经,但从开始回滚到结束,大概花了不到20分钟。最长的时间都用在了下载上面,安装很迅速,安装完成以后。365的激活是正常的,我的账号是正常的,也就是说直接开箱使用。查看版本就可以发现已经从2511退回到2510。

本来我的办公电脑是win10,没办法继续更新下去,我觉得让365停止在一个合适好用的版本是一个比较安全的做法。

当个吹哨人

2025年12月17日 08:38

到底是什么原因导致了这个ADO+SQL查询一夜之间就失败呢?首先我把这个错误代码和错误描述拿去搜索,无论是bing还是百度,历史网页都没有太多有价值的信息,同时我也搜索了24小时之内的结果。两个搜索引擎都没有找到些什么,也就是说发现这个问题的人估计还不多。奇怪的是,当我用国际版的bing的时候,发现居然没办法限制搜索结果为24小时内。不知道如果用Google会有什么效果,但显然在上班时间我不想冒那个风险用Google。

搜索没办法得到结果,我就去ExcelHome的论坛VBA板块看一下,果然也是没有人发帖,我觉得如果有人在那里发帖了,搜索引擎估计能捕捉到,但显然没有,于是我就当了吹哨人。一开始我就把已经发现的情况描述出来,比如是什么时候开始发现不行的,有什么错误代码有什么错误描述。

一开始我的帖子就只有那些东西,但之后我又拿出了几个月前用来测试文件打开的时候查询很慢的那个文件,把所有选项都点了一遍,结果发现6个选项里面只有2个选项可以完成查询,其余的那些都不行。对比成功查询的那两个,发现里面其实我只做了一个cnn的指向。其它实际上用的是两个数据源,虽然最后输出的数据可能只是指向其中一个。这个情况很尴尬,意味着用经典传统写法的cnn是可以正常查询的,无论数据源在查询文件里面还是在外部,无论那个文件是关闭的还是打开的。之所以要用ADO+SQL,就是为了可以方便快速地跨文件查询。现在这个指针只能是一个,以前除了指针那个以外的其它可以用绝对地址引用到达,现在那些用绝对地址引用的好像都不行了。遇到这个情况我很绝望,这就意味着我的那些查询文件一夜之间几乎全部都失效了。如果只是一个文件,那还好,但显然我绝大多数的查询都是跨表的,也正是因为有跨表这个功能,才让它们有价值。偏偏微软不知道进行了什么更新,把这个给废掉了,我不知道他们什么时候才能修复这个bug,但我觉得没有半个月估计搞不定。因为首先他们得意识到有这个bug,然后才着手去研究是什么更新导致了这个bug。马上就年底了,各种各样的数据报送要求接踵而至,在这个节骨眼上你给我干出这种bug,我实在非常无语。

发现了这个只要跨文件就失效的问题以后我马上又去论坛那里补充更新。补充更新过了一段时间以后,我就发现有人回帖了。他的状况跟我一样,无端端那些联合查询失效了,他用的不是Excel,他是用Access,也就是全套office的这个用法都撞墙了。

有人说不行,也有人说他没事,仔细看他们的那个office,我感觉没挂的那个用的是beta频道,而我们这些挂了的人我感觉是用零售版的当前频道。批量版的长期更新估计还没有状况,因为他们要过上很长一段时间才会有更新,相对于零售版的更新来说,那些批量版的更新会稳定一些。之所以要发帖,是因为我要看一下到底有多少人和我一样的,我知道论坛里面有大佬,他们遇事比我多,他们可能会想到一些我想不到的解决办法。我不知道他们有没有遇到这种问题,有可能他们没遇到,因为即便装的是零售版,他们通常会禁止更新,更多的可能是他们用的是批量版。但因为他们是热心的大佬,看到小菜鸟在那里求助,他们不会坐视不管,这样的话,我们这些中招的人离得救就不远了。

要解决专业的问题,得去专业的地方吸引专业的人。

ADO+SQL突发报错

2025年12月16日 08:19

周日晚上感觉一切都好,没有遇到什么特殊的情况。周一早上打开wifi连接网络,打开微信以后发现同事给了我一个信息说前一天晚上VBA的查询失败了,无法获取数据。看到那条信息,我的第一反应是会不会重命名有问题。那里有个截图,但我没有仔细看。VBA的弹窗都那个模样,而且大概差不多都是那些内容。虽然有说是什么方面的问题,但通常你往那个方向想的话,可能根本找不出原因,所以我就没有看。出现这么个状况,最大可能是浪潮升级系统以后又改过某个导出数据的表,导致那个表里面的某些字段名改变了,那个字段又是我使用的,于是就会查询失败。为什么我觉得是浪潮的原因呢?因为20点多的时候还是很正常的,我的同事是23点多的时候查询。她查询的时候,单位的作业已经结束了半个小时以上,如果浪潮要抓紧时间升级,估计会在作业结束以后马上进行。综上所述,如果查询失败,我的第一感觉是浪潮整出来的幺蛾子,但我不确定这真的是浪潮的幺蛾子还是我同事文件名不对导致出状况,唯一能做的就是上班以后我自己试验一下。

文件导出后,的确发现查询失败了,错误代码是80004005,对应的描述是“这种对象类型不支持该操作”。在我印象之中,没有遇到过这种描述的错误,但是搜索800044005这个代码,很多各种各样的原因都会是这个号,所以这到底是什么毛病呢?在我记忆之中,如果是浪潮改了那个表,导致我查询失败,应该不是这个描述,但是我没有太多的时间去研究到底是什么,我得先把我手头上的东西都搞完。

搞完那些日常必须做的东西以后,我开始研究这个查询失败。按照常理,浪潮bug的概率最大,所以我首先把之前从浪潮导出的表格和现在从浪潮表出的导出的表格的字段核对了一遍。发现字段是完全一致的,整个表格的构造也是一样的,所以这基本排除是浪潮的问题,为了证明的确不是浪潮的问题,我把以前导出的数据喂给查询文件,发现和新导出数据弹出的错误一样。这样就说明了肯定不是浪潮的问题,但不是浪潮的问题,那是什么问题呢?在进行新旧表格对比后,我又回到查询代码那里,先是逐个删除我觉得可疑的,结果发现还是那样,最后就直接原表输出,居然原表输出也出了状况。到这一步的时候,我基本确定是微软的问题。因为前几个月我们才经历过如果进行ADO+SQL查询的时候引用了当前查询文件所在的表格,就会让查询时间大幅增加。如果查询的时候,源文件所在的文件打开了,也会让查询时间大幅增加。到底是什么样的更新才会出现这种问题呢?我们不知道,但肯定的是一定是微软升级导致的问题,因为有些人有问题,有些人没有。用批量版的那些没有,用零售版的出现了问题,那些用零售版的一直没有更新的也没有问题。最终几乎可以追溯到到底是具体哪一个版本的更新引发了这个问题。

如果是SQL语句导致的状况,当我什么都不设置原表输出理论上应该没有问题,但实际上问题依旧。

研究到了这个程度,我知道这不是我一个人能解决的。我大概知道这是不是我们这些用户能解决的。那到底是什么问题突然触发了这个事故,得问那些负责windows系统更新的人。

用这三货做数据查询

2025年11月22日 08:02

不知道从什么时候开始,我就迷上了数据查询。

一开始只是想实现某个功能,后来发现原来实现同样东西,我用不同方法都可以做到。哪个方法更直观简便一些?我感觉Excel VBA的SQL,Power Query以及Python相比,就数据处理的方便性来说Python是碾压的,但我没有发现Python的巨大优势。问题可能在我交给Python处理的数据太少了,跟其它两个相比体现不出Python的高效。在控制Excel单元格格式方面,Python天生不如office自家的VBA。为什么我会把PQ跟VBA跟Python相比呢?是因为从Office 2019开始,PQ就算是内置的一个功能。VBA里面的SQL天生有缺陷,因为跟真正的数据库SQL相比,那就是个阉割版,有些你觉得明明可以实现的东西,在Excel VBA里好像就真没有直接的解决方案,为什么居然会这样呢?

到现在为止,我依然没有发现Excel VBA的SQL有直接的文本拼接功能。其它数据库的SQL里,那就是一个很简单的函数。Excel VBA的SQL在合并其他数据方面没问题,但一旦遇到需要进行文本拼接。我感觉除非在查询结束以后再做一个字符串的字典,否则无解。或许你会说其实我也可以直接在Excel的函数层面做这个拼接,因为用textjoin函数实际上是能实现那个功能的,但关键是如果数据比较多,既然我都在VBA里完成前面的所有,为什么最后的功能又要回归到函数呢?二者的运算速度不是一个层次的。每当我遇到文本拼接,我知道SQL是撞墙的,所以我就直接想到PQ。

PQ可以做数据分组,做文本拼接直接在高级编辑器里修改就能实现,但关键是实际上可以不用PQ,我不想用那个玩意,使用可能会有点慢还行,如果要进入到里面编写代码,那个小窗口字体无法放大,简直要逼死我这种老花。更作死的是,很多时候提醒我错误,但错误根本不发生在提醒的那个地方,不断的嵌套括号、逗号、又或者不小心带入的中文标点符号都会导致错误,找茬的过程让人挺绝望。我觉得,我还是喜欢在VBA里用SQL,其实无非就是判断加循环。在PQ里我总觉得有些很容易就能做到的事情,但是它非得用一些看上去很复杂的函数去实现。比如要根据A字段去决定B字段的数值是正数还是负数,在SQL里,一句很简单的iif就能实现,但在PQ里,你还得新建一个条件列,把条件写进去,接着把原来那个数值列删掉,再把条件列的名称改成数值列。当然你也可以直接使用replacevalue函数,但据说那个东西的执行效率反倒不如新增一列再删除一列。PQ里的函数非常多,嵌套用起来的方法更是让你眼花缭乱,也正是因为那些杂七杂八的东西太多了,反而让我觉得不如SQL简单干脆。让我很绝望的是,Access的SQL可以直接文本拼接,但Excel里的就不行,虽然二者是同一个版本的office。

当我在一个问题上钻研得越深,我就越能理解到高中时候,我的数学老师说学习数学的几个境界:不懂不会,会而不对,对而不全,全而不好。

键盘太智能

2025年11月21日 08:57

周三下午开会,周四要切换系统,到周五下午快下班的时候,我想到经常查这个数据的人还有会计。就去问了一下,他们需要哪些数据,然后我就可以在导出的表那里为他们挑选有必要的字段,没有必要的就直接不理会了。因为之前已经做了两个格式化,在做第三个的时候,我只是在之前的那个基础上修改而已,所以非常简单,从询问需求到最终出来大概只花了15分钟,同事非常惊讶。要知道前两个版本出来花了好几个小时,尤其是第一个版本,所以最后这一个只是细微的些许的变动当然显得很简单。那些需要用已有的字段做判断,得出新数据的新字段,该怎么个判断法之前我也已经考虑得很透彻了。

我觉得对导出数据用SQL做筛选或者分组合并是最恰当的,因为那个大表里的字段很多,如果用经典VBA的方法,要保留某些,要剔除某些很费劲,但是如果用SQL去考虑这个东西就很简单,我根本不需要考虑原来有多少个字段,我只需要知道我需要留下什么字段就好了。字段的排序是可以随意捣乱的,字段名也可以重命名为我想要的那个。我不知道浪潮脑子里想的是什么,字段名里面有括号有斜杠,反正就是不少不太恰当的字符。要在SQL里面引用这些字段名就得用`。这个东西之前我还真不知道,但我肯定有某些方法可以把某些特殊字符认定为某个名字而不是特殊字符的特殊含义。SQL筛选很简单,就像是点菜一样。最关键的是我得知道你要做什么菜,然后我才能为你考虑我得为你准备什么食材,那些食材应该怎么预加工。在做第三个格式化的时候,基本上所有事情都已经得心应手。

当我把这个东西交给我的同事,让她试用的时候,又发现一个新的问题了。我没有给他们配置宏大按钮,所以要运行那个宏还是用office经典的那个快捷键Alt+F8。在标准的键盘里直接按这两个就可以了,但是在某些品牌的键盘,布局是不可能光按一个键就调出F1到F12的。比如联想的台式机标配的键盘或者笔记本电脑就不行。他们默认的是那个键所对应的是多媒体。我同事的那个键盘是罗技的Wave Keys,也就是人体工程学键盘。她那个键盘默认的也是多媒体,所以当我要她按Alt+F8时候,F8根本出不来,在那种情况下,最直接的办法是按三个键,Alt+Fn+F8。联想的键盘有可能无法把F1到F12锁定为这些键原来的功能,但我确定罗技肯定可以。当我要给我的同事干这种事情的时候,她跟我说多媒体键盘那里的截图很好用。

以前的windows系统自带的截图要不全屏,要不窗口。大概好像从win10开始。win+Shift+S能调出任意选取框的截图,默认会保存到粘贴板。这个也是在我遇到了那个键盘的快捷键之后才去搜索出来的。一直以来我用的都是QQ或者微信的截图。QQ的截图是Ctrl+Alt+A,微信的截图是Alt+A。当我有截图需求的时候,这两个东西肯定有一个挂着,这两个东西除了截图以外,你还可以对图片进行各种加工,比如框选比如模糊。我的同事虽然的电脑也挂着微信,但是她用的却是罗技键盘上面的截图快捷键,也就是调用系统的截图。既然她喜欢用那个快捷键,我也没办法让她把F1到F12的功能还原出来。

在office里,Alt+F8就能马上调出宏的运行窗口,如果只有一个宏直接按回车就完了,但关键是如果遇到某些人的键盘F8不能直接出来,这显得很郁闷。我明明可以告诉她office里面找到开发工具,然后点击宏也能出那个快捷键的窗口,但我选择不告诉。因为如果她知道能用鼠标点的方式,她就不会使用快捷键。这也就是为什么明明很多事情可以很简单,他们需要点击很多次鼠标、滚动很多次滑轮才能做到的原因。

程序该考虑的我会考虑到位,但使用方法,我真的不想再为他们费心了。

实战

2025年11月20日 08:32

对系统的导出数据进行了两种形式的格式化以后,接下来我要把其中一种格式化的VBA交给同事,告诉她该怎么用。在我印象之中,每天他们报送数据的时候用的电脑装的是office软件。我这里说的报送,意思是要得出某个文字转化版本的那些人。单位是很奇怪的存在。联想电脑附带的软件是office家庭学生版的正版,另外一些系统不知道为什么一开始的时候就被格式化了,被某些人装了windows系统之后装过各种奇奇怪怪的软件,最终可能定下来的是一个不知道什么版本的wps。也不知道从哪一年开始单位就有批量买的wps,但因为我是office软件的超级粉丝,wps根本无法满足我的要求。因为wps没办法做Power三剑客。Power Pivot还好一点,我用得比较少,但是如果要对一些数据进行文本合并,SQL没那么容易,需要用字典搭配字符拼接才能实现。在那种情况下,我首选通过Power Query合并。当然用Python也能做到,但是如果某个人的电脑里面装的是office,又在2019以后,PQ内置功能,但如果要别人运行Python,还需要安装,还需要配置环境。

我没想到的是那个同事居然先拿回办公室试一下,她办公室电脑用的是wps。wps我猜她安装的版本是32位,因为我的VBA查询用了ADO+SQL,这两个东西意味着不是所有的wps都可以直接执行。即便单位买的那个wps的版本能运行宏,但是宏里面又用了SQL,这个估计就很悬,最终能不能用,可能也可以但估计得折腾一番。幸好她没有挣扎,直接拿着那个VBA文件就直冲工作地点。她第一次在办公室截图回来告诉说wps无法运行宏的时候我就下去找人,结果没找到,原来她已经直接去工作地点了。过了一阵她又跟我说运行不了,反馈出来的那个信息就是VBA脚本没有找到恰当的源文件。

我第一个反应是她导出的文件会不会文件名有一些空格没有留意到,于是我马上赶往那个地方,结果发现她的确导出了文件,但是她发现导出文件的名字跟我之前跟她说的不一样,所以她重命名了。重命名没有任何的意义,因为导出的文件名不一样,基本可以确定她导出的位置不对。当我问她是在哪里导出的时候,她自己估计也马上发现了问题所在,果然就是因为她导出的文件导出错了。

工作地点的那台电脑一次就通过VBA考验。旁边的那台电脑是一台新的联想,预装office2021家庭学生版,但是那台电脑打开VBA之后就会有一条红色的提示。正常情况下,理论上那应该是一个黄色的提醒,按确定或者允许之类就可以了,但红色的提示好像根本没办法按掉。只要按那条红色的东西,就会弹出一个网页,告诉你一些细节。一开始我没有留意,我不管那条红色直接去选项那里设置允许宏,但即便这样,这个文件也依然运行不了。我就不得不去仔细看红色那条提示对应的那个网页。发现是因为因为出于某些安全原因,系统锁定了这个带宏的文件,需要在文件那里按右键点击属性,然后再点击某个解除按钮,之后才能运行那个文件的宏,打开文件才会出现黄色的提示。所以到底是什么安全设置让那个电脑带宏的文件出现那条红色的提示呢?起码在之前我接触过的所有office里未曾遇到过。

对用宏文件的人来说,宏可能有风险,但是对我来说,宏是我自己写的,我不可能不放心。

Svelte和Sapper实战

2024年7月7日 00:31

评分

⭐⭐⭐⭐⭐ ⭐⭐⭐ 8 / 10

评论

川流的作者李大毛没有猫在群里招募为新网站写前端的人,我报名后了解到其技术栈是 Serverless 和 Svelte 和 SvelteKit。我大约在几年前在 daily.dev 上常看到大家拿 Svelte 与 React 和 VUE 对比,但也有一些认为 Svelte 也有其不足,由于当时其位列前端三大方案之后,我未作细节关注。

这几年我都没有涉足编程技术,在大体尝试 Svelte 官方例子后,得知 SvelteKit 就是之前的 Sapper,让我想到了这本书。虽然 Svelte 出现的比较晚,在营销方面也没有很多突破,但它的思路确实比虚拟 DOM 更新颖,服务端编译也为它带来了比较优势——更小的打包尺寸和更好的性能。

我相信系统性优势是可以扩大市场占有率的,同时,我也认识到 jQuery 存在的时间比想象的要长。

说到此忍不住吐槽国内的技术生态,今日还看到v2ex一个帖子,说国内技术环境常年不变 centos7 java1.8 mysql 5.7,其实不全是,常年不变的算不上以技术为竞争壁垒的公司。仅在计算机系统的软件层面构建竞争壁垒是非常困难的事情。国内某些“厂”,之所以常年使用固定的开发环境,是因为它赚钱核心并不在此(使用更新的开发平台、更新版本的编程语言、性能更高的数据库),也不想在软件研发上作小白鼠做无谓的投入。这是一种很油滑作呕的策略,只从外部吸收索取,不回报,拿着多个开源项目,自己改吧改吧生成自主掌握技术。也许商业上算成功的,但对技术社区没有实质贡献。

这本书的可读之处,不仅在于它对 Svelte 体系的介绍,更在于作者的深厚功力,可以学到一个工作三四十年的技术大拿的思维方式和对技术周期的认知。

Svelte 是否是 React 的颠覆者呢,从影响力上算不上,但它确实是一种 Smart 的范式,喜欢的人自然喜欢,我也见过太多的新技术,但 Svelte 来说,它不仅仅是前端框架中一个新的 VUE。

先补帧还是先放大

2025年11月14日 14:45

最近一直很无聊的在用AI工具做 文生图生视频 动画。线上用的豆包文生图,即梦首尾帧图生视频。豆包也有用图生视频,把首帧图倒放,然后接到即梦视频的前面。

因为豆包和即梦的视频输出是诡异的 1248x704p24fps,704甚至不能被9整除,1248÷16×9=702(根据网上搜到的结果说是为了匹配patch所以要能被32整除)。所以我在线下用了 realesrgan-ncnn-vulkan 和 rife-ncnn-vulkan 把输出放大到 1408p ,把帧率补到 60fps,然后再用 FFMPEG 重新编码到 1080p60fps。

(可灵虽然直出1920x1080p24fps,但是一个月就166个点数,非会员生成视频还要等几个小时,而且不还能多个生成并发排队,有时候生成的结果还特别像幻灯片然后补帧到的24fps。屁用没有)

这样就有一个疑问了:

是先补帧?还是先放大?


交换律?

首先第一刻板印象当然是想到了交换律,即最终结果都是1408p60fps,所以顺序并不重要。

但仔细一想,插帧是一种算法实现,缩放是另一种算法实现,这两种算法除了都是从卷积派生出来的之外,基本没啥数学关系,甚至先补帧后缩放和先缩放后补帧的1408p60fps输出结果都不一样。

所以这玩意不符合交换律。

而我其实并不太关心最终结果的质量。这俩工具目前的使用场景都是大玩具,实际生产环境也是作为玩具存在的。

我更在意的是在有限性能下,哪个前哪个后的总耗时更短,速度更快。

当然这俩玩意的算法我是没研究过,即使研究了,其在实际场景下还有多核和多线程调用的差异,在不同硬件和不同驱动下也肯定没准。

还不如在自己机器上实际跑一遍测速。


测试

所有测试中用到的视频,我上传到了B站。因为B站有二压的特性,所以所有视频素材整合到了同一个60fps的视频中。同时因为B站的限制,非会员只能观看30fps的视频,补帧效果可能看不出来。

每个测试用例的首帧图我会放到文章中。

测试用例1:AI生成的简单动画

首先准备测试用例。

我是不知道输入源的哪个因素对两个工具的性能影响最大,所以准备了两个实际素材。

一个素材偏重于更静态的图像,另一个素材则更偏重于运动场景。两个素材均是分辨率 704p 的PNG图像,共 49 帧。

当然我没有用极端测试场景(比如H.264等图形算法最常用的雪花图像,这玩意怎么缩放和补帧?),真实素材也更符合实际日常使用的结果。

输出目标均为:1408p 图像(704p的2倍),121 帧(由24fps插帧到60fps)

AI引擎和模型使用:

  • 放大引擎:realesrgan-ncnn-vulkan-20220424-ubuntu,模型:realesr-animevideov3
  • 插帧引擎:TNTwise-rife-ncnn-vulkan-20240102-frame-count-patch,模型:rife-v4.10_ensembleTrue

补帧和放大均使用目录路径作为输入参数,以排除文件系统调用和模型重复预热引入的性能限制。两个工具也均支持GPU加速所以没有单线程限制(反过来也就是说CPU和GPU在性能统计上会变得乱七八糟而没有参考价值)

存储则使用 ramdisk ,以减少硬盘读写性能的影响。

结果:

偏重静态的图像:

snap-20251022212700_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	0m15.478s
user	0m30.060s
sys	    0m0.874s

这里,如果你没有使用 Linux time 命令的经验的话,我可以简单解释一下:

  • real指的是实际用时,即真实世界时间,和你用秒表测量的数值是一样的
  • user指的是用户态的CPU时间
  • sys指的是内核态CPU时间
  • 在单核单线程硬件下,real=user+sys,但是在多核多线程场景下,每个核的CPU时间都是独立的,所以这个时间统计在现在这个场景下基本没意义。
    (解释并不精确,如果你想深入学习,建议看更详细的资料)

所以在目前这个场景下,我们只关注real这个真实耗时就足够了。

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output

计算 (49 - 1) * 60 / 24 + 1
源帧数: 49
目标帧数: 121

real	0m35.632s
user	1m27.617s
sys	    0m1.462s

放大约15秒,补帧约35秒,总计约50秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

计算 (49 - 1) * 60 / 24 + 1
源帧数: 49
目标帧数: 121

real	0m7.843s
user	0m15.536s
sys 	0m0.707s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	0m36.348s
user	1m14.572s
sys	    0m1.513s

补帧约8秒,放大约36秒,总计约44秒。

结果是 先补帧后放大 优于 先放大后补帧

偏重运动的图像:

snap-20251022214458_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	0m16.676s
user	0m30.713s
sys	    0m1.277s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output

real	0m36.721s
user	1m33.545s
sys 	0m1.513s

放大约16秒,补帧约36秒,总计约52秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m9.753s
user	0m20.995s
sys	    0m0.850s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-out/ -v

real	0m37.459s
user	1m16.351s
sys	    0m2.180s

补帧约10秒,放大约38秒,总计约48秒。

结论是:

  • 高动态的图像的确为插帧带来了更多压力
  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

很奇妙的是不论先后顺序,第二步的耗时都差不多。


测试用例2:AI生成的长动画

实际只测试两秒钟(49帧-121帧),打算再测一个输入时长更长的,看看能不能把性能差距拉得更开。

同样是两组,一组偏静态,另一组偏动态。

这回输入均为10秒钟24fps,241帧。目标仍是 60fps,601帧。

(注:这所谓的10秒其实是两个5秒钟视频贴在一起的,第一个视频使用即梦生成,首尾帧相同。第二个视频使用豆包生成,根据关键字调整了动作幅度)

结果:

偏重静态的图像:

snap-20251024222139_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m9.580s
user	2m21.161s
sys	    0m3.010s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

计算 (241 - 1) * 60 / 24 + 1
源帧数: 241
目标帧数: 601

real	2m45.014s
user	7m9.693s
sys 	0m3.845s

放大约70秒,补帧约165秒,总计约235秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m33.821s
user	1m11.185s
sys	    0m1.258s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m52.675s
user	5m57.794s
sys	    0m8.370s

补帧约34秒,放大约173秒,总计约207秒。

偏重动态的图像:

snap-20251024221945_nowatermark

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m10.573s
user	2m24.758s
sys	    0m2.371s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

real	2m49.481s
user	7m27.740s
sys	    0m4.279s

放大约70秒,补帧约170秒,总计约240秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m39.217s
user	1m32.454s
sys 	0m1.594s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	3m0.312s
user	6m19.679s
sys	    0m5.674s

补帧约40秒,放大约180秒,总计约220秒。

结论是:

  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

测试用例3:AI生成的现实场景视频

这里得偷懒了。缩放工具 realesrgan 本身的默认模型 realesrgan-x4plus 对现实场景的缩放效果更好,但是其仅支持4的整数倍缩放,在现在这个场景下比较浪费。
同样 rife 这边也有更适合现实场景的补帧模型,但我也打算偷懒。

所以模型将仍然使用 realesr-animevideov3 和 rife-v4.10_ensembleTrue 。

视频输入样本,偏静态样本仍为即梦5秒+豆包5秒,但偏动态样本这回使用即梦生成的10秒,因为偏动态的内容,现实场景首尾帧相同实在太诡异了,而且即梦和豆包生成奔跑内容的视频效果非常差,经常就变成单腿跳。

结果:

偏重静态的图像:

snap-20251105235631_nowatermark

time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m9.756s
user	2m22.813s
sys 	0m2.415s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

real	2m49.322s
user	7m21.308s
sys	    0m3.992s

放大约70秒,补帧约170秒,总计约240秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m37.079s
user	1m27.702s
sys	    0m1.498s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m51.899s
user	6m0.976s
sys	    0m4.820s

补帧约37秒,放大约171秒,总计约208秒。

偏重动态的图像:

snap-2025-11-08-9101

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m10.753s
user	2m24.943s
sys	    0m2.365s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

real	2m49.142s
user	7m16.057s
sys	    0m3.969s

放大约70秒,补帧约170秒,总计约240秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m38.306s
user	1m29.791s
sys	    0m1.516s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m49.268s
user	5m55.462s
sys	    0m4.760s

补帧约39秒,放大约170秒,总计约209秒。

结论是:

  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

测试用例4:真实现实场景视频

这个源不太好找,现在手里没有24fps的摄像机这玩意,目前常见的摄像设备都是30fps,60fps,120fps,240fps,960fps的。

所以这里将测试用例调整一下。

首先,源视频是拍摄的一段1080p60fps的视频,再缩小成704×1252,再把1252剪成1248。

然后分为两个策略:

  1. 去掉所有偶数帧,这样源就变成30fps了。虽然当然也可以直接拍30fps的视频,但有个补帧缩放后有个对比也算不错。
  2. 使用比较主流的减帧策略(丢弃每5帧中的第2、3、5帧),将60fps视频减至24fps。

(当然像OpenCamera这种App也支持拍摄24fps视频,但是场景过于小众了)

这样做的目的是:rife 的非整数倍补帧, 24补到60是2.5倍,只有奇数帧会被保留,偶数帧在算法里被用掉之后就被丢弃了。

相关日志:

/tmp/ramdisk/rife-tmp//0-000001.png /tmp/ramdisk/rife-tmp//0-000002.png 0.000000 -> /tmp/ramdisk/rife-output//00000001.png done
/tmp/ramdisk/rife-tmp//0-000001.png /tmp/ramdisk/rife-tmp//0-000002.png 0.400000 -> /tmp/ramdisk/rife-output//00000002.png done
/tmp/ramdisk/rife-tmp//0-000001.png /tmp/ramdisk/rife-tmp//0-000002.png 0.800000 -> /tmp/ramdisk/rife-output//00000003.png done
/tmp/ramdisk/rife-tmp//0-000002.png /tmp/ramdisk/rife-tmp//0-000003.png 0.200000 -> /tmp/ramdisk/rife-output//00000004.png done
/tmp/ramdisk/rife-tmp//0-000003.png /tmp/ramdisk/rife-tmp//0-000004.png 0.000000 -> /tmp/ramdisk/rife-output//00000006.png done
/tmp/ramdisk/rife-tmp//0-000002.png /tmp/ramdisk/rife-tmp//0-000003.png 0.600000 -> /tmp/ramdisk/rife-output//00000005.png done
/tmp/ramdisk/rife-tmp//0-000003.png /tmp/ramdisk/rife-tmp//0-000004.png 0.400000 -> /tmp/ramdisk/rife-output//00000007.png done
/tmp/ramdisk/rife-tmp//0-000003.png /tmp/ramdisk/rife-tmp//0-000004.png 0.800000 -> /tmp/ramdisk/rife-output//00000008.png done
/tmp/ramdisk/rife-tmp//0-000004.png /tmp/ramdisk/rife-tmp//0-000005.png 0.200000 -> /tmp/ramdisk/rife-output//00000009.png done
/tmp/ramdisk/rife-tmp//0-000005.png /tmp/ramdisk/rife-tmp//0-000006.png 0.000000 -> /tmp/ramdisk/rife-output//00000011.png done
/tmp/ramdisk/rife-tmp//0-000004.png /tmp/ramdisk/rife-tmp//0-000005.png 0.600000 -> /tmp/ramdisk/rife-output//00000010.png done
/tmp/ramdisk/rife-tmp//0-000005.png /tmp/ramdisk/rife-tmp//0-000006.png 0.400000 -> /tmp/ramdisk/rife-output//00000012.png done

所以这次测试用例是:

  • (类)原生30帧补到60帧
  • (由2:3策略减帧的)24帧补到60帧

模型也同样使用 realesr-animevideov3 和 rife-v4.10_ensembleTrue 。

偏静态与偏动态不做区分了,本身真实场景,除非是使用三脚架固定相机拍摄,否则也没啥偏静态的场景,大多数都是动态且镜头抖动巨大,个人拍摄的内容还有严重的低光照问题。

(说白了还不是因为根本没有可用的视频素材)

结果:

snap-2676

30帧补到60帧

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m24.551s
user	2m57.076s
sys	    0m2.912s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/

计算 (301 - 1) * 60 / 30 + 1
源帧数: 301
目标帧数: 601

real	2m43.455s
user	7m6.708s
sys 	0m3.595s

放大约85秒,补帧约164秒,总计约249秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m43.132s
user	1m52.735s
sys	    0m1.387s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m48.691s
user	5m56.668s
sys	    0m5.217s

补帧约43秒,放大约169秒,总计约209秒。

24帧补到60帧

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-input/ -o /tmp/ramdisk/rife-tmp/ -v

real	1m7.531s
user	2m21.199s
sys	    0m2.532s

$ time ./2_rife.sh /tmp/ramdisk/rife-tmp/ /tmp/ramdisk/rife-output/


计算 (241 - 1) * 60 / 24 + 1
源帧数: 241
目标帧数: 601

real	2m45.471s
user	7m11.694s
sys	    0m4.140s

放大约68秒,补帧约165秒,总计约233秒。

$ time ./2_rife.sh /tmp/ramdisk/rife-input/ /tmp/ramdisk/rife-tmp/

real	0m42.656s
user	1m52.408s
sys	    0m1.312s

$ time /mystorage2/tools/realesrgan-ncnn-vulkan-20220424-ubuntu/realesrgan-ncnn-vulkan -n realesr-animevideov3 -f png -s 2 -i /tmp/ramdisk/rife-tmp/ -o /tmp/ramdisk/rife-output/ -v

real	2m46.998s
user	5m53.404s
sys	    0m5.189s

补帧约42秒,放大约167秒,总计约209秒。

结论是:

  • 先补帧后放大的总耗时 小于 先放大后补帧的总耗时

测试总结

  • 所有测试用例的场景下,先补帧后放大的总耗时 总是小于 先放大后补帧的总耗时

相关视频

【AI工具研究之:先放大还是先补帧】 https://www.bilibili.com/video/BV1yoCtBFE1L/?share_source=copy_web&vd_source=bc6d7e4cd2c1f2bba38d19773d2bc1fc


结尾

这几组测试用例其实都不严谨,没有参考官方的建议在不同场景下使用不同模型,而且因为这是我的个人电脑,里面跑的乱七八糟东西特别多,CPU和GPU在跑用例的时候偶尔也会被其他应用调用,所以每次跑的时候精度都一般,误差很大。我本来也只是跑着玩的,根本没多次测试然后取平均值。好孩子不要学。

本次测试结果仅代表两个工具以及对应模型在本人主机硬件环境上的性能测试结果,不对其在其他场景下的性能负责。请勿将本文中的结论用于生产环境。

The post 先补帧还是先放大 first appeared on 石樱灯笼博客.

尝试把树莓派1和小米盒子1改造成游戏机,但是失败了

2025年10月18日 14:28

本文大概只是想讲讲我手中这块树莓派1B的使用经历。小米盒子1只是附带。


我玩树莓派那些事

我2013年的时候买了一块树莓派1B的板子。那时候我只有一台2007年买的奔腾T2130的笔记本,跑虚拟机比较吃力,而且由于是定制显卡所以Linux装上后显卡驱动不起来,这些问题导致没法在家(北京的出租房)用Linux。想要用Linux就只能在公司用公司的服务器。而且由于公司的系统是一个高度魔改的CentOS,公司改了相当大量的内核代码并且安装了大量跨版本的依赖包,只能用来学习Linux基础,嘛毕竟是2004年成立的公司,产品严重依赖Linux内核功能所以就只能一直往里面Merge最新功能,直到后来实在是塞不进去了,全部推倒了从新发布的CentOS7重新搞。

当时树莓派也不贵,就买了一块。说实话没怎么用。因为我没买任何外设,所以所有功能都是纯跑在CPU上的,32位的arm 700Mhz性能基本上只能验证功能上的可行性,一点性能都没有。

screenshot_on_b85m_by_flameshot_at_2025-10-17_19-17-39

IMG_3336

IMG_3337

IMG_3338

IMG_3339

IMG_3342

IMG_3344

IMG_3345

IMG_3346

IMG_3347

IMG_3348

IMG_3349

IMG_3350

(当然,想学 Linux 这个是借口)

当时手中还有个大学时买的罗技C270摄像头(15年了,这玩意到现在还没停产),能拍720p。刚巧当时出租房和公司都用的电信通/宽带通的网络,开DDNS可以用(不知真假的)公网IP互联。在公司摸鱼的时候就用SSH连上家里的树莓派,然后再开小飞机做代理就能完全访问家里的局域网(公司是有上网审计的,但公司主营业务之一也是上网审计,只要不干违法的事情且不影响公司其他同事上网就没问题)

IMG_4279

连上后瞎搞mjpg-streamer,当时调通后拿到的第一张照片刚好是放在窗台上对着窗外拍到的一位路过的美女。(然而当时的照片已经找不到了)

对应 mjpg-streamer 的内容可以参考十多年前的这篇老文章《使用树莓派制作近距离遥控摄像机(无线网卡+摄像头,手机或平板等移动终端控制)》,不过放在现在已经没什么参考意义了。

后来还把树莓派和移动电源和摄像头还有无线网卡组合到一起,把摄像头绑在书包后面,骑自行车上班时拍了一路。

【[远古画质] 北京,2013年某月】 https://www.bilibili.com/video/BV1U9W7zkEm4/?share_source=copy_web&vd_source=bc6d7e4cd2c1f2bba38d19773d2bc1fc

(请忽视评论区那些自嗨的精神病)

当年我还对视频编码什么的一无所知,就只留下了这么一个编码格式是H.262的远古画质的视频。

当时想调通这一套可是费劲。没有接入点的情况下,想把控制终端和树莓派连起来就很麻烦。而且树莓派的电路设计一直超级缺心眼,它的供电设计,一直没有优先保障主板,且USB接口一直有反相供电的问题。插拔USB设备造成的电压波动基本上100%会导致树莓派重启。输入电流也被压在500mA(201x年USB供电基本都是1A了),这就导致像无线网卡或摄像头这些用电大户(?)在工作的时候可能导致树莓派自己供电不足而重启。

为此专门买了一个同时有外置电源和反相供电屏蔽的USB Hub。这玩意可是非常稀有了。

screenshot_on_b85m_by_flameshot_at_2025-10-17_19-38-29

IMG_6866

用这玩意也就意味着没法插着移动电源用。

IMG_20140503_001825

2013年去广西出差的时候,带的公司的笔记本,散热风扇坏掉了。干活办公开SSH和Word/Excel没事,但是玩游戏或者看视频几分钟就直接蓝屏重启。恰巧客户那边网络炸了,所以一个星期我都只能在酒店发呆。当时就带着树莓派,装了个 OpenELEC 系统,用酒店的电视把《刀剑神域1》全看完了。

DSC_0195

DSC_0202

(之所以是 OpenELEC 是因为,Raspbian系统需要4GB SD卡,而3DS原装的SD卡是2GB的,落灰中。而 OpenELEC 只需要 2GB 的空间就可以安装。当然另一个理由是 Raspbian 图形界面实在太卡)

当时还买过一张跳舞毯。厂家给的光盘当然只包含一个 Windows 32位的游戏端,实际上就是个 Stepmania 汉化版。Stepmania本身是开源的,但是当时官方也只提供 64位 的 Linux 客户端。我当时对交叉编译一无所知,完全搞不懂,就只好把源码都复制到树莓派上然后直接在上面编译,结果编译了一个通宵,第二天早上屏幕上还在滚屏编译,实在是等不起,这性能可能就算跑起来了也够呛能运行(更别提还要跑在图形界面上),就放弃了。(后来在x86的Linux笔记本上编译,没报错直接成功编译并且成功运行,所以说代码里并没有int64这种必须用64位CPU才能编译运行的代码)

screenshot_on_b85m_by_flameshot_at_2025-10-18_01-05-57

再后来配套的亚克力板磕坏了,想要再买发现买不到了,网上只有B+外形的外壳了(后续的树莓派外壳基本也都是B+的)。我最后就只能用个饼干盒子套着用。就开始落灰。

IMG_20150512_152030_hongmi1

IMG_20150512_152103_hongmi1

IMG_20150725_110321_hongmi1

再再后来换了工作,我拿着树莓派当作一个远程控制设备插在公司服务器上当远程控制,即我远程登录到树莓派上模拟用户操作,这样我就不用蹲在服务器旁边干活了。结果老总为了要用墙壁上的电源插座给手机充电,直接把树莓派拔下来扔杂物堆里了。

(除非你已经为领导创造过巨大的收益,否则任何领导没见识过的努力都是狗屎)

再再再后来又换公司,公司搞高度网络劫持,然而用的是一个及其白痴的上网审计,导致大部分HTTP网站都访问不了,那时候HTTPS还没普及,导致想在网上搜资料就只能手机开热点,搜完了再切回公司网络。于是又翻出来插在出租房的联通宽带上,当时还有公网IP,在浏览器里写好规则,在公司翻到家里上网。尤其是那个白痴上网审计只会疯狂的主动探测端口的HTTP协议,小飞机的日志里全是主动探测告警,我还得专门安装个旧版的不会自动封禁主动探测的小飞机。

后来还买过扩展版和传感器模块(温度气压高度光线,但是没有湿度)。没学的时候觉得是魔法,树莓派社区吹得及其玄幻,学会后发现就是从对应API读数据,而且因为都是用Python写的,代码质量还稀烂,所以被社区吹得越来越玄乎。当时我还没转型做开发,没搞明白PHP怎么去抠系统级的API(事实上读不了,PHP-FPM不是干这个的,PHP-CLI又不是跑在Web上的,想以正经方式拿系统信息还是得走系统指令,那就和调用Python没区别了),且想在树莓派1上跑HTTP服务非常吃力,就更别提还没火起来的NodeJS了。实际上这屁事只用Bash应该就能做,只要能处理好从API中提取出来的二进制数据然后转换成人类可读的数据,然后再排版就好了。当然,Bash处理二进制数据和排版都超级麻烦,理所当然社区没人做。去他妈的国内开源社区

IMG_20151019_225300_MiPad

IMG_20151025_002219_MiPad

IMG_20151223_221943

IMG_20171030_192817

后来还买过 315M433M无线模块,想用树莓派做物联网。但是最后因为精力有限,买回来之后一直在落灰,一点都没动过。(后来物联网的发展趋势也是一坨狗屎,一帮傻逼搞紫蜂全死了,最后变成WiFi是亲爹,断网就报废,电饭锅都物联网人工智能)

screenshot_on_b85m_by_flameshot_at_2025-10-18_01-05-26

IMG_20151103_233125

再再再后来我也不在那个公司工作了,北京联通也不再分配公网IP了,手里这个树莓派又开始落灰。我也想过再利用,尝试把这树莓派做成同步网盘(大容量SD卡和U盘已经很便宜了),但是这设备的IO性能是在不够,虽然可以插外置硬盘,但兼容一代的硬盘盒也不存在,更别提之前说过跑Apache和PHP都很吃力了。

最后这树莓派1就正式落灰了。


年轻的时候憋坏了

我这个人,上学的时候憋坏了。早年间上大学从哈尔滨到西安,火车单程42个小时,后来提速后36个小时,但晚点又是日常。当年最多只能用个不到2寸的诺基亚3110c玩马里奥医生,因为屏幕小且九宫格键盘难操作且模拟器限制,只能玩这一个游戏,其他游戏都玩不了。(我也纳闷这大学4年我为什么不买一个俄罗斯方块机呢)

毕业工作后我就买了台3DS,买了两块移动电源。

后来买了台式机之后,老笔记本也开始落灰,我就装了个RetroArch又当作游戏机,在有大电视的合租房客厅里放了一年。结果是没玩,HDMI线超过2米之后要不就是价格登月,要不就是直接花屏。

IMG_20160124_160039_SHOT2SHOT1

而作为控制器的手柄,USB连接线同样没法超过两米;蓝牙又莫名其妙的高延迟。总之怎么样姿势都不舒服。

再后来有了新笔记本(就是那个后来自燃了的戴尔灵越7380),PS2模拟器的性能甚至比有GTX1080独显的台式机还好,经典掉帧场景在这个核显笔记本上竟可以全程60帧。虽然有着8代i7,但跑分和x264这笔记本(都因为散热问题)输给4代i7的,却在这个特别的场景下略微获胜(但是屁用没有,过场动画掉几帧根本不影响游戏性)(更别提Win10会给更低端的模拟器造成明显抽搐的问题,而且3DS模拟器在4代U上能稳定跑,在这破本上启动都费劲)。但最终结果也是一样的,一根又粗又硬的HDMI线扯着笔记本,笔记本还要再插着电源适配器,然后一根USB线连在手柄上,怎么样都不舒服。再再后来这破笔记本自燃了,这场景也自然没有了。

(所以我还是觉得,同样都是走2.4GHz频段,在无线键鼠和蓝牙手柄都出问题的情况下,游戏机无线手柄能做到延迟无感知是一种魔法。当然我也没钱去专门买一个无线手柄适配器,毕竟不适应需求,PC游戏还是坐在电脑显示器前玩,不需要无线)


煎熬后想把树莓派1改造成游戏机

前几年过春节都是在自己家熬夜的,用自己的电脑打一宿的TF2或者100oj。

去年在外公家过夜,但是下午的时候回家了一趟,然后晚上徒步走了3公里到街机厅,玩跳舞机一直玩到人家除夕闭店。

今年过春节时,则是在一个我不怎么熟的大人的朋友家过的。

纯煎熬。

能玩的东西就只有手机和3DS。

倒不是说3DS游戏性不行,而是我在嘈杂且陌生且随时会被打断的环境下,玩不下去那种期望有沉浸体验的游戏。

结果就是一个除夕,歪坐在一个陌生的沙发上,把魔法气泡手游的无尽之塔打到实在打不过,然后又在3DS上打了半宿的PPT(魔法气泡俄罗斯方块),最后结果是坐着落枕了。

邻居家当然是有电脑和电视的,只不过电脑是人家工作用的,别人的工作设备我基本不想碰;电视全是在播放春晚,根本看不得。

那一晚真的是纯煎熬。好在第二天大人们晚上全跑去歌厅唱歌了,我自己回了自己家,才算解脱。

再后来整理物品的时候又翻到箱子里落灰很多年的树莓派1和小米盒子1(还有2台小霸王),遂有了把这俩玩意改造成游戏机的想法。

两台小霸王机当然也是能用的,我还有一张400合1游戏不重复的游戏卡,基本上涵盖所有热门FC游戏。但这些年来我一直是在NTSC模式下以60fps的帧率玩FC的,如今再回到PAL模式的50fps,就显得特别的不适应。

为什么自己年轻的时候没感受到这么大的差异呢,我高中期间是同时玩模拟器和小霸王的啊。


把树莓派1改造成游戏机,但是失败了

思路有多个:

  • 安装个有图形界面的操作系统(Raspbian),然后在里面跑独立模拟器或者RetroArch。
  • 安装 OpenELEC ,然后在里面的 XBMC中 安装模拟器插件
  • 安装 Lakka 或 RetroPie 这种专门(只)跑 RetroArch 的操作系统

首先抛弃方法2。这个方法本来是我道听途说的,真实性不高。OpenELEC 已经停止维护太久了,XBMC也早就改名 Kodi。如今肯定是连不上那古董的插件服务器,就不费那劲了。

事实上现在想在网上搜树莓派1的资料已经很少了,就更别提树莓派基金会搞了一堆幺蛾子之后名声都臭掉了,现在还做树莓派资料的基本都是 外国营销号,没啥正经玩意,搜什么关键字都是一群人复制粘贴的垃圾(有一种百度比谷歌遥遥垃圾的领先感)。本身就追求开放的老粉肯定不会在这一根歪脖树上吊死,直接去 Linux on Arm 这种大领域玩去了。

用了几个AI工具搜了一下(百度、豆包、必应、秘塔,排名不分先后),基本上给出的答案都类似:

screenshot_on_b85m_by_flameshot_at_2025-10-17_21-58-02

screenshot_on_b85m_by_flameshot_at_2025-10-17_22-35-22

看起来还行?

Raspbian 方案

首先刷了 Raspbian 试了下。甭说模拟器了,只要进图形界面,分分钟整个系统卡到无响应。我专门是了下最新版的 Raspbian 和 自己电脑里保存的 2013 年的旧版 Raspbian ,结果是一样的。

这个配置跑一个图形界面操作系统实在是太勉强了,再在上面跑其他东西,还是算了。

RetroPie 和 Lakka

这俩方案我已经记不清前后顺序了。记忆里2013年的时候用过其中一个(另一个当时肯定没诞生),只记得当时那个很漂亮的仿PS3/PSP的系统界面(因为邻居家有台PS3)。

现在在装回来,只感觉到莫名其妙的超级卡顿。

RetroPie 方案

其中 RetroPie 又叫 EmulationStation ,看着很像是对 RetroArch 的重度套皮。不仅如此,所有对非模拟器的设置,全部都会先退出这个图形界面,然后调用Raspbian提供命令行风格的配置界面,配置完成后再重新启动 EmulationStation。这一套白痴操作下来,整个系统直接就炸了。

DSC_8108

屎山设计。

Lakka 方案

Lakka 则简介多了,看介绍,Lakka应该是直接把 OpenELEC 减掉大部分功能,只保留图形功能支持,然后在里面启动 RetroArch。

和 RetroPie 不同。RetroPie 是做加法,屎山;Lakka 是做减法,仅保留需要的内容。

缺点就是需要基于RetroArch之外的第三方功能基本没戏(但是把Samba这种功能塞进RetroArch是有可能的)。

Lakka跑起来后,首先是着跑 FC/NES,结果是卡顿得不行。

除了QuickNES核心之外,其他模拟器核心都是卡到爆炸,60fps最多只能跑到一半,30帧。

DSC_8111

这跟AI给出的答案完全对不上。还 SFC/SNES呢,连 FC/NES 都不行

试着给树莓派超频,结果是只要动树莓派的频率设置,就完全不启动。超频失败

最后勉强用 QuickNES 跑起来松鼠大战1,能将就着维持到60fps。

把耳机接上显示器/树莓派之后,又发现根本没声音,看了一眼,发现音频输出是null。手动把音频输出更改为 HDMI 或者 3.5mm 之后,游戏瞬间又卡得没法玩了。

RetroArch 的小插曲

当年在树莓派上跑RetroArch,也是我第一次RetroArch这个应用的渠道。

后来也想过在旧笔记本上安装这个操作系统,但是旧笔记本的性能可以跑Ubuntu这种功能正规操作系统,性能都绰绰有余,没必要专门安装专用操作系统,直接再在Ubuntu上安装RetroArch就好了,但是玩瘾没那么大,想玩直接上台式机,旧笔记本大部分时间在落灰。

再后来把整体操作系统环境从Win7迁移到LinuxMint时,在笔记本上使用过一阵RetroArch,结论是: RetroArch安装在专门用于游戏的机器上,或者给无经验者作为综合模拟器使用,用户体验还行;但是对于有经验的用户,在PC上使用窗口环境的模拟器的用户体验更棒。

于是之后再也没用过 RetroArch 玩游戏。

OpenELEC

本来没指望再用 OpenELEC 的,但是心理很别扭,总觉得以前不是这样的。

把 OpenELEC 重刷进去,发觉连操作菜单都卡顿得不得了。每个选择操作都能卡顿1秒以上。

啥情况?CPU缩肛了?

按理说菜单这些内容都是加载到内存的,就算SD卡因为放置太久有IO性能问题了,也不至于影响到菜单操作。

选了个 H.264的视频,播放起来倒是很顺畅,但我又用不着这玩意看视频。(尤其是现在大部分视频都是Webrip或Web-DL的,都需要手动选字幕,旧版的OpenELEC字幕能力太弱了,更别说操作还这么卡顿)

DSC_8112

DSC_8113

我电脑里当然是存着2013年的 旧版 OpenELEC 的。

刷了当初的旧版,依旧的性能问题。

看来树莓派是指望不上了。

想当年家里亲戚有过一台从单位搬回家的1988年产的 COMPAQ 486,只有486MHz主频和16MB内存(MMX指令集都没有),在DOS下用Nesticle模拟器也是能玩大部分NES游戏的(只要Mapper支持就行)(在Win95下开声音会掉帧)。

(暂时不想为了验证是否是SD卡的问题再买新的SD卡。手里的旧卡都一堆了,线上在用的只剩下3DS的卡和一个相机的卡,也都是偶尔开机)

(事实上固态存储长期不通电不擦除不读写导致性能下降的问题目前很严重且无解。PC端的冷数据还是用机械硬盘或者光盘存储更安全,SSD只适合做系统盘。但是这个情况在移动设备和移动存储上怎么做都绕不开)


小米盒子1

与树莓派1装在一个袋子里的还有个小米盒子1。

IMG_6867

IMG_6871

IMG_6876

话说小米这破品牌,当年我竟然还因为他曾把一个停产的产品在网站上多放了几个月页面,就夸了一下,当时绝对是脑子没有被门挤出屎。

(都是年轻时犯下的错)

小米盒子1这玩意,配置可比树莓派高太多了。

screenshot_on_b85m_by_flameshot_at_2025-10-17_22-04-44

(纸面参数甚至比我的旧笔记本还高)(但是别忘了这破玩意是精简指令集)

于是也想拿出来试一试。

思路很简单:小米盒子1内置的是魔改的安卓4.4系统,所以只要:

  • 安装安卓版本的 RetroArch 或其他模拟器
  • 使用任何可行办法将游戏ROM复制到小米盒子中,或使用USB OTG访问U盘
  • 使用内置蓝牙模块与PS4手柄DS4配对连接,或使用 USB OTG 有线连接PS4的DS4手柄

首先用遥控器把小米盒子1重置到出厂状态,然后连网,希望通过网络把文件复制到小米盒子中。

结果,只要一连网,小米盒子1就炸了。整个操作界面强制更新到了一个作坊风格的净是推广内容的界面,所有功能入口都没有了。用文件管理器,所有APK文件均被提示禁止安装。

DSC_8106

没办法只能用遥控器重新重置。

这回用USB OTG插U盘把好用的文件管理器和RetorArch安装包复制到小米盒子上,然后安装。

然后尝试连网,期望通过自己安装的文件管理器把游戏ROM复制到小米盒子上。

(之所以一直要连网,是因为 RetroArch 默认不带任何模拟器核心,需要连网才能下载对应的模拟器核心才能运行)

结果连网之后,不仅界面炸回山寨风格,而且隐藏了所有应用的入口,刚才安装的文件管理器和RetroArch在界面看不到了,完全被隐藏。

没办法只能再次用遥控器重新重置。

这回决定完全不连网,RetroArch的问题先搁置,大不了等会在路由器把抓包把小米盒子的所有网络请求全封掉,只放行 RetroArch 的请求。或者干脆不用 RetorArch,使用其他独立模拟器。

然后尝试用小米盒子的蓝牙配对手柄或者键盘,结果是:小米盒子除非小米自己品牌的外设之外,其余任何设备都不识别。

最后直接把手柄插在USB OTG上,依旧不识别。

封闭的垃圾!!!


开放的东西越来越封闭

本身表面上树莓派这玩意是个很新奇很开放的东西,但是实际上树莓派基金会是由博通建立的,芯片也是一直用的博通最便宜的垃圾。本身博通这公司有多烂就不用解释了。

只是没想到 卡片电脑 这个概念能在那个时间段突然爆发。之后树莓派除了换了几代SoC之外基本没任何改良,但由于名声在外,其他同类型产品都没能撼动这个破烂的地位。

然而树莓派5登场后,卡片电脑这个概念终于或许是大抵确实是好像死了。

天下苦 Intel x86 久已,但 arm 却不是来拯救大家的。

很可惜资本主义下,开放指令集根本没法发展。

没钱寸步难行。

而像小米之流的更是打着开放的名义把用户当牲口,成功培养出了很大一批的“有问题就刷机”但实际上只会在特定网站上下载自己都不知道里面是啥玩意的东西往手机里装的年轻韭菜。自由即吃饲料,自由即当牲口。

vlcsnap-2025-10-18-01h22m50s403

vlcsnap-2025-10-18-01h25m28s409

看手里一堆一堆的塑料电子垃圾,最后的结局都是换个5块钱的不锈钢铁盆。

“我们”是商品。

The post 尝试把树莓派1和小米盒子1改造成游戏机,但是失败了 first appeared on 石樱灯笼博客.

Forgejo及其Action自部署简明教程

2025年7月25日 22:00

前几天刚搭好了自己的 Forgejo 私有 Git 服务,之后出去玩了几天一直没动它。正好有朋友问起如何部署 Forgejo 及其 Actions 支持,发现网上相关资料不多。最近天气炎热,我也正宅在家,就抽空整理了这篇部署教程,希望能帮到有同样需求的你!

❌