Apple dumps Intel and shows Final Cut Pro on new Mac with Apple CPU !

[joema]

...as an editor, why would I want or care about editing video on an iPad, unless I travel a lot?...for those who edit in an office or home office, I see little to no advantage of editing on a tablet...

The simplest answer is a desktop is the best form factor for sustained editing. But I'm not sure anyone is suggesting long-duration editing on an iPad at a fixed location *instead* of a desktop machine. Rather they want more professional editing features on the tablet when mobile situations are unavoidable.

However even that reasoning assumes that relative to an iPad, laptops are heavy, thick, power-hungry machines. Imagine IF a MacBook existed which was the size, weight and battery efficiency of an iPad Pro + Magic Keyboard -- and which ran iPad apps natively. Something like this but a real MacBook which ran real apps including FCPX and Resolve: https://images.app.goo.gl/Y7VG7vSpn8bVFZoi6

Then people might be more open to using that in mobile situations rather than an iPad, but they'd still get iPads for certain things. It appears Apple may be delivering something like that within a few months.

For desktops, it appears Apple Silicon versions might not be available until next year, but that's not far away. The advantages of an Apple Silicon iMac seem less obvious (at first), but imagine a 30-inch iMac with a 32-core Apple CPU which was more silent than an iMac Pro, had better video acceleration than Quick Sync, cost less than the iMP and had better graphics performance. Something like that might be possible.

Longer term Apple will leverage special Apple Silicon features in their apps such as hardware-accelerated object identification. They'd like to provide a FCPX version that doesn't require manual keywording and tagging of media but the hardware-assisted AI logic does that for you. It's conceivable that eventually that logic could identify, tag and sync all multicams automatically. I tend to be somewhat pessimistic about that, but you can get faint glimmers of those features in current versions of iOS Photos.

 

[JAMedia]

For desktops, it appears Apple Silicon versions might not be available until next year, but that's not far away.

So where does that leave people who forked out $6K to $50K on the new Mac Pro last year?
Obsolete in 2 years. All the new program upgages and versions will be for the new MAC-OS 11

 

[Peter C.]

So where does that leave people who forked out $6K to $50K on the new Mac Pro last year?
Obsolete in 2 years. All the new program upgages and versions will be for the new MAC-OS 11

I'd imagine they would have two trees for their os/hardware. Arm for everything except a few pro products that need Intel until they can be transitioned to Arm.

Arm is tailored to 90% of Apples products that are small, portable, low heat and energy efficient. Not sure it's suitable for power users and whether software companies would need to rewrite their code. If Apple does go all arm, I'd expect a long transition.

The move to Arm is for Apple benefit of having one OS (iOS), having chip that designed to be small and energy efficient devices, and probably manufacturing cost savings. The best we can hope for is that power users won't be negatively effected.

 

[joema]

So where does that leave people who forked out $6K to $50K on the new Mac Pro last year?
Obsolete in 2 years. All the new program upgages and versions will be for the new MAC-OS 11

They are in the same situation as people who buy $5k MacBook Pros or $14k iMac Pros every day. They will be in the same situation as people who buy new x86 Macs now being designed. The newly-purchased x86 Macs will not be obsolete anytime soon and will be supported by Apple for many years. The purpose of the Universal 2 binary is to support both x86 and Apple Silicon Macs with a single application file. Largely the same application source code will be compiled for both x86 and Apple Silicon platforms. That is easier than how Premiere, Resolve and other cross-platform apps are compiled for both Windows and Mac. Those are different operating systems so some customization is needed, but for a Mac app being compiled for x86 vs Apple Silicon, it's the same OS with the same APIs and an identical user interface.

 

[ahalpert]

btw based on an educational guess, FCPX 10.5 or FCPXI(whichever they call it) will be coming out in Sept.

What's the story here? More than an incremental upgrade? Something I'll have to pay for?

 

[DLD]

Edit on laptops? One should be able to edit on iPhone 12 (to be announced in early September, supposedly on the 8th).

As to the industry as a whole.

Windows PCs Will Have to Switch Over to ARM CPUs Eventually to Match Apple’s Future Offerings, Says Former Mac Chief

“Specifically, what are Dell, HP, Asus, and others going to do if Apple offers materially better laptops and desktops and Microsoft continues to improve Windows on ARM Surface devices? In order to compete, PC manufacturers will have to follow suit, they’ll “go ARM” because, all defensive rhetoric aside, Apple and Microsoft will have made the x86 architecture feel like what it actually is: old.”

https://wccftech.com/windows-pcs-wi...pples-future-offerings-says-former-mac-chief/

 

[puredrifting]

What's the story here? More than an incremental upgrade? Something I'll have to pay for?

