@feikaras #90

1. 不至于吧，俩电商平台上简单数数，Mac mini M4 卖出快 40W 台了（如下图）

2. 对呀，前几天测试过（ /t/1101836 #reply56 ），五年前 M1 用 CPU 压 4K 80 Mbps 黑神话宣传片，x265 veryslow crf24 时有 1.02 fps （嫌太慢可下调至 slower 甚至 slow ），结果 20 Mbps ，挑 vmaf 最差十几帧放大对比原图，看不出啥损失。。

3. 🍎 M 系芯片不是共享内存吗？且现在起步 16G 内存，咋会负担不起 8G 显存的。。

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

是 Typora 那种所见所得编辑吗？

还是两列，一列编辑一列渲染那种。。

@scegg #115

1. 不追求一定要减少随机写入次数呀？关键是想利用顺序写入，快速完全持久化一批事务数据，减少交易事务延迟？（毕竟是落盘才结束事务）

2. 你是说，fsync 能又快又安全落盘到 LUN 写入队列/日志/缓存/分层/…，所以即使 commit 一次就落盘一次，延迟也能很低，并发量也能很大，系统崩溃断电 数据也能很安全，进而解决楼主的问题了？



@julyclyde #118

1. 丢就丢了呗，反正事务没提交成功（因为是攒一批事务，再一起完全落盘提交，事务才结束），又不会对后续其他交易事务有啥影响（比如一钱多用），提示用户《交易失败，服务器忙，资金不变，稍后重试》就行了？

2. 就算不攒事务，commit 一次落盘一次，高频系统每秒钟照样还有几千上万笔交易事务在处理呀？系统崩溃 / 断电，这些处理中事务照样失败，这批用户交易请求数据照样丢失，照样需要提示用户《交易失败，稍后重试》？

@feikaras #80

1. 性能强。。那就对应前两条？还是说要猛堆 16 核 32 核？

可我看很多人推荐买笔记本选 MacBook ，第三条是很重要的理由，待机 / 轻工作（码字看视频等）续航久？


2. 特制 CPU 是指啥？可 GPU 转码质量很差呀？这些场景咋办：

比如：x265 veryslow 视觉无损减少日常拍摄视频 80% 体积，骁龙 865 盒子 100 元电费能处理 7 TB ，低成本一劳永逸腾硬盘空间？

再如：svt-av1 猛猛压缩 1080p 视频到 300 ～ 400 Kbps 放至手机里（即 6 ～ 7 小时 / GB ），随时随地反复品味（还算清晰的）海量经典好剧？


3. NS 那（千元 8gen3 安卓都能流畅模拟的）孱弱性能，也不妨碍一堆厂商为其开发游戏呀？

况且我看 🍎 M4 玩死亡搁浅、博德之门 3 、古墓丽影 11 、生化危机 8 等，表现都还可以？

@msg7086 #83

所以说 AMD 摆烂嘛，🍎 M4 咋就能猛猛提升性能同时，大幅降价呢。。正常来说，HX 370 应该也是 2000+ 价位的。。

感觉 x265 可以是大众场景呀，拍日常视频的多了去了，电脑闲时压一压，能低成本视觉无损减少 80% 体积，一劳永逸省个几十上百 GB 出来，何乐不为呢。。

专业干活的也吃性能嘛，代码编译、视频剪辑渲染、数据处理、……

至于能效，除了干活省电外，还有 🍎 粉老生常谈的《噪音》问题，什么风扇一转就心烦。。

x86 生态确实强大，但也逐渐被 arm 蚕食了，比如轻办公、敲代码、搞设计等。。普通人没那么多上古 x86 应用场景吧。。

@feikaras #71

1. 你认为 AMD 的 CPU 应该朝啥方向进化呢？

- 提升单核性能（日用大部分场景更快）
- 提升多核能耗比（噪音更小，干活省电）
- 待机 / 低负载功耗控制（笔电场景续航更久）
- 其他……？


2. x265 、svt-av1 视频编码，都是 CPU 吭哧吭哧算，和 GPU 硬编 / 硬解没关系呀？


3. 你觉得阻碍 Mac 游戏繁荣的原因，可能有啥呢？

@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