5 ms·

> If so this will be a smooth transition. That is extremely unlikely. Anything involving gaming is unlikely to run at even 50% of it's performance. It is goi

> If so this will be a smooth transition. That is extremely unlikely. Anything involving gaming is unlikely to run at even 50% of it's performance. It is going to be an extremely, extremely rough transition.

jurmous 6y ago
Any big macOS game would have an iOS gaming equivalent. The code was probably already metal and ARM compatible and probably only needs a recompile. They will have more than six months to figure that out. Other recent more desktop like games are probably using a big game engine like Unity/Unreal with Metal support and probably also only need a recompile. And older games which are less likely to be recompiled can likely run perfectly fine even at 50% performance on a new ARM MacBook which is very likely way faster than the latest non pro intel MacBooks.
- Mindwipe 6y ago
  > Any big macOS game would have an iOS gaming equivalent. Lol. That isn't true, in any way. There is virtually no commonality. > Other recent more desktop like games are probably using a big game engine like Unity/Unreal with Metal support and probably also only need a recompile. Do you really think that's how game engine support works? Heck, if that was remotely the case why does Metal get so little support with titles even on x86? > And older games which are less likely to be recompiled can likely run perfectly fine even at 50% performance on a new ARM MacBook which is very likely way faster than the latest non pro intel MacBooks. Any game with graphics performance is not going to run at 50% performance through an emulator. If it's done very well it might run at 20%, much more likely 10%. A "way" faster ARM MacBook isn't going to run five times faster than the Intel equivalent. Different thermal windows aren't magic. A 10% performance improvement is unlikely.
tgv 6y ago
Anything that uses a lot of CPU or pushes much data around. I use Logic to make music. Many of te plugins run on one core, and can take up 100% of it. If performance via emulation is around 50%, that means a lot of drop-outs in the sound, and basically an unworkable situation. Been there, seen it, don't want to go throug it again. The bigger plugin makers will probably port their products, but it's going to cost the user; the smaller ones may simply give up macOS completely.
- jurmous 6y ago
  You assume it is a lot of work to port the plugins. Most likely it only needs a compile for a new architecture. And they will probably have months to check that checkbox in Xcode. It is not like they have to switch to a new programming language.
  - kall 6y ago
    I think almost no audio plugins (other than those ported to mac from iOS) use a blessed apple toolchain to the extend that they could just flip a switch in Xcode. And I wouldn't be surprised if some of them have very processor specific optimizations in their code.
  - cageface 6y ago
    Audio plugins are one of the few software domains where you'll still often find handcoded assembly in performance critical sections. I wouldn't be surprised if a lot of third party vendors don't make the transition. On the other hand DAWs are more complete in the box now than ever so this is probably less of an obstacle to switching from the users' point of view than it would have been 5 years ago.
    - waterhouse 6y ago
      Video too. I paid attention to the commits to x265 for a while, and quite a lot of them were like this: asm: AVX2 version of saoCuStatsE3, (136881c -> 45126c) Just counting lines, there's more assembly than C++: ~/x265> find source -name '*.cpp' | xargs cat | wc -l 95358 ~/x265> find source -name '*.asm' | xargs cat | wc -l 168690 That said, x265 does compile for ARM, and has ARM assembly as well, though much less of it, as of when I last updated my copy (March 2017): ~/x265> find source/common/arm -name '*.S' | xargs cat | wc -l 11014 Looks like, in today's codebase, the line counts for .cpp, .asm, .S are 111188, 203423, 12217 respectively—so proportionally much the same.
  - jfkebwjsbx 6y ago
    DSP etc. are the kind of things likely optimized for architectures, using intrinsics for vectorization and whatnot.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