Apple has not charged for any updates to FCP X since it's introduction to my knowledge. They used to charge occasionally with FCP Studio, but only big feature updates, not the smaller bug fix updates.

 

[combatentropy]

why would I want or care about editing video on an iPad

Agreed. Sounds like a nightmare.

The brain has three parts.

1. Cerebrum. The center of conscious thought: "What is 25 × 7? Where should we go for Christmas? Should I buy this camera or that one?"
   
2. Cerebellum. Motor coordination: shooting a basketball, touch-typing, manual focus, playing a guitar. "Muscle memory", things that improve with practice, you're training your cerebellum. You don't "think" about them anymore, with your cerebrum. You just will them and they happen (more or less reliably) with your cerebellum. As you type, are you thinking about what each finger is doing, or are you just willing the words onto the screen?
   
3. Brain stem. Involuntary functions, like your heartbeat.

People fantasize about mind-controlled machines. But I say we already have that, with our cerebellum. With my 10 fingers on the keyboard, I already feel wired into my computer, as if it was an extension of myself. I use keyboard shortcuts for almost everything. I hate when I have to grab my mouse or even a trackpad. Much slower.

The same goes with tactile controls on my car's dash and on a camera. In fact, I would say that good manual controls are superior, because with mind control, how would the machine distinguish between something I'm just thinking about, like "I wonder if I want the camera to pan over there", vs. something I have decided, "Camera, pan over there". Sounds flaky, if and when it even becomes possible. My fingers submit to mind control much more accurately.

But I digress. My original point was, I agree, give me a good keyboard, not a touchscreen (and not one of those flimsy keyboards that attach to tablets).

In order to compete, PC manufacturers will have to follow suit

Good point. Windows already runs on ARM. I'm not sure why it has taken them so long, besides inertia.

In general, programs don't need to be rewritten for ARM, just recompiled. Actually you don't even have to recompile them. They can be run in emulation, for a minor slowdown.

Technical background: What is compilation?

Computer programmers write programs in programming languages. There are many: C, Java, Python, plus about a dozen other popular ones [example].

Computer processors, though, don't understand any of these languages. Computer processors understand only one language, which we call "assembly" or "machine code" [example].

Thankfully, the translation of any easy-to-write* programming language (like C) to a tedious and verbose assembly language is largely automatic. For whatever reason, the early programmers named this translation "compilation", instead of "translation". So the little programs that do it are called "compilers" [example].

Now the dialect of assembly that Intel and AMD's chips understand, called "x86", is different from the dialect of assembly that ARM chips understand. So if you compile your program for x86, it won't work on an ARM chip. But you just have to recompile it for ARM**.

* When I say "easy-to-write", I mean for programmers. It is still a whole bunch of gobblydygook for the uninitiated. Even more impressively, programmers in the early days wrote straight assembly, because there were not yet friendlier languages invented. The sample I gave for assembly is from the source code for the Apollo 11 guidance computer (ca. 1969), which they hand-typed.

** Sometimes recompilation is straightforward, sometimes not. Programmers sometimes have mixed in hand-typed assembly, to fine-tune things. If they did this in one of their programs, then they will have to do it all over again for ARM.

 

[David Saraceno]

Apple has not charged for any updates to FCP X since it's introduction to my knowledge. They used to charge occasionally with FCP Studio, but only big feature updates, not the smaller bug fix updates.

Correct, Final Cut Pro X was was released on June 21, 2011. In the last nine years, it has been updated a few times each year with new functionality, bug fixes, and codec support. In 2018, the company announced a user base of approximately 2.5 million users.

Apple has not charged for any updates or new versions.

Motion and Compressor are two separate applications dealing with motion graphics and compressing and transcoding and are sold separately at a much lower cost. There has been no additional cost for either app for updates and new features.

 

[JAMedia]

In general, programs don't need to be rewritten for ARM, just recompiled.

It's not that simple by a long way

 

[DLD]

There are a few of Arm based laptops - M-soft, Huawei, Samsung. None of them produces performance similar to the same budget laptop with x86 chip. That's because most programs were written for x86 and even Apple has to run them via Rosetta2.

https://www.theverge.com/21304182/apple-arm-mac-rosetta-2-emulation-app-converter-explainer

Which is why Cook said that the full conversion to RISC might take a couple of years. Lots and lots of software has to be rewritten and that's where a lot of effort will take place.

 

[DLD]

https://appleinsider.com/articles/20/07/23/how-apple-a-series-chips-stack-up-against-intel-macs

A history of Geekbench tests of Arm vs. Intel over the years on Apple products.

Summary -

