@MacsedProtoss #25

呃。。不是点开链接就能看了吗。。

同架构下，应该就能根据跑分类比了吧。。CPU Monkey 说，M4 大概是 M4 Pro 性能 60% 左右。。

反正意思类似这样，我手头也没有这俩机器，网上也找不到交叉编译到 x86 或 arm 平台的编译测试结果。。还有 x265 、svt-av1 等的结果。。

要是你能找到，欢迎告知我一下。

@MacsedProtoss #23 说实在，我不想看跑分，我想看实际任务速度。。

比如，编译 Chromium 、x265 / svt-av1 视频编码、7z 压缩解压等，这才最符合实际的场景。。


关于第一项，我在知乎[^1]看到，M4 需要 147 分钟，9950X + Windows 需要 83 分钟，

但感觉后者偏慢？因为网上一贴[^2]看到，9950X 只需 65.9 分钟。本站另一帖[^3]看到，7945HX 只需 80 ~ 90 分钟。。

而且 Windows 文件系统性能一直很差，更不要说巨量源码小文件的了。。要是能换成 Linux 测就好了。。


因此我采信 65.9 版本，认为 M4 性能最多是 9950X 的 45%，

看 CPU Monkey 上跑分对比[^4]，R24 中 M4 性能为 42%，R23 为 31%，GB6 为 65%，

所以你说得对，看 R24 更准确些。


[^1]: https://www.zhihu.com/answer/30599039317
[^2]: https://www.techpowerup.com/forums/threads/amd-ryzen-9-9950x.325439/page-7
[^3]: https://v2ex.com/t/1081503#reply15
[^4]: https://www.cpu-monkey.com/en/compare_cpu-apple_m4_10_cpu-vs-amd_ryzen_9_9950x

@MacsedProtoss #21 就算是 M4 Max (14 CPU)，也一样啊。。

为啥不对比 R23 成绩呢？为啥 R23 和 GB6 差这么远。。

链接： https://www.cpu-monkey.com/en/compare_cpu-apple_m4_max_14_cpu_32_gpu-vs-amd_ryzen_9_7940hx

@MacsedProtoss #7


感觉 7940HX 、7945HX 还可以啊？

在 CPU Monkey 上对比 M4 Pro (14 CPU)，7940HX 多核整体强 5%？

Cinebench R23 ，7940HX 强 30%，

Geekbench 6 ，7940HX 弱 22%

换块电池，应该就正常了。

同为 K40 ，用了三年后，电池寿命掉到 60% 时，出现了类似你说的：

1. 低电量时，有时充电不增加数字。我记得此时重启后再充电，则正常。
2. 低电量时，某些疑似瞬间大负载操作（如上滑看任务列表、启动某 APP ），会自动重启。怀疑是电池供电能力不足。

图方便，直接去官方换就行。动手能力还行的话，自己花 50 块换电池也不错。我自个儿换了块，用了小半年，还有 96% 寿命。

唉，原本用两年后，寿命还有 80% 左右的。。结果小半年天天数据线给电脑供网络，疑似过充严重，寿命迅猛缩水。。

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

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

怕啥。。真被替代了，你要求 AI 写个《日赚过万，一键提现》的 App ，不就能天天过上退休生活了吗？

@wangliran1121 #51

1. 是因为害怕，交易过程有 BUG ，会算多余额。失之毫厘，往后谬以千里吗？
所以需要设定，支出上限为昨日余额？那会不会也害怕，今日交易过程也有 BUG 呢。。

2. 用户看余额，应该是《实时》余额吧。。但汇总频率加快成几分钟，应该就不太介意了。。

3. 交易过程只写在一处，甚至写成存储过程，再疯狂并发测试几十上百亿次，可以尽量保证正确性吗？

4. 单个用户是串行，但可以多个用户同时交易吧。。（间隙锁范围，只是该用户现在 ~ 未来？）


5. 现在有点怀疑，会不会只支持串行化，并发数量能更高呢？（免去了很多锁之类的开销？）

我半个月前测试过，SQLite 在 1.3 亿 100 GB 数据时，仍能 1W 随机写事务 / 秒。。

设备是六七年前的轻薄本 + SATA 低端固态，Python 单线程 16 MB 内存完成的。。