wastedhours 6y ago
Given the progress, depth, and variety of iOS games, it's probably not a massive concern to Apple, no? There'll be some enforced pain on OSX game developers, but from a "majority" user perspective, they'll probably be able to turn on a big enough library of titles that it'll make no difference (and arguably be better).
- jfkebwjsbx 6y ago
  How are mobile games relevant? There is a huge gap in gameplay, complexity and whatnot between desktop/laptop/console games to those in phones.
  - wastedhours 6y ago
    We're talking about Apple's transition to ARM here - it makes perfect sense to compare iOS games to OSX games, given the relative improvements in iOS gaming and their running on ARM. Apple's consideration about gaming will be "we have this massive catalogue of titles customers can play already here that we've been marketing, investing in, and pushing for years (and which get us a nice 30% cut of profits...)" > huge gap in gameplay, complexity and whatnot between desktop/laptop/console games to those in phones I made no judgement on that, simply that Apple's rationale for gaming is going to be based on the millions of ARM optimised titles they already have ready for the jump. The mobile gaming market is a lot bigger than the desktop gaming market for Apple - expecting that to not have an out-weighted influence on their decision making is absurd.
    - Mindwipe 6y ago
      Why don't those titles have a bigger representation on MacOS now given Catalyst? The answer is that they're not the right types of title for the Mac demographic, and that the business model isn't there to justify the porting costs (and moving to ARM does very little reduce those, which are mostly UX related).
  - jki275 6y ago
    I wouldn't call gaming relevant in the macOS sphere at all, really. Certainly in the mobile sphere it is, but there's not really any crossover to desktop OS X. There are games that run on OS X , but even for me as a relatively hardcore OS X type, I go sit down at my Windows 10 desktop machine when I want to game.
Someone 6y ago
If they market this right, I don’t see big problems. Many users live mostly in the browser, anyways. Photos, Pages, Numbers and Keynote will be native. If they convince Dropbox and Microsoft to have native apps, support iOS apps better than they do now (that should cover casual gaming), and make it cheaper than the ‘equivalent’ x64 one, I think they would have a product.
- owenwil 6y ago
  Microsoft already builds ARM Office for the Surface Pro X, and has the only official ARM-based Chromium browser, Edge, as well, so I suspect they'll be well positioned.
  - fowl2 6y ago
    There are official ARM ChromeOS devices (and therefore Chromium).
    - owenwil 6y ago
      Indeed – Edge is based on the ARM Chromium branch – though oddly enough, you can't get an official Chrome ARM build yet. I'm assuming Apple's push to ARM would make them actually release it. Also just remembered that Visual Studio Code is now building for ARM as well, which is interesting timing...

jurmous 6y ago

Any big macOS game would have an iOS gaming equivalent. The code was probably already metal and ARM compatible and probably only needs a recompile. They will have more than six months to figure that out. Other recent more desktop like games are probably using a big game engine like Unity/Unreal with Metal support and probably also only need a recompile. And older games which are less likely to be recompiled can likely run perfectly fine even at 50% performance on a new ARM MacBook which is very likely way faster than the latest non pro intel MacBooks.

Mindwipe 6y ago
> Any big macOS game would have an iOS gaming equivalent. Lol. That isn't true, in any way. There is virtually no commonality. > Other recent more desktop like games are probably using a big game engine like Unity/Unreal with Metal support and probably also only need a recompile. Do you really think that's how game engine support works? Heck, if that was remotely the case why does Metal get so little support with titles even on x86? > And older games which are less likely to be recompiled can likely run perfectly fine even at 50% performance on a new ARM MacBook which is very likely way faster than the latest non pro intel MacBooks. Any game with graphics performance is not going to run at 50% performance through an emulator. If it's done very well it might run at 20%, much more likely 10%. A "way" faster ARM MacBook isn't going to run five times faster than the Intel equivalent. Different thermal windows aren't magic. A 10% performance improvement is unlikely.

tgv 6y ago

Anything that uses a lot of CPU or pushes much data around. I use Logic to make music. Many of te plugins run on one core, and can take up 100% of it. If performance via emulation is around 50%, that means a lot of drop-outs in the sound, and basically an unworkable situation. Been there, seen it, don't want to go throug it again. The bigger plugin makers will probably port their products, but it's going to cost the user; the smaller ones may simply give up macOS completely.