There are already high-performance ARM-based chips out there, mostly running in servers and delivering better performance-per-dollar and energy efficiency than Intel processors. While their market share is still paltry compared to Intel, the pace of performance upgrades and advancements in technology may just close that gap. With Apple moving its complete lineup of Macs to ARM-based Apple Silicon, it could further spur adoption by computer makers and server companies.

As indicated by the pace of Apple's A-series developments, a Pro Apple Silicon chip could very well run circles around a similar Intel chip — especially when you consider how quickly the A-series has caught up to desktop performance. Also note that Apple Silicon Macs will have more robust cooling solutions than the iPads in the previous comparisons, meaning that thermal throttling could be less of an issue.

 

[joema]

..In general, programs don't need to be rewritten for ARM...

It's not that simple by a long way

During the recent WWDC, Apple Senior VP of software Craig Federighi described the process of moving an x86 MacOS app to an Apple Silicon Mac using the new version of XCode: "...to get started, developers just open their app projects and recompile. The vast majority of developers can get their apps up and running in just a matter of days".

He said Apple already has all their apps (inc'l complex Pro apps like FCPX and Logic Pro) up and running on Apple Silicon Macs. He demonstrated native "ARM versions" of Word, Excel, Powerpoint, Lightroom, and Photoshop running on Apple Silicon Macs.

 

[JAMedia]

"...to get started, developers just open their app projects and recompile. The vast majority of developers can get their apps up and running in just a matter of days".

As I said it is not just a re-compile. "Most" can port in a "few days" but many can't. However optimising for a completely different architecture is a different thing all together.

 

[joema]

As I said it is not just a re-compile. "Most" can port in a "few days" but many can't. However optimising for a completely different architecture is a different thing all together.

I worked on a major software product which we compiled for x86, Alpha and MIPS, all for the same operating system (Windows NT). It was mostly just a recompile. After making source code changes to a common tree, we'd crank out new versions for each CPU platform multiple times per day. This was highly optimized code using profile-guided post-link basic block optimization which maximized CPU pre-fetch and instruction caches.

It is definitely a bigger job to move code to a *different* OS platform such as between Windows and Mac. But for the Apple Silicon case, existing MacOS x86 apps are being moved to the *same* OS platform on ARM which has the same UI constructs, development frameworks and API surface.

 

[JAMedia]

This was highly optimized code using profile-guided post-link basic block optimization which maximized CPU pre-fetch and instruction caches.

As I said it is a bit more than just "recompile" and you have highlighted that many hours had been spent on creating a system for compiling for different architectures on the same OS.
I bet there was a fair amount of conditional compilation depending on target.

The cache structures and sizes will, of course, have a lot of impact for large video files. I believe Apple are going to use Cortex A14 and A15. It will depend if you leave it to the OS or go direct.

 

[joema]

As I said it is a bit more than just "recompile" and you have highlighted that many hours had been spent on creating a system for compiling for different architectures on the same OS.
I bet there was a fair amount of conditional compilation depending on target.

The cache structures and sizes will, of course, have a lot of impact for large video files. I believe Apple are going to use Cortex A14 and A15. It will depend if you leave it to the OS or go direct.

combatentropy's post actually said "in general programs don't need to be re-written for ARM...Sometimes recompilation is straightforward, sometimes not..."

That was correct. Re-writing an app is different from making changes to an app. In general moving an x86 MacOS app to an Apple Silicon Mac does not require re-writing it. E.g, if an app malfunctioned when moving from Mojave to Catalina on x86, it might require fixing something. You would not describe that as "re-writing the app".

Now if you decided to port FCPX from MacOS to iPadOS -- THAT would require re-writing the app, and in a profound way.

A certain % of MacOS apps can be simply recompiled for an Apple Silicon Mac with no changes whatsoever. A simple case was shown at WWDC session wwdc20-10214, "Port your Mac app to Apple Silicon": https://developer.apple.com/videos/play/wwdc2020/10214/

He also covers various situations where relatively minor changes are needed. There are other cases where more changes are needed, but tend to be somewhat mechanical involving edit/replace to fix incorrect flawed assumptions in the source code. Normally you wouldn't describe that as re-writing the app. There are cases where using a 3rd-party pre-compiled x86 binary (e.g. a plugin) could require more work, since x86 plugin code can't be mixed in-process with ARM. That might require the 3rd party developer to do that, which means coordination, scheduling, etc. There are other cases where the app runs fine after modest tweaks but improved performance is available - possibly beyond anything on x86 or AMD GPUs. If they chose to re-write a section of the app's GPU code to use tile-based-deferred rendering, you might describe that as re-writing part of the app. But that's an "extra credit" step, not required to ship a Mac Apple Silicon app with decent performance.

In general the developer labor required to port and maintain an x86 MacOS app to an Apple Silicon Mac is likely much less than to port and maintain that app between different operating systems, such as supporting Word, Excel, Premiere, Photoshop on both Windows and MacOS.

We must differenate between the work required for the initial port vs the less-visible but substantial work required to maintain and support that app. In some companies test and support engineers outnumber development engineers by 3:1. To port an app between MacOS and Windows (both on x86) can be a major undertaking. To maintain and support that cross-OS port requires lots of work because significant sections of the source code are OS-specific. Contrast that with porting an x86 MacOS app to an Apple Silicon Mac, where a variable but possibly modest amount of work is required for the initial port but maybe far less ongoing work to maintain and support that.

OTOH there are issues possibly unique to the x86/ARM port, such as the compiled universal binary must be tested and debugged for three scenarios: (1) x86, (2) Apple Silicon, and possibly a Rosetta case if out-of-process x86 plugin code is combined with an Apple Silicon host process.

There are possible differences in race condition timing between x86 and Apple Silicon, whereby a long-dormant bug concealed by a quirk of x86 suddenly materializes. Even if the required source code change is small (far below what you'd call "re-writing") the actual work required to isolate and fix those could be substantial. It appears the major app developers will have native Apple Silicon products available when the first new Macs ship. However smaller developers with fewer resources might take longer.

 

[JAMedia]

combatentropy's post actually said "in general programs don't need to be re-written for ARM...Sometimes recompilation is straightforward, sometimes not..."

That was correct. Re-writing an app is different from making changes to an app. In general moving an x86 MacOS app to an Apple Silicon Mac does not require re-writing it. E.g, if an app malfunctioned when moving from Mojave to Catalina on x86, it might require fixing something. You would not describe that as "re-writing the app".

Now if you decided to port FCPX from MacOS to iPadOS -- THAT would require re-writing the app, and in a profound way.

A certain % of MacOS apps can be simply recompiled for an Apple Silicon Mac with no changes whatsoever. A simple case was shown at WWDC session wwdc20-10214, "Port your Mac app to Apple Silicon": https://developer.apple.com/videos/play/wwdc2020/10214/

He also covers various situations where relatively minor changes are needed. There are other cases where more changes are needed, but tend to be somewhat mechanical involving edit/replace to fix incorrect flawed assumptions in the source code. Normally you wouldn't describe that as re-writing the app. There are cases where using a 3rd-party pre-compiled x86 binary (e.g. a plugin) could require more work, since x86 plugin code can't be mixed in-process with ARM. That might require the 3rd party developer to do that, which means coordination, scheduling, etc. There are other cases where the app runs fine after modest tweaks but improved performance is available - possibly beyond anything on x86 or AMD GPUs. If they chose to re-write a section of the app's GPU code to use tile-based-deferred rendering, you might describe that as re-writing part of the app. But that's an "extra credit" step, not required to ship a Mac Apple Silicon app with decent performance.

In general the developer labor required to port and maintain an x86 MacOS app to an Apple Silicon Mac is likely much less than to port and maintain that app between different operating systems, such as supporting Word, Excel, Premiere, Photoshop on both Windows and MacOS.

We must differenate between the work required for the initial port vs the less-visible but substantial work required to maintain and support that app. In some companies test and support engineers outnumber development engineers by 3:1. To port an app between MacOS and Windows (both on x86) can be a major undertaking. To maintain and support that cross-OS port requires lots of work because significant sections of the source code are OS-specific. Contrast that with porting an x86 MacOS app to an Apple Silicon Mac, where a variable but possibly modest amount of work is required for the initial port but maybe far less ongoing work to maintain and support that.

OTOH there are issues possibly unique to the x86/ARM port, such as the compiled universal binary must be tested and debugged for three scenarios: (1) x86, (2) Apple Silicon, and possibly a Rosetta case if out-of-process x86 plugin code is combined with an Apple Silicon host process.

There are possible differences in race condition timing between x86 and Apple Silicon, whereby a long-dormant bug concealed by a quirk of x86 suddenly materializes. Even if the required source code change is small (far below what you'd call "re-writing") the actual work required to isolate and fix those could be substantial. It appears the major app developers will have native Apple Silicon products available when the first new Macs ship. However smaller developers with fewer resources might take longer.

That's a long winded way to say: yes, you were correct there is more to it than just re-compiling.

 

[combatentropy]

joema and I were responding to those who think apps must be rewritten.

It is a true statement that many need only be recompiled. It is true that some will need more, but far less than a rewrite.

I'm not sure what specifically we disagree about. You haven't said much specifically, and when you have it is basically what we have said.

 

[JAMedia]

I suspect we have differing experiences of software development