源码发在当时的[帖子]( /1075881#reply68 )里了，可以去测试一下。

@zhady009 #26

连 wrk 都能用 10 线程，Vertx 本身是用了二三十个线程吗？

100 个 TCP 连接，占不了啥内存吧。。每个 4KB ，也就是 400 KB 这样？

@wangliran1121 #48

1. 为啥不直接在用户表里，记录实时余额呢？是因为 支出次数 <<< 收入次数，写压力小，还满足风控吗？

2. 23:00 时，用户查看余额，你要汇总当天 1.66 亿条流水，计算余额吗？

3. @sujin190 的思路，在有支出时，user_balance 也是不变的。而是每笔支出，都查 (SELECT SUM(amount) + 该笔支出 FROM user_transaction WHERE uid = ... AND create_time >= 今天) 是否 <= balance 。。

4. 你觉得 45 楼，流水表里记录实时余额，完全免除额外写压力，思路如何？

@NewYear #12

那现在能稳定找到，支持 XP 的新硬件（主板、CPU 等）吗？

如果不能，工厂、银行等的机器一出故障，岂不就要停摆好久？



使用新硬件、系统、软件，能获得优越感的原因，我猜测可能有：

1. 新硬件性能更强。身手快的，就是瞧不起慢吞吞的。
2. 新设备能使用更广泛的软硬件。人无我有的稀缺性，能得到其他人的羡慕。
3. 厂商赋予的情绪价值。比如更安全、更潮流、更方便等，再来个停止旧用户更新，让新用户高旧用户一等。
4. 展示财力。新东西往往更吃配置，设备更贵。
5. 展示能力。表示自己能及时适应新设备、功能等，学习能力更强。

@reea #10 这年头，还有这么多支持 XP 的主板、CPU 吗？

超出年限这么多，也不更换吗？不怕机器故障坏掉，数据出错啥的吗。。

@fengYH8080 #40 不是《一次》汇总，是当天《每一笔》都要这么汇总一次，来查余额。。


@sujin190 #39
@fengYH8080 #40

你们觉得，在存储每笔流水时，顺便在这笔流水存当前余额，如何？

根据 5 楼，啊哩云对 MySQL 的测试，读速大约是写速的 3 ~ 4 倍。

因此每写一条流水时，额外读一下最新流水记录，取其中余额，加上本次金额组成最新余额，性能损耗应该不大？

而且，最新流水记录，和即将新生成的流水记录，大概率是临近位置的，应该能利用上 Buffer Pool 里的缓存？所以读损耗进一步减小？



具体来说，主键设成（用户 ID << 42 | 毫秒时间戳），那么添加一笔支出，SQL 大致如下。

要知道是否添加成功，可以检查插入了 0 行还是 1 行。前者大概率是余额不够所致。


```sql
INSERT INTO 流水 (流水 ID, 金额, 这笔流水后用户余额, ...)
SELECT
　(用户 ID << 42 | ${当前毫秒时间戳}),
　${金额}, -- 支出，应该是负数
　(该用户最新流水记录.这笔流水后用户余额 + ${金额}) AS 该笔支出后余额
FROM (
　 SELECT 这笔流水后用户余额
　 FROM 流水
　 WHERE 流水 ID BETWEEN (用户 ID << 42) AND (((用户 ID + 1) << 42) - 1)
　 ORDER BY 流水 ID DESC
　 LIMIT 1
) AS 该用户最新流水记录
WHERE 该笔支出后余额 >= 0
```

@xxss0903 #6 这年头，还有这么多支持 XP 的主板、CPU 吗？

超出年限这么多，也不更换吗？不怕机器故障坏掉，数据出错啥的吗？

@fengYH8080 #27 《汇总实时余额 = 上次汇总余额记录 + 上次汇总时间点之后的流水累计余额》，

像上面所说，每天汇总一次的话，23:00 时，当天有 1.66 亿 笔未汇总流水。那计算一次余额的代价，是不是太大了。。



@sujin190 #26 是第二天内，能花无数笔 <= 1W 的钱吗？还是累计最多 1W 的钱？

前者不可接受。后者怎么实现呢？每一笔支出，都检查当天流水吗？像上面所说，23:00 时，当天有 1.66 亿 笔流水，这。。https://i.imgur.com/krir4IG.png

另外，商户看到的余额，也是（已清算 1W 余额 + 当天 1.66 亿笔流水余额）吗。。这。。https://i.imgur.com/krir4IG.png