ARM 内存模型比x86的强内存松散很多，可以各种乱序执行，打个比方就是ARM司机开车会各种乱插并道，程序的逻辑如果不严谨(内存屏障)，几个指令跑下来会出不一样的结果。
x86比较严格的大家排队开车，你在我前面，我就绝对不会超车，所以程序怎么跑都很稳定出结果

以后ARM的崩溃问题会比x86多，以前x86伺候码工，现在码工要伺候好arm

引用:

原帖由 taxidriver 于 2020-12-12 11:48 发表

你这说法简直违背计算机的常识，如果同一段程序，设计没问题，每次执行结果会因为CPU导致不同，那计算机的大厦简直要崩塌

http://dreamrunner.org/blog/2014 ... -memory-reordering/



[ 本帖最后由 biocoat 于 2020-12-12 13:06 编辑 ]

引用:

原帖由 MacPhisto 于 2020-12-12 13:39 发表
posted by wap, platform: Chrome
这些细节早就被操作系统，编译器，标准库隐藏起来了。99.99%开发者根本感受不到。

多线程即使在x86上，race condition也是未定义行为。
因此，线程安全是需要在软件设计层面解决 ...

arm弱内存的读写排序乱排的问题早就被讨论过了，编译器怎么隐藏这种逻辑性随机性的问题？？？

早就有人叫了，bug修了几个月不知道怎么回事最后发现是内存模型的问题

引用:

原帖由 MacPhisto 于 2020-12-13 10:59 发表
posted by wap, platform: Chrome
你做过多线程编程吗。只要你写的代码有race condition，那在x86上照样出问题。因为这是你代码逻辑错误，不是x86或者arm的问题。别指望底层硬件自动帮你解决。

你要抬杠也没办法，我就知道杠精特别多，所以我引用人家写的，明明白白说的race condition是arm比，请注意，请特别注意， 比 x86更加容易出错

没有说x86不会出错，而是arm更容易出错

这有问题吗？

引用:

原帖由 MacPhisto 于 2020-12-13 10:59 发表
posted by wap, platform: Chrome
你做过多线程编程吗。只要你写的代码有race condition，那在x86上照样出问题。因为这是你代码逻辑错误，不是x86或者arm的问题。别指望底层硬件自动帮你解决。

发图不说话，写程序的都明白

引用:

原帖由 MacPhisto 于 2020-12-13 12:15 发表
posted by wap, platform: Chrome
你这些疑问放在2010年还是有价值的。在2020年还担心这些，难道过去10年arm的多核设备和多线程软件都是假的？

尤其是在功能完整的桌面操作系统，办公软件，3A游戏都已经在arm上跑 ...

拜托了，不跟你闹了，你这逻辑能力真心不像写程序的，围观的心里倍清

我最后问一句，arm比x86更容易出错，难道就是说arm不能写多核跟多线程吗？？？

啊？

拜服！一个字，服

引用:

原帖由 MacPhisto 于 2020-12-13 12:30 发表
posted by wap, platform: Chrome
我前面早就说了，99.99%的程序员都感受不到底层的差异。为什么苹果安卓在arm上都跑得好好的，3A游戏在switch上也没问题。doom eternal这种更是从几w的arm一路scale到上百瓦的x86。魔 ...

这下我整明白了，你这脑袋就是电脑，纯的，二进制，要么0，要么1，别的啥不懂

99.99%的程序员你都认识，你脸大，咋不说99.99%的cpu你都编程过

你看看你看看，3A能跑arm好好的，有啥问题？

废话，有问题人家码农早解决了
这么说是不是又没法理解了？

引用:

原帖由 MacPhisto 于 2020-12-13 12:54 发表
posted by wap, platform: Chrome
你在这杞人忧天没用啊，还说什么ARM的崩溃问题比x86多。苹果自家软件day 1流畅跑就不说了。第三方暴雪魔兽世界M1版，微软office原生M1版都毫无压力。难道苹果的xcode，llvm只准微软 ...

lz的m1是什么问题？忘了？

引用:

原帖由 胜利11人 于 2020-12-11 18:00 发表
终于买了台，第一天装了点软件没问题，太忙了，可能只用了半小时，第二天也用了不到1小时，大概半小时吧。又安装点东西，准备适配个鼠标，结果突然死机紫屏重启了。
昨天开始干点活，打开axure，弄了点图片界面，准 ...

引用:

原帖由 MacPhisto 于 2020-12-13 13:08 发表
posted by wap, platform: Chrome
从lz的描述也看不出是race condition啊。你有什么证据吗。

另外谷歌的chrome也是大量使用多线程的。在ios和安卓设备上跑了没有10年也有8年了吧。M1版也很快就适配了。你的软件什 ...

你有什么证据不是？

chrome不crash吗？
https://s3.ax1x.com/2020/12/13/relP1S.png

引用:

原帖由 MacPhisto 于 2020-12-13 13:32 发表
posted by wap, platform: Chrome
你贴的这个race condition明显是Firefox Focus调用chromium，属于Mozilla的软件设计问题。

mozilla这个focus不是跑在安卓上的？

甩锅也能这样甩？

你个三轮脚踏，被五菱甩百里远，然后你怪人骑的太慢？

[ 本帖最后由 biocoat 于 2020-12-13 13:46 编辑 ]

引用:

原帖由 MacPhisto 于 2020-12-13 13:46 发表
posted by wap, platform: Chrome
你用C++数组下标越界导致crash也可以怪任何一个操作系统或者CPU不给力啊，没毛病。

没毛病？

race condition可以导致越界，x86下不越界，arm就可能

下课

引用:

原帖由 ginaamix 于 2020-12-13 14:45 发表
posted by wap, platform: GOOGLE Nexus 4
M1完全支持X86强内存时序

没错，M1有TSO模式。
M1要兼容x86，没有TSO会很难看，windows on arm已经让我们看过一次了。

arm标准还是weak ordering，不是说arm就一定不如x86稳定，我是说要达到相同的稳定性，arm对程序员的要求比x86更高，就这么一点屁事而已

楼上那货绕不过来

引用:

原帖由 ffcactus 于 2020-12-13 15:19 发表
posted by wap, platform: iPhone
这种情况是发生在原x86程序不加修改就直接在ARM上编译运行，可能会因为时序问题而奔溃。目前确实是没有好办法。

但是这可以通过修改原程序来解决，因为本质问题就是源程度有BUG， ...

你说的没错，我不是说arm不如x86稳定，我只是说arm这种内存模型比较自由奔放，对程序员要求比较高

x86按部就班，一是一二是二，强内存不如弱内存对乱序执行的自由度优化度高

就这么一点屁事而已，楼上搞不懂

引用:

原帖由 MacPhisto 于 2020-12-13 15:20 发表
posted by wap, platform: Chrome
你有干货就晒，没干货也好意思说别人。

你甩了半天干货人家一看结果是甩货

引用:

原帖由 MacPhisto 于 2020-12-13 15:24 发表
posted by wap, platform: Chrome
你原话“以前x86伺候码工，现在码工要伺候好arm”。我就问问现在全世界那么多程序员，有多少人写代码是处于“伺候arm”这个状态的。

肯定不是你，你一行代码都写不出来，换句话说，伺候arm？ 你够资格吗？