What does the amount of ports have to do with the cpu?
And iBooks haven’t been sold by Apple for what, 14 years?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Transitioning Macs to Custom Chips With 'Incredible' Performance Starting Later This Year
- Thread starter MacRumors
- Start date
- Sort by reaction score
What does the amount of ports have to do with the cpu?
And iBooks haven’t been sold by Apple for what, 14 years?
Or they could just recompile it.
I don't develop Mac apps, but I do develop in C#. I had one app I had on Windows that I wanted to use on OSX. I took my source, changed the project type to be .net core and finally added the referenced libraries from nuget. One search/replace later and I was off and running.
Apple have stated it should be even easier with XCode.
So under every basis are you making this claim? Other than fear mongering that is...
Go big or go home! LOL
Well, actually it often does in that different CPUs support more or less channels of I/O. So, I suppose you could create the same number of ports, but at some point, you're just putting a lot more ports on a single channel, rather than real usable ports. A great example were the smaller and bigger MacBook pros where they had 2 ports on the smaller one and 4 on the bigger one. And, that was because of the differences in CPUs and I/O channels.
Whether that will apply to Apple silicon or not, we'll have to wait and see.
I'm not a developer at all (OK, I've written a few tiny python apps and modified a bunch of stuff while working in IT), but my understanding is that it is quite dependent on the app. Maybe a calculator or word-processor might be able to just recompile, but that isn't going to work with an app like SolidWorks or something like Autodesk 3ds Max.
I'm not sure how big of a market we are, but I think a lot of us are worrying about losing access to those kind of higher end apps and utilities that are highly unlikely to port, but which we can currently run under Windows (on our Macs) when needed.
As mentioned earlier in the thread, I guess our hope is that Apple silicon is so fast as to be compelling to these companies, along with their 'just use Parallels or Boot Camp' excuse going away, might actually pull some of them over. But, for every one of those, there will be ones that just give up, too.
1) Solidworks isn't a Mac app and needed to be run via a VM
2) Solidworks xDesign is their new platform agnostic browser based solution.
I addition, my reply was about smaller indie apps and not the big names.
It’s highly unlikely that very many apps need to know a thing about processor architecture, including complicated apps like these. Almost no software nowadays has any idea about the hardware - it simply uses sdks to abstract all that away. Where you’ll have problems is apps that rely on deprecated OS services like OpenGL, etc. but that’s true for intel macs, too.
It probably will work.
It might not be optimized, though. They're unlikely to still use raw x86 assembly code. That's a rare thing these days.
Instead, they might use Intel-specific extensions, like SSE or AVX (or MMX, way back in the day). They can either implement ARM equivalents like NEON, or use an abstraction layer like Accelerate.framework (if they don't already).
Those were just quick example I was hoping would be familiar names... I didn't research into the specifics.
But, I guess my point was that if we risk loosing access to bigger apps, we're certainly going to risk losing access to the indie ones.
Also, my point was that a lot of these apps don't have Mac versions at all, so are dependent on Windows x86 virtualization or emulation.
The one I'm concerned about right now (as I use it) is Autodesk Revit. There would have to be some kind of miracle happen, IMO, to be able to run that on a non-x86 Mac.
As an aside, you mention cloud-based. It is hard for me to imagine 3D/CAD apps being cloud-based, but I guess *if* Google can do FPS games in the cloud, that should be possible as well. But, then why the heck are remote control apps so horrible (ie. Screens 4), even if I'm controlling a machine on my own GB network? Something isn't matching up.
Yes, but a lot of what (some of us) are worried about are exactly the kind of apps dependent on those kinds of things. OpenGL is a great example.
I don't know a lot about it. Maybe they'll have some way to convert those to Metal a lot easier than I know, but they seem resistant (from what I've read). On the other hand, a few big titles have surprised me by being Metal already.
Yeah, I'm not enough into the developer world to know. I figure the big companies will either get on board, or they won't, much like the past. It's the apps by the sole developer or a small team I'm most worried about, if things get too complex. Or, the apps I'm nearly positive will remain Windows only that I'm going to have to run on a separate machine.
Last edited:
Keep in mind OpenGL is available, though. Virtually every API in Catalina for x86 is also in Big Sur for x86 + ARM.
I do understand the concern that some developers won't bother regardless, though.
It’s not a great example for supporting your point. When it goes away it will be going away for both intel and arm macs.
Yes, that is good (for now). It initially sounded like it was going away much more quickly, but I guess it has a couple years yet?
But, yes, unless it goes away on Windows too, some of these apps will just stick with it and not bother with Metal.
Well, for macOS. I can run Windows on my Intel Mac, for which as far as I know, it won't be going away.
But if you are running windows on your mac, you are better off with a windows machine.
Not necessarily. It is really handy to still be working on the Mac and just have a 'window-ized' Windows machine running some app you need. Also, while I suppose I could find a nearly-comparable set of peripherals and input devices (double-purchase, though), I like the ability to work with just one machine/input-devices for all of it.
But, yes, if I move to Apple silicon and no reasonable emulation option exists, that's what I'll have to do. At least I have a mini and monitor (instead of an iMac) so I can add a 2nd machine into my display (you know, actual INPUTS... handy things!). I don't even know about modern KVM types stuff for USB devices (I've never looked)? Maybe some kind of x86 dongle? A fast enough 'remote control' option?
That does not answer PORTS of current or older software. Anything that was an accessory to hardware was abandoned (look at editors for synthesizers and MIDI controllers, etc). Native Instruments might port their PRIMARY development lineup to Apple Silicon. Will they port the rest? Etc.
What makes a word-processor different to SolidWorks or 3ds Max when it comes to compiling the sources for another architecture? (assuming all already existing for x86 Macs)
[automerge]1593910053[/automerge]
You have all the right to worry about API support, however the discussion is about different CPU not different API.
A word processor or calculator is less likely to use instructions that are available on the x86 that won't have direct equivalents on the new ARM chips. Apple already called out some of the vector instructions as not working under Rosetta 2 and I'd extrapolate it to mean code leveraging those instructions will require alternate implementations on Apple Silicon (which is interesting for me because the Intel shift lost Altivec support and wasn't quite equivalent at the time). It's more likely that these programs that do 3D image manipulation that is likely to benefit from vector instructions than a word processor or calculator.
Apple Silicon brings a move to Apple's own GPU platform which on iOS is less problematic because it never supported the full OpenGL spec like the desktop GPU's did. Most of the material to date indicates a high probability that Apple will move to their own GPU which historically hasn't had as wide support for OpenGL with Apple pushing for Metal over OpenGL in recent times. OpenGL is an interface down into the hardware and more that a simple software API.
Anything that was 64-bit software that ran on Catalina should port very easily. Unlike last time, most software is now being developed on Apple's tool chain and is native to macOS. Last time a large percentage of apps were old OS 8/9 apps that were mostly unsupported using compatibility modes that did not really make the transition. These were apps developed using MacApp (moved from System 7 to OS 8 to OS 9).
Things were abandoned more than anything else because they had been driven by system extensions or old style KEXTs, and needed to be completely re-written. This transition will be much different in that anything that was native to Mojave or Catalina should be easy to bring to the new architecture. However, as I have said before, how much should the vast majority of users be forced to suffer because a small number of niche products are not really being supported?
Well clearly no one is running PPC code on a modern Mac any more, so it kind of does "answer" it. If that software was around during the PPC era, and it's around now, that means it was recompiled (and whatever CPU specific changes might be required) for Intel. If it wasn't around then but is around now, why are you assuming what they're going to do?
Right, so instead of arguing over something that will never be able to convince you, why do we not look to the future, so we can have some solid answers with fixed metrics once Apple Silicon starts shipping. The goal is to get everyone on the record so there will be no moving of the goal posts.
Once we have everyone’s answers, we can wait a few months and see who was right. Much easier than trying to do this retro actively. So far CMaier, Gerdi and I have fully answered these questions, and SSGBryan has partially answered them. Still waiting for answers from Nugget, IPProng and you.
- What set of benchmarks will you consider as the basis for comparison between the released Apple Silicon Mac systems and competitive Intel/AMD machines?
- When doing our comparisons between Apple Silicon-based hardware and AMD/Intel based hardware, how will you pick the AMD/Intel chip to compare? What objective metric would you use to define equivalent systems for comparison? Machines at the same price point? Machines with the same max TDP? Something else? The point of this question is that since Apple will not be selling its SoCs to others, one cannot do it purely on price of the chip, one needs some other objective metric to decide what two items should be compared.
- What objective criteria would Apple Silicon have to meet to be a successful product vs. Intel/AMD’s chips? (10% faster? 25%? 10% better battery life? 25%? Something else?) Once Apple starts to deliver high-end GPUs, what are your answers on those same metrics for those?
- When did you purchase your most recent Mac from Apple or a third party reseller that was currently shipping at the time you purchased it?
- What would be required for you to purchase an Apple Silicon-based system?
For the record, anyone else who wants to be on record should feel free to answer. I will create a new thread collating everyone’s answers so it is easy to review when it makes sense.
- Anything that's appropriate and allows for fair comparison. Geekbench seems to fulfill that.
- Might depend on what I want to compare. Could be "class" (size, performance target, notebook or desktop etc.). So, for example, compare a future Arm MacBook Air to the appropriate equivalent in the x86 world (regarding size). Or, TDP if there is no match on the x86 side.
- Match or exceed the current offerings. Given that it is the "first try", that alone would make it a success in my view, as Apple gains independence from Intel's ability to execute it's roadmap. I suspect Apple Silicon to fair much better than this, though. I'd guess around 25% - 30% more efficiency (faster or better battery, whatever the given product benefits more from).
- October 2018, Mac Mini (for me) and MacBook Air (gift for my mom).
- I will purchase an Apple Silicon based Mac. The exact time frame depends on when I feel the new system offers enough improvements over my current one. I'm really excited to see where the Mini is headed with this transition. As much as I like my current one, I do wish for beefier graphics without an eGPU. Doesn't have to be high end, but the UHD 630 just isn't the greatest …
This time it may be that multi-platform pro apps can be like those OS8/9 apps. I've read from other sources, that an application may be harder to port, if they include suppporting libraries etc from the "3rd parties". The developer has no control for those. F.ex. file format conversion codes within a CAD application can be like that. Perhaps some music apps could be in similar situation? Some of the functions will have to be removed and they may become available only later. In the worst cases, an app will lose its main function if there is no sensible replacement for some code parts.
Not because of this hardware transition. There maybe be some apps that never get 64-bit support like happened with Account Edge (they had a thirty year old code base that they tried to re-write in one shot and just gave up), or have never transitioned from OpenGL to Metal, but both of those things would have affected stuff on Catalina forward anyway.
Essentially the same point. If these libraries are still actively being supported, there will be little work for them to port, and if you have an expensive application (like AutoCAD, Cinema4d, etc.) and are completely dependent on a third party library to which you do not have source, you are doing it wrong.
Again, there are almost certainly open source equivalents for almost every file format conversion library, and transition for this kind of library is easy (no endian issues makes the process much simpler).
I have seen someone mention that there are some audio extensions that he used that were still 32-bit (he has not detailed what they are, so it is really impossible to respond intelligently about them), but they are already a problem, having nothing to do with the architecture transition. Again, Apple began warning people about the transition to 64-bit only code years ago (almost certainly since they have been planning this transition for years). People that did not make the transition had essentially abandoned their products years ago (some like Account Edge still collected checks for software that was not really being maintained, but that is a different issue).
The one set of libraries that will be harder to port are highly optimized, hand tuned libraries that directly target SSE/AVX/AVX2, etc. but for the most part users of those can run (just with less optimized code on CPUs without those instructions.
Apple deprecated OpenGL two years ago. It will be another year or two before support is gone. That is more than enough time for someone to port to Metal. There are libraries like MoltenGL that can help people transition (and likely see a performance increase on macOS even without making any other changes).[/quote][/quote]
... If these libraries are still actively being supported, there will be little work for them to port, and if you have an expensive application (like AutoCAD, Cinema4d, etc.) and are completely dependent on a third party library to which you do not have source, you are doing it wrong.
Again, there are almost certainly open source equivalents for almost every file format conversion library, and transition for this kind of library is easy (no endian issues makes the process much simpler).
A lot of CAD and 3D apps are dependent on all kinds of 'components' as well as even cores of technology they license, for example: https://www.spatial.com
If those components don't port, then they are probably no-go.
And, some of these apps are massive. For example, I use Revit, and there are so many (seemingly) apps within the app, that there isn't even interface consistency yet, let alone modernization.... and then porting? As I mentioned earlier (I think) the text handling engine feels worse than those in CAD apps I had on my Atari 1040ST. In other words, they have MUCH bigger fish to fry than porting.
I hope so. But, it might also be adding another straw to the camel's back for some of the smaller-team apps, or the big ones that might have been hesitating on what direction to take. UNLESS, Apple can bring them something quite substantial and they get enough outcry from their user-base.
I would argue at any point when you're including a third party library, you're becoming completely dependent upon said library for the functionality it provides. It doesn't mean you can't rewrite it or reimplement it but there was likely a reason you picked that third party library instead of developing the code yourself. Even if you have access to the source code, it doesn't necessarily follow you have an understanding of the code sufficient to update it where necessary and it might require a process of tasking someone to get up to speed with doing so. Again the likely reason you picked a third party library is because you didn't want to develop the functionality yourself and said functionality wasn't already available from the platform you were developing against.
A not uncommon reason for picking up a third party library is that library has done the heavy lifting of handling the cross platform compatibility for you. In that case getting rid of that library is potentially a choice between abandoning the other platforms that the library brings you support or abandoning the Mac, at least until said library is updated for Apple Silicon. In those situations a company might make the business decision that your Mac customer base isn't sufficient to invest the resources in making that happen.
Open source isn't always the answer either because whilst there might be open source code that does what you need, it may not necessarily be in a license that is permissive towards your intended use, especially if you're selling a commercial product.
The 64-bit forced transition with Catalina I think was intended to shift the negative press from leaving a significant chunk of 32-bit apps that hadn't been updated behind so that Big Sur wasn't the release that took that negative hit from those applications dropping potential compatibility on Apple Silicon. Apple have been talking about the transition to 64-bit for more than long enough so I'm not as empathetic for developers not making the switch given how Apple have slowly moved their own pieces by recompiling everything as x86_64, removing support for the 32-bit kernel and kernel extensions, warning end users that their apps might not be compatible with future versions of MacOS for two releases before finally removing support with a years notice. The Apple Silicon shift will not be as clearly telegraphed since it's an instruction set and architecture swap in two years so there will be developers who will have to determine if it's worth making the transition and they might decide the market isn't worth it.
[automerge]1594001772[/automerge]
One other problem is that the library developers might also have an updated version of the library but have since taken the library in a different direction to what is important for your application. At that point you might be on an earlier version of the library and you may even have the source code however you still have to do the work of either learning the library to update it or make your own implementation that makes sense for your application. In this situation it isn't that the library isn't inherently supported any more but that the authors of the library took it in another direction. I'm aware of at least one developer that is in that bucket who is looking at spending a year to take out and replace the library as they move forward. In that case they found that the library wasn't compatible with Catalyst which brought to the fore the need to get off the dependency if they wanted to take their iOS app and leverage Catalyst.
A not uncommon reason for picking up a third party library is that library has done the heavy lifting of handling the cross platform compatibility for you. In that case getting rid of that library is potentially a choice between abandoning the other platforms that the library brings you support or abandoning the Mac, at least until said library is updated for Apple Silicon. In those situations a company might make the business decision that your Mac customer base isn't sufficient to invest the resources in making that happen.
Open source isn't always the answer either because whilst there might be open source code that does what you need, it may not necessarily be in a license that is permissive towards your intended use, especially if you're selling a commercial product.
The 64-bit forced transition with Catalina I think was intended to shift the negative press from leaving a significant chunk of 32-bit apps that hadn't been updated behind so that Big Sur wasn't the release that took that negative hit from those applications dropping potential compatibility on Apple Silicon. Apple have been talking about the transition to 64-bit for more than long enough so I'm not as empathetic for developers not making the switch given how Apple have slowly moved their own pieces by recompiling everything as x86_64, removing support for the 32-bit kernel and kernel extensions, warning end users that their apps might not be compatible with future versions of MacOS for two releases before finally removing support with a years notice. The Apple Silicon shift will not be as clearly telegraphed since it's an instruction set and architecture swap in two years so there will be developers who will have to determine if it's worth making the transition and they might decide the market isn't worth it.
[automerge]1594001772[/automerge]
One other problem is that the library developers might also have an updated version of the library but have since taken the library in a different direction to what is important for your application. At that point you might be on an earlier version of the library and you may even have the source code however you still have to do the work of either learning the library to update it or make your own implementation that makes sense for your application. In this situation it isn't that the library isn't inherently supported any more but that the authors of the library took it in another direction. I'm aware of at least one developer that is in that bucket who is looking at spending a year to take out and replace the library as they move forward. In that case they found that the library wasn't compatible with Catalyst which brought to the fore the need to get off the dependency if they wanted to take their iOS app and leverage Catalyst.
Last edited:
Any non-trivial piece of software links third-party libraries.
Ultimately, you weigh the risk of being dependent on someone else (regardless of whether they're open-source or closed-source) with the risk of having to reinvent and maintain the wheel yourself. The latter means more control but also more work.
I am like a LOT of folks in the Mac Pro forum - I wanted an updated 5,1, not an xMac. I didn't want consumer grade CPUs, I need a lot of ram, and I need a number of PCIe slots (Video card, eSata card, and possibly a sound card).
The 5,1 was price competitive with Windows workstations. If they weren't moving to AMD, give me a Xeon, the ability to add whatever PCIe cards I need (ability to add a Blu-ray player would be a "nice to have"), and be priced competitively - like the 1st 5 generations of Mac Pros. The 7,1 is a $1,400 computer in a $4,600 case.
Instead, we got the 6,1 in a different form factor. In the 6,1 everything connected via thunderbolt - in the 7,1, everything connects via MPX. It is proprietary, and limits what I can do. There will be no CPU upgrades, and I suspect the last dedicated GPU will be a navi32 based card.
Apple is moving to sealed boxes - That has always been a priority for Apple, regardless of who was running the company.
AFA 3d art - the bottom end of the stack is either free or inexpensive, and quite powerful. Blender is open source, Daz couldn't get people to pay for Daz Studio, Bondware knows the Poser folks are too cheap to move to subscriptions, and I don't see Zbrush moving to subscriptions - from what I have seen, moving to subscriptions cuts off the hobbyists. Vue has just a shadow of it's former userbase, and hobbyists aren't moving off their paid for copies of Cinema3d, or Adobe CS. My BiL is the CIO for a hospital chain and he told Adobe to pound sand when they showed up to sell him on subscription based software.
You would probably be amazed at how many of us own our own server farms 😁. For the price of a 2080ti, I got 5 Z210 workstations, upgraded to 4core/8 thread Xeons, 32gb of ram & a SATA drive.
I have never been a Apple fanboy - not now, not when P.T. Barnum was running the company. I am with Apple as long as they make a better product - somebody builds a better mouse trap - I am out. The true believers don't understand this mindset - they would rather settle for less performance, because Windows Suks! It is an emotional thing for them; And that is fine, I just don't take them seriously.
AMD has delivered a better mouse trap on the hardware side, and Win10 is on par with OSX - I have run it for 9+ months now and have yet to see the issues I saw with Windows NT 20 years ago. Everything just works.
But apparently Workstation-class Xeons, 50% more memory slots supporting 12x as much memory, and twice as many PCIe slots isn't quite enough. I guess it really needs to have an optical drive so you can watch those blockbuster rentals right?
Are you just trolling or do you not understand what how MPX works? It's a regular PCIe slot, with an additional connector. A standard PCIe card will still work, so what exactly is it limiting?
Ah yes, the 'sealed box' where you have more internal expansion than any previous model, and they introduce user-replaceable parts for the T2-secured SSDs that are not replaceable on other models.