V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
jibe
V2EX  ›  问与答

Windows 的性能是比 Linux 性能低吗?(非引战)

  •  
  •   jibe · 174 天前 · 1351 次点击
    这是一个创建于 174 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我发现了一个好玩的项目 Oppai_benchmark 。然后我用 C 语言重写了一个Oppai_benchmark_c。写这个的时候用了一个线程池库C-Thread-Pool,但是这个库 Windows 上用不了,然后我发现 Windows 自带线程池,然后就自己把 Windows 线程池 api 封装成了 C-Thread-Pool API 的形式。然后我发现这个程序在 Windows 上比 Linux 性能差了一半。两个平台都是 Release 编译的,不是 Debug 。 是我封装的有问题还是本来 Windows 性能就比 Linux 差一些? 以前听说 Windows api 性能很好比 Linux 要好是真的吗?

    10 条回复    2024-06-29 19:50:00 +08:00
    Mithril
        1
    Mithril  
       174 天前   ❤️ 1
    性能好的那个你说的应该是 IOCP ,确实设计比 Linux 的好一些。但这也就只是 IO 方面的,比较的是作为 webserver ,极限情况下能有多大负载。

    实际使用中差不了多少的。大部分情况下瓶颈也都不在系统这边,你也不会等快要榨干系统性能了才去扩容。
    agagega
        2
    agagega  
       174 天前 via iPhone   ❤️ 1
    没有试过线程,但多进程情况的性能是明显比 Linux 更差的
    lonewolfakela
        3
    lonewolfakela  
       174 天前
    一般来说重计算的应用,只要写的不是太烂,性能瓶颈应该不在线程池设计上……你最好先确认一下你在 windows 和 linux 上用的是一样的编译器和一样的编译参数……
    jhytxy
        4
    jhytxy  
       174 天前   ❤️ 1
    是的


    只有 Linux 能把硬件性能榨干


    Windows 在极限状况下就是稀巴烂
    tool2dx
        5
    tool2dx  
       174 天前 via Android   ❤️ 1
    牛逼啊,这是我看过最有奶量的 benchmark ,日本果然是一个神奇的国度,绝赞。
    jibe
        6
    jibe  
    OP
       174 天前
    @lonewolfakela 编译器不一样,Windows 特意用的 MSVC 。
    jibe
        7
    jibe  
    OP
       174 天前
    @lonewolfakela 我再用 mingw 试试
    jibe
        8
    jibe  
    OP
       171 天前
    @lonewolfakela 用不了相同编译器😢,mingw64 不支持信号,放弃了。
    lonewolfakela
        9
    lonewolfakela  
       171 天前
    @jibe #8 按理说两边应该都可以很容易地用上 clang 的?
    jibe
        10
    jibe  
    OP
       171 天前
    @lonewolfakela 我用的那个库 thpool 用了 POSIX 信号,Windows 不支持 POSIX 信号,所以编译不了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5789 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 01:44 · PVG 09:44 · LAX 17:44 · JFK 20:44
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.