Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
I bet it is easier for developers to update a x86 Mac version next to their Windows x86 version.

I would be more concerned with developers even paying less attention to the Mac version of their software with ARM Mac’s.
Good one.
 
I bet it is easier for developers to update a x86 Mac version next to their Windows x86 version.

I would be more concerned with developers even paying less attention to the Mac version of their software with ARM Mac’s.
To compile mac software (Intel and/or M1) a developer typically uses Xcode. The type of CPU(s) one compiles for is just a setting in a menu. The type of CPU in the mac doing the compilation(s) is essentially irrelevant (more speed is always better, but that's it), just as it is utterly irrelevant what machine(s) sit next to it.

The target architecture during compilation is essentially not linked to the architecture of the machine doing the compilation. That's been possible and used for decades already.

If you program in a high level language it is utterly irrelevant what CPU is going to be the target. What is highly relevant though are the libraries, the APIs etc. you have at your disposal. And those differ completely between a Mac and a wintendo machine even if they would have the same CPU. A Mac using an M1 or an Intel will have the very same API and libraries making it easy to compile for any target.

Where it does make a difference is in coding machine language directly but no developer outside of those writing the most basic drivers ever does that anymore for anything real. Similarly: if one writes code in an application that is dependent on the CPU type one is doing a tremendously lousy job in 99.99% of the cases.

Machines being big endian or little endian might have some impact in e.g. networking software (as the order on the wire might be different from the order inside the machine). This was more an issue with the PowerPC to Intel transition as the PowerPC was used in big endian mode AFAIK. Intel only supports Little Endian and AFAIK AMD is supposed to be biendian but typically used in little endian mode. Making it easier to avoid trouble with software that deals with hardware directly.
 
Last edited:
I bet it is easier for developers to update a x86 Mac version next to their Windows x86 version.

I would be more concerned with developers even paying less attention to the Mac version of their software with ARM Mac’s.

We will see...RISC machines are 2-4 times faster than CISC, and less expensive...Microsoft embracing, edge computing embracing, Mac embracing.... Intel is gone, gone!
 
To compile mac software (Intel and/or M1) a developer typically uses Xcode. The type of CPU(s) one compiles for is just a setting in a menu. The type of CPU in the mac doing the compilation(s) is essentially irrelevant (more speed is always better, but that's it), just as it is utterly irrelevant what machine(s) sit next to it.

The target architecture during compilation is essentially not linked to the architecture of the machine doing the compilation. That's been possible and used for decades already.

If you program in a high level language it is utterly irrelevant what CPU is going to be the target. What is highly relevant though are the libraries, the APIs etc. you have at your disposal. And those differ completely between a Mac and a wintendo machine even if they would have the same CPU. A Mac using an M1 or an Intel will have the very same API and libraries making it easy to compile for any target.

Where it does make a difference is in coding machine language directly but no developer outside of those writing the most basic drivers ever does that anymore for anything real. Similarly: if one writes code in an application that is dependent on the CPU type one is doing a tremendously lousy job in 99.99% of the cases.

Machines being big endian or little endian might have some impact in e.g. networking software (as the order on the wire might be different from the order inside the machine). This was more an issue with the PowerPC to Intel transition as the PowerPC was used in big endian mode AFAIK. Intel only supports Little Endian and AFAIK AMD is supposed to be biendian but typically used in little endian mode. Making it easier to avoid trouble with software that deals with hardware directly.
This is especially true in this day and age were the most popular language are python and javascript. There's still a place for bare metal high performance programing but in the end, our processors are sitting mostly idle not breaking a sweat for most of our daily task.
 
I've been waiting for a post like this! I've experienced the exact same thing and totally bought into the YouTube hype (despite being a YouTuber myself!). My 15" 2018 was in for a battery repair and I thought I'd give an M1 Air a spin in the interim so I at least had something with which to work. Never have I been more frustrated working with a machine!

Glad to get the 15 back today, but I totally can see the potential of the Apple silicon platform. I love the keyboard, love the form factor, love the thermal performance. But yes, totally disappointed by the Final Cut transitions, and numerous crashes! It's definitely made me think twice about when I'll be upgrading, particularly from a work perspective as a musician/mix engineer too. I'll be sticking to intel a while, as much as a 16 with Apple Silicon is definitely gonna turn my head.

The hype had me expecting pro results, I definitely wouldn't recommend one of these for work, but for most people this laptop is still gonna kill. Big sympathy OP and glad it wasn't "just me"!
 
Something really weird happened earlier. Created a new library and imported some Fuji xt4 Hvec footage and it played like butter. Nothing unusual. Added a few cross dissolves and again, like butter? How?
 
  • Haha
Reactions: acidfast7_redux
Something really weird happened earlier. Created a new library and imported some Fuji xt4 Hvec footage and it played like butter. Nothing unusual. Added a few cross dissolves and again, like butter? How?
Disk i/o... Background task running...
 
Something really weird happened earlier. Created a new library and imported some Fuji xt4 Hvec footage and it played like butter. Nothing unusual. Added a few cross dissolves and again, like butter? How?
I guess that's good...? At least you found it can do it. Just need to figure out how to replicate that every time.

If this were an issue you'd think there'd be a large thread on it as every second person who wrote they are buying one here at MRs stated they needed it for Video Editing...
 
  • Like
Reactions: beastforum
I'd watch the task manager and monitor the disk and temperature to make sure it isn't throtling, which it shouldn't do since nobody has reported it yet in all the testing being done.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.