posted by wap, platform: Chrome

引用:

原帖由 @toshiki  于 2020-12-11 21:37 发表
现在 apple m1 芯片 上 会分为三种格式app  
通用（我理解是兼容m1但是不能发挥最大效率）
intel （顾名思义是x86需要转译的app 通常bug很多）
Apple芯片 （这应该就是专为了arm m1的最大效率的app，安装ios的app也是这个属性）

不存在apple silicon专用app。通用universal binary就是arm + x86双份二进制。

2年后苹果移除掉universal才会有arm专用。

posted by wap, platform: Chrome

引用:

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

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

这些是多线程的问题，正确做法从来都是从软件设计层面解决。具体硬件是什么无所谓。比如巫师3，doom eternal这些多平台游戏在switch上都跑的很好。

posted by wap, platform: Chrome

引用:

原帖由 @toshiki  于 2020-12-12 08:32 发表
呃，那有个问题，比如Lightroom前两天更新了，之前就是X86版本，但是实际上有些bug，这个更新的就是修复的。
2021年说是要出原生ARM的Lightroom，从版本是应该怎么区分？

分成 X86 X86优化修复bug？ ARM优化？

只要adobe提到native support那就是原生arm了。只不过现有的打包方式是把x86和arm打包成universal binary。

优化修bug要看是否是平台相关。有的优化是软件层面的，和硬件无关。有的优化是硬件相关。

https://helpx.adobe.com/download ... ilicon-m1-chip.html

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-12 13:05 发表
http://dreamrunner.org/blog/2014 ... memoryreordering/

这些细节早就被操作系统，编译器，标准库隐藏起来了。99.99%开发者根本感受不到。

多线程即使在x86上，race condition也是未定义行为。
因此，线程安全是需要在软件设计层面解决的问题。与底层硬件无关。

这就是为什么巫师3和doom等在x86上开发和运行的游戏也可以无压力移植到arm上。

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 06:32 发表
arm弱内存的读写排序乱排的问题早就被讨论过了，编译器怎么隐藏这种逻辑性随机性的问题？？？

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

你做过多线程编程吗。只要你写的代码有race condition，那在x86上照样出问题。因为这是你代码逻辑错误，不是x86或者arm的问题。别指望底层硬件自动帮你解决。

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 12:06 发表
发图不说话，写程序的都明白

你这些疑问放在2010年还是有价值的。在2020年还担心这些，难道过去10年arm的多核设备和多线程软件都是假的？

尤其是在功能完整的桌面操作系统，办公软件，3A游戏都已经在arm上跑起来之后，你的这些担心都已经不能用杞人忧天来形容了。

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 12:19 发表
拜托了，不跟你闹了，你这逻辑能力真心不像写程序的，围观的心里倍清

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

啊？

拜服！一个字，服

我前面早就说了，99.99%的程序员都感受不到底层的差异。为什么苹果安卓在arm上都跑得好好的，3A游戏在switch上也没问题。doom eternal这种更是从几w的arm一路scale到上百瓦的x86。魔兽世界shadowlands day 1支持apple silicon。这些项目难道不比几个推特帖子有说服力？你做的项目技术难度比doom eternal或者魔兽世界还复杂？

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 12:44 发表
这下我整明白了，你这脑袋就是电脑，纯的，二进制，要么0，要么1，别的啥不懂

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

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

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

你在这杞人忧天没用啊，还说什么ARM的崩溃问题比x86多。苹果自家软件day 1流畅跑就不说了。第三方暴雪魔兽世界M1版，微软office原生M1版都毫无压力。难道苹果的xcode，llvm只准微软暴雪用，别人不能用？
你不如说说你的项目是什么，是比office复杂，还是比魔兽世界复杂，现有技术都满足不了你的需求？

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 12:58 发表
lz的m1是什么问题？忘了？

从lz的描述也看不出是race condition啊。你有什么证据吗。

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

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 13:20 发表
你有什么证据不是？

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

你贴的这个race condition明显是Firefox Focus调用chromium，属于Mozilla的软件设计问题。

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 13:41 发表
mozilla这个focus不是跑在安卓上的？

甩锅也能这样甩？

你用C++数组下标越界导致crash也可以怪任何一个操作系统或者CPU不给力啊，没毛病。

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 13:58 发表
没毛病？

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

下课

前面说了你这些担心在2010年左右是成立的。现在2020年了。你觉得苹果谷歌在这些基础问题都没搞定的情况下就卖出了几十亿部多核arm设备给全世界消费者，然后现在还需要你来担心的可能性有多大？

posted by wap, platform: Chrome

引用:

原帖由 @sumeru  于 2020-12-13 14:54 发表
你这话说的，一听就不是程序员出身。跟其他软件比，游戏其实对跨平台最不敏感，拿游戏举例没有说服力。

游戏对跨平台最不敏感？没有说服力？游戏开发才是软件开发技术的集大成者。以狂吹来说，需要同时支持PowerPC，arm，x86三个平台。运行设备功耗从几瓦到几十瓦。我就问问全世界有多少程序员做过这种scale的项目的？你做过吗。

posted by wap, platform: Chrome

引用:

原帖由 @sumeru  于 2020-12-13 15:12 发表
果然是个民科，你去找虚拟内存大大聊吧。

你有干货就晒，没干货也好意思说别人。

posted by wap, platform: Chrome

引用:

原帖由 @biocoat  于 2020-12-13 15:22 发表
你说的没错，我不是说arm不如x86稳定，我只是说arm这种内存模型比较自由奔放，对程序员要求比较高

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

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

你原话“以前x86伺候码工，现在码工要伺候好arm”。我就问问现在全世界那么多程序员，有多少人写代码是处于“伺候arm”这个状态的。