V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
786375312123
V2EX  ›  程序员

一个弱值的问题,读的成本比写低多少?

  •  
  •   786375312123 · 2020-09-21 23:40:28 +08:00 · 2145 次点击
    这是一个创建于 1525 天前的主题,其中的信息可能已经有所发展或是发生改变。

    RT 以前上大学学过汇编,可是好久不用记不清楚了。而且那个时候也没讨论过成本问题。

    比如说很简单的 c++代码

    a > 0 和 a = 12

    前一句的成本能比后一句低多少?底在哪了?

    9 条回复    2020-09-22 11:04:51 +08:00
    lcdtyph
        1
    lcdtyph  
       2020-09-22 00:25:58 +08:00   ❤️ 2
    单独拎出来两句比较对应汇编的性能是没有意义的,还要考虑前后指令对流水线、缓存的影响
    ryd994
        2
    ryd994  
       2020-09-22 01:59:56 +08:00
    建议你代码成形前不要纠结这种细枝末节的事
    代码成形以后,你会发现你的程序根本没到这个级别
    如果你的程序真的需要这个级别的优化,那你应该已经掌握各种 profiling 的用法,问不出这个问题。
    786375312123
        3
    786375312123  
    OP
       2020-09-22 02:22:59 +08:00
    @ryd994 我工作不少年了。就是今天突然想起这个问题,好奇
    786375312123
        4
    786375312123  
    OP
       2020-09-22 02:26:55 +08:00
    @lcdtyph 这个只是举例。我也不想比较 mov 和读语句(忘记哪个了,读有对应的汇编么?)我就是想知道语义上的读和写,哪个成本更高?似乎读的话,你一定拷贝一个东西,不管是地址还是值。写的话,似乎需要获取地址,然后写到这个地址?
    这么看读的成本大概率比写要低?
    cassyfar
        5
    cassyfar  
       2020-09-22 02:30:48 +08:00
    今天所说的“写”成本,主要是指互联网应用下分布式系统的“写”,里面涉及了 replica 的更新,多个写到同一 entry 的 consistency,cache 的更新,高 TPS 下如何处理写,atomic 的写,等等吧。而读,基本就是一个读。
    vk42
        6
    vk42  
       2020-09-22 02:30:49 +08:00
    @786375312123 读和写都涉及地址和数据啊,从 CPU 执行单元来看没啥区别。如果按你的假设没有上下文,现在主流 CPU 的 Cache 是写回策略,所以写会直接 Cache hit,而读是直接 miss,所以读更慢
    AX5N
        7
    AX5N  
       2020-09-22 02:54:55 +08:00
    `mov eax, [ebp-4]`,把内存里的某个值复制到寄存器上,`mov [ebp-4], 5`,把某个值直接写入地址里,`mov eax, 5`把某个数直接写入寄存器里,`mov [ebp-4], eax`把某个数从寄存器里写入到内存里。这 4 个操作你既可以看成是读,也可以看成是写,不过读似乎都是先复制到寄存器上?

    鬼知道谁比较快是比较慢,你可以用 c++写个循环自己去测一下啊。编译之后再用调试器去改下汇编代码就好了。
    OysterQAQ
        8
    OysterQAQ  
       2020-09-22 08:13:46 +08:00 via iPhone
    @vk42 cpu 多级缓存策略不同,
    CRVV
        9
    CRVV  
       2020-09-22 11:04:51 +08:00
    https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=vmovdqu&techs=AVX&expand=5655,3418

    单纯回答这个问题的话,随便找一对 load 和 store 指令看文档就好了
    所以不同的处理器上不一样,Intel 架构上 load store 指令有一大堆,估计这个数字还会各不相同。
    上面链接里的这一对指令,在 Icelake 上是 store 的开销比 load 小

    当然,以上回答其实没有意义,因为如一楼所说这个数字没有用。

    不过,如果你要做的是一个并发的系统,可能是 cpu core 并行工作,也可能是你部署了一个集群来处理请求。
    那么, 在很多情况下,最后系统的瓶颈是在对同一个位置的写操作上。
    比如 atomic counter,不论是 cpu 上实现的还是 Redis 实现的,这个写操作都不可能被无限扩展,在 cpu core 足够多或者并发请求足够多的时候就会成为瓶颈。

    所以,通常情况下,设计架构 /算法时,会让写操作少一些。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1013 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 18:58 · PVG 02:58 · LAX 10:58 · JFK 13:58
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.