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.
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.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.
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.
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.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.
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.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?