jurmous 6y ago
You assume it is a lot of work to port the plugins. Most likely it only needs a compile for a new architecture. And they will probably have months to check that checkbox in Xcode. It is not like they have to switch to a new programming language.
- kall 6y ago
  I think almost no audio plugins (other than those ported to mac from iOS) use a blessed apple toolchain to the extend that they could just flip a switch in Xcode. And I wouldn't be surprised if some of them have very processor specific optimizations in their code.
- cageface 6y ago
  Audio plugins are one of the few software domains where you'll still often find handcoded assembly in performance critical sections. I wouldn't be surprised if a lot of third party vendors don't make the transition. On the other hand DAWs are more complete in the box now than ever so this is probably less of an obstacle to switching from the users' point of view than it would have been 5 years ago.
  - waterhouse 6y ago
    Video too. I paid attention to the commits to x265 for a while, and quite a lot of them were like this: asm: AVX2 version of saoCuStatsE3, (136881c -> 45126c) Just counting lines, there's more assembly than C++: ~/x265> find source -name '*.cpp' | xargs cat | wc -l 95358 ~/x265> find source -name '*.asm' | xargs cat | wc -l 168690 That said, x265 does compile for ARM, and has ARM assembly as well, though much less of it, as of when I last updated my copy (March 2017): ~/x265> find source/common/arm -name '*.S' | xargs cat | wc -l 11014 Looks like, in today's codebase, the line counts for .cpp, .asm, .S are 111188, 203423, 12217 respectively—so proportionally much the same.
- jfkebwjsbx 6y ago
  DSP etc. are the kind of things likely optimized for architectures, using intrinsics for vectorization and whatnot.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

wastedhours 6y ago

Given the progress, depth, and variety of iOS games, it's probably not a massive concern to Apple, no? There'll be some enforced pain on OSX game developers, but from a "majority" user perspective, they'll probably be able to turn on a big enough library of titles that it'll make no difference (and arguably be better).

jfkebwjsbx 6y ago
How are mobile games relevant? There is a huge gap in gameplay, complexity and whatnot between desktop/laptop/console games to those in phones.
- wastedhours 6y ago
  We're talking about Apple's transition to ARM here - it makes perfect sense to compare iOS games to OSX games, given the relative improvements in iOS gaming and their running on ARM. Apple's consideration about gaming will be "we have this massive catalogue of titles customers can play already here that we've been marketing, investing in, and pushing for years (and which get us a nice 30% cut of profits...)" > huge gap in gameplay, complexity and whatnot between desktop/laptop/console games to those in phones I made no judgement on that, simply that Apple's rationale for gaming is going to be based on the millions of ARM optimised titles they already have ready for the jump. The mobile gaming market is a lot bigger than the desktop gaming market for Apple - expecting that to not have an out-weighted influence on their decision making is absurd.
  - Mindwipe 6y ago
    Why don't those titles have a bigger representation on MacOS now given Catalyst? The answer is that they're not the right types of title for the Mac demographic, and that the business model isn't there to justify the porting costs (and moving to ARM does very little reduce those, which are mostly UX related).
- jki275 6y ago
  I wouldn't call gaming relevant in the macOS sphere at all, really. Certainly in the mobile sphere it is, but there's not really any crossover to desktop OS X. There are games that run on OS X , but even for me as a relatively hardcore OS X type, I go sit down at my Windows 10 desktop machine when I want to game.

Someone 6y ago

If they market this right, I don’t see big problems. Many users live mostly in the browser, anyways. Photos, Pages, Numbers and Keynote will be native. If they convince Dropbox and Microsoft to have native apps, support iOS apps better than they do now (that should cover casual gaming), and make it cheaper than the ‘equivalent’ x64 one, I think they would have a product.

owenwil 6y ago
Microsoft already builds ARM Office for the Surface Pro X, and has the only official ARM-based Chromium browser, Edge, as well, so I suspect they'll be well positioned.
- fowl2 6y ago
  There are official ARM ChromeOS devices (and therefore Chromium).
  - owenwil 6y ago
    Indeed – Edge is based on the ARM Chromium branch – though oddly enough, you can't get an official Chrome ARM build yet. I'm assuming Apple's push to ARM would make them actually release it. Also just remembered that Visual Studio Code is now building for ARM as well, which is interesting timing...