@msg7086 #42

日常 8 核够用的话，那就该拼：单核性能、多核能效、待机 / 低负载时功耗控制了。。

这样 AMD 改进方向还有很多了，即使是 7840HS 应该也就《单核性能、28W TDP 时能效比》两项刚能打赢 🍎 M1 的水平。。（数据见下）

真用起来，多核性能还是不够。像前几天展示给你的那样，x265 veryslow 压视频，视觉无损减少 75 ~ 80% 体积，🍎 M1 压一年也才处理 5TB 。。

---

我有个 6900HX 小主机，Ubuntu 25.04 待机整机稳定 7W 。Win11 待机时至少 8 ~ 9W ，且经常跳动十几甚至几十 W ，很不安分。。

Ubuntu 上用 clang 20 编译 svt-av1-psy 3.02 （ gcc 编译性能慢 10%），再转码同一视频，来对比 🍎 M1：

- 15W TDP 时多耗电 32%
- 28W TDP 时多耗电 15%
- 35W TDP 时多耗电 24%
- 45W TDP 时多耗电 42%
- 54W TDP 时多耗电 60%

对比 r23 功耗曲线，同功耗 6900HX 应该比 7840HS 差 20% 性能。所以 7840HS 能效比最高时也只比 🍎 M1 省电 5% 这样。。

还以为 x86 复杂指令集，能在视频编码这种复杂任务里拉开点优势呢。。

再不努力，等 🍎 逐渐完善 arm 应用游戏生态（ M4 1650 级别 GPU 水平也不错了），高通发哥也能分杯羹，消费端 x86 就真要没落了。。

@msg7086

没有 Intel 上压力，摆烂了呗。。哪有啥不知新产品咋出的。。

🍎 Mac mini M2 刚出一年，🍎 M4 就出来了，性能提升近 60%。。6000 元 M2 一夜掉价到 2500 。。

咋不见 7840HS 刚出一年，HX 370 也来猛猛提升性能，价格不升反降，7840HS 再来波大降价呢。。

现在 🍎 Mac mini M4 抢了几十万台 Win 小主机市场，希望能给 AMD 上上压力吧。。

改进方向多的是啊，单核差 🍎 M4 很远吧？多核性能、能效比也不如 🍎 M4 吧？低负载时低功耗低噪音？待机时 2W 功耗提高笔记本续航？

新品也和 🍎 一样搞统一内存，便宜硬件没了，只剩个 x86 生态护城河了。。

@gzlock AMD 还不算摆烂吗？

两年前 2000+ 价位 7840HS ，今天还是这个价

🍎 M4 都比一年前的上一代，提升 60% 性能，内存提升 100%，价格降低📉 20% 呢。。

@julyclyde #113 请教一下，为啥会丢数据呢？（攒几百事务落盘，再结束这几百个 commit / 事务）

还是说《用户只要发了交易请求，就算处理过程中数据库 / 系统崩溃，服务器也必须处理成功！不接受 rollback ！即使是可串行化级别事务也不行！》？

用户为啥不能接受《交易失败，您的资金一切正常，请稍后重试》呢。。

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

@codefun666 你把所有核心都用来跑整个测试的话，2696 v3 比 11900k 快多少分钟呢？

@datocp #13 都追求性价比了，电费、维护费等肯定也要算在内呀。。

你这是整机待机 70W ？还是整机满载也 70W ？总计用电是计电插座实测的吗？

@julyclyde #109 你说的是《 commit 后，攒几百再落盘》吧

我意思是，数据库应该提供《 commit 时，等待积攒一批事务，再落盘，最后才结束事务》特性，既《确保数据完全持久化》，又《平摊落盘成本，尽可能降低每事务延迟》的。。



@scegg #110 提供上一行的功能，会有啥问题吗？

sql server 不也允许《不同事务有不同持久性：完全持久（ commit 时，积攒一个落盘一次）、延迟持久（ commit 后，积攒一堆落盘一次）》吗？

再多加一个《延迟完全持久（ commit 时，积攒一堆落盘一次）》不算过分吧。。

特别地，《延迟完全持久》配置为《最多积攒一个》或《最多等待 0 秒》，就退化成《完全持久》了。。

感觉没啥问题呀。。

@songray #13 比 7950x 板 U 便宜了 800 块呢。。而且满载 128W ，散热要求低，这里也能省些钱出来。。实在担心质量的话，用三年，之后应该能半价卖出？

（唉，三年前 2000 元 6900HX 迷你主机，现在二手都还要 1400 这样呢。。不知 7840HS / 8845HS 系列啥时候能猛猛降价，2899 元 Mac mini M4 的压力都还是太小了。。https://i.imgur.com/krir4IG.png ）

如果之后一直用这种 MoDT 板，买笔记本内存也没啥吧。。700 元 48G 英睿达 ddr5 5600 ，应该够用吧。。

@julyclyde #102 数据库的事务日志。。是啥样的？ commit 后，每秒刷新落盘到磁盘上？

那还是解决不了楼主说的《 commit 后，落盘前，数据库/系统崩溃，数据丢失》呀。。



@scegg #106 《要求事务完全持久化》肯定是数据库基础功能。连几百 KB 的 SQLite ，甚至在 20 年前都做到了。。（ PRAGMA synchronous = FULL ）

关键是数据库有没有采取措施，既保证《完全持久化》，又降低每个事务的持久化时间。。

每次 commit 都落盘，会很慢。积攒一堆事务再落盘，可以平摊成本。

但 sqlserver 文档里没看到类似方法及配置选项？（如：最长等待 0.1 秒就落盘现存事务；最多积攒 1000 个事务 / 1MB 数据页就落盘；……）

@scegg 就算磁盘保证实际写入一定完成，也不能解决楼主《提交事务后，每秒落盘前，数据库/系统崩溃，数据丢失》问题吧。。

还是得在 commit 里，落盘数据，再结束事务。。

但每次 commit 都落盘数据，不划算，最好攒个几百事务平摊成本。。（ 4K 顺序写，慢于，1M 顺序写）

数据库有提供此种机制吗？

@acorngyl #82 嗯。。感觉你说的都是，commit 后，数据库定时将内存里的页缓存（数据/日志等），落盘到 SSD 上？

这样就会有楼主的《 commit 后，落盘前，数据库/系统崩溃，数据丢失》问题？

能否 commit 时，就落盘日志/数据，再结束 commit / 事务呢？

当然，每次 commit 都落盘一次不划算，需要数据库积攒多些事务平摊成本（ 4K 顺序写，和 1M 顺序写，速度也是不一样的）


我同意你后面说的，提交事务，先顺序写数据/日志页，有空/崩溃重启后，再慢慢回写到数据库本体上。

@scegg #80 楼主的意思不是说，就算提交事务后，数据库脏页还在内存里，每秒才刷新一次，保证落盘到 SSD / 存储卡 / HBA ，在此之前若数据库/系统崩溃，会丢失这一秒数据吗？

感觉 54 楼说的，数据库若能先攒够一堆事务数据（高频系统很容易短期内满足此条件），再批量顺序将脏页写入 SSD / 存储卡 / HBA ，最后才让事务返回结果，可以解决楼主的问题？

即使是随机写入事务，WAL 落盘时也是顺序写入的，有空再慢慢回写到数据库本体就好。

说不定还能合并多条相邻的事务数据，减少随机写入次数，事实上更快回写呢（ 1MB 随机写，总体速度比 4KB 随机写快）

比如同一用户（或同一数据页内 ID 相近的多个用户）几秒钟内几百笔交易，若每秒落盘一次，可能需要 10 次 4K 随机写。若有空慢慢回写，可以攒成一次 40K 随机写。。

@sleepingdog #55 这个不清楚诶，我也想知道，有没有追求小体积高质量的压制组。。https://i.imgur.com/krir4IG.png

@msg7086 #53 改下图片链接格式。。

https://i.imgur.com/IC6T83U.png

https://i.imgur.com/to57xlc.png

https://i.imgur.com/cvqR6h4.png

https://i.imgur.com/ipkS6aS.png

https://i.imgur.com/mTbTZg8.png

https://i.imgur.com/0hiQpw0.png

https://i.imgur.com/fDYFIRa.png

https://i.imgur.com/AqJpTtt.png

https://i.imgur.com/h5SerRZ.png

https://i.imgur.com/pX7CzHg.png

https://i.imgur.com/0YnyfWd.png

https://i.imgur.com/MIVDq2h.png

https://i.imgur.com/8yLWUP1.png

@msg7086 #53 我用 🍎 M1 详细转了 4K HDR 黑神话宣传片，并用 FFMetrics 分析每一帧 vmaf 质量分数，再挑最差的十几帧，用 video-compare 与原视频同时对比（白线左侧是原视频，右侧是转码后视频），

感觉 8bit CRF24 参数（结果 20 Mbps 码率）时，画质挺不错的，vmaf 平均 95.41 ，最差的十几帧放大对比，细节纹路还算清晰（见下列 10+ 张截图），速度也有 1.02 fps ，整机功耗 28 ~ 29 W 。。

如果用 10bit ，速度慢 20%，但质量会更好一些。。

如果正常观看，而不是逐帧放大，甚至挑最差帧去细细对比，且还是日常拍摄视频（而不是非常精细 4K 游戏画面），感觉 CRF26 （结果 15 Mbps 码率）也足够了，而且转码速度还能再快 10% 左右。。

https://imgur.com/IC6T83U

https://imgur.com/to57xlc

https://imgur.com/cvqR6h4

https://imgur.com/ipkS6aS

https://imgur.com/mTbTZg8

https://imgur.com/0hiQpw0

https://imgur.com/fDYFIRa

https://imgur.com/AqJpTtt

https://imgur.com/h5SerRZ

https://imgur.com/pX7CzHg

https://imgur.com/0YnyfWd

https://imgur.com/MIVDq2h

https://imgur.com/8yLWUP1

那种 2299 元 7945HX 的 MoDT 板 U 能用吗？

CPU-Monkey 说，多核性能比 i9-12900K 强 15%，但比 7950X 差 17%？（应该是最大功耗限制 120W 所致）

https://i.imgur.com/F29pmQ6.png https://i.imgur.com/F29pmQ6.png

https://i.imgur.com/dFjNamJ.jpeg

@acorngyl 为啥不能做到，落盘日志，commit 才结束？

难道 SSD 落盘 1MB 数据，延迟要几秒钟吗？

否则为啥不能积攒几十上百个事务的脏页数据/日志，批量顺序落盘，再 commit 结束，批量返回事务结果呢？

@aieruishi 你们说的『数据丢失』，包括『事务结束后，数据无法持久』吗？

感觉从题主描述来看，是包括的？

但个人认为，数据一致性要求极高的地方，就该攒批落盘数据后，这堆事务再批量返回结果。。

调用方线程被阻塞太多的话，应改用协程等方式实现。。

@aieruishi

关于第一点，如果数据库能做到 54 楼说的那样，是否能消除『数据丢失的窗口期』呢？毕竟是批量落盘后再返回事务结果的？（这应该是数据库要实现的？）

第二点，还是 54 楼说的，应该没必要每次事务都单独刷盘吧。。等一小会儿，积攒多些事务数据后，再批量落盘，总体更划算？代价就是每个事务延迟大一点点。。但高频系统，要短时间内攒够足够多的事务，轻而易举吧。。

这和你说的第四点是类似的，但应该是脏页在内存中停留时间增大一些？攒够一堆脏页再批量写盘？

当然，上面这些都是软件层面的，硬件不可靠，软件再完善也没法力挽狂澜。。