3 ms·
People that are downvoting, what am I missing? Developers either target apple silicon and ignore intel, ignore apple silicon and rely on rosetta2 for as long a
by Maxburn 4y ago
People that are downvoting, what am I missing?
Developers either target apple silicon and ignore intel, ignore apple silicon and rely on rosetta2 for as long as that's here, or invest in both to optimize performance and just eat all the extra work both require? I'm not a mac user, is there such a thing as making a app targeting apple silicon work on a x86 machine?
If someone is looking to add their application to Mac it really seems like a bad time to do it, wait a year and more apple silicon will be out there and you could reasonably target just that and be OK. Apple prolonging the transition is not good for anybody, but I guess we can blame this on supply chain.
- wtallis 4y agoWhy would anything in HVAC control software be written in a way that is at all specific to a particular CPU architecture? Most software really doesn't need to use inline assembly or SIMD intrinsics, so usually the only extra effort to support both x86 and arm is in configuring the build system correctly.
- Maxburn 4y agoI admit I don't know the software at that level but I think you would be surprised, it's a web server, db engine, and all sorts of things rolled up into it. This is commercial/industrial HVAC, it has more in common with emulating a PLC on PC hardware than say a nest thermostat app. I know it interacts with serial and ethernet ports to speak multiple languages (BACnet/LonWorks/Modbus/hundreds more) and they like to have some close relationship with the hardware, some of which is for licensing... They currently support windows, redhat, and just added Ubuntu. Very much similar version of the software runs on their "native" jace 8000 (PLC lite) hardware, which is ARM under it all so you would think they already have experience in that area.
- wtallis 4y ago> which is ARM under it all so you would think they already have experience in that area. I think you are probably still incorrectly assuming that the CPU architecture and instruction set have any relevance. What you've described sounds like the kind of software that is a portability challenge due to being tied to specific operating systems and their particular APIs for interacting with peripherals. It doesn't sound like anything that should much more than a recompile to target a new CPU architecture, provided that the application has already been ported to the operating system that will be used on that architecture. Certainly nothing you've described would require hand-tuned assembly code to reach adequate performance on a decade-old laptop.