Benchmarks are useful as a way of directly comparing products within the same controlled environment, given known performance of a baseline. Zwift typically responds to raw processing power, so it’s worthwhile knowing how a GPU or CPU compares to another when running the same benchmark.
However it only really works if else everything is the same; the architecture, the API, the operating system, the other hardware used and so on. So even comparing different generations of GPU/CPU on the same system otherwise can be fallible. There isn’t much linear scaling when it comes to Zwift performance, which backs this up.
That’s one way of looking at it, but far the most popular response to any note that Apple TV runs the lowest graphics profile at a low resolution and frame rate (compared to other options) is that users find it good enough, or simply don’t care at all - both of which are totally fine viewpoints to hold. Personally I want the best of what I’m paying to stare at, but that doesn’t make others wrong. They’re typically coming from an old/weak/slow/unreliable laptop, so by default it feels like a big upgrade in many respects.
And while I contributed to going off-topic w/a response to an Apple TV post, this thread is about Apple Silicon (M1/M2) of which the Apple TV does not have! So, let’s continue moaning about the lack of the lack of M1/M2 native support (no Rosetta)
That’s partially incorrect.
Apple TV uses an A15 Bionic SoC, which is a 64-bit ARM architecture just like Apple M1/M2. Since the assembly code for the two CPUs is basically the same, the two topics are closely related.
What’s more, iPhones and (more importantly) iPads belong to the aforementioned 64-bit ARM family too.
These are all Apple platforms, so when you develop for a device you don’t have to reinvent the wheel if you want to port the source code to another platform: you usually just need minor fixes.
PS: I’m referring to the latest models in all cases.
No: “tvOS. Leverage many of the same frameworks, technologies, and concepts as iOS.” Source: Apple
Obviously, nobody forces you to design/write software by leveraging the same frameworks (to use Apple’s words), but it is advisable if you want to produce portable software.
It is, because some people (including you) are implicitly claiming a priori that good software is not portable across different Apple devices. Although this might have been true in the past, it is not true anymore. Also, you are confusing the concept of system design/computer organization — i.e. what you call “architecture” — with the instruction set architecture. Considering that
all these operating systems (xOS) belong to the same family,
all these CPUs belong to the same family (RISC ARM64),
all these platforms can now use the same frameworks,
there is no need to study/understand how each device was designed, even though the devices look very different (e.g. an Apple TV, an iPad, a MacBook Pro). The same goes for their respective CPUs.
This thread is about extracting high(er) performance from software. And that involves understanding the architecture to make the most of it.
No, or at least not what you mean by “architecture”. On the contrary, it involves following Apple’s guidelines, in which case you will get assembly code that can be executed by different CPUs — provided they share the instruction set as is the case here — even though the “architectures”, to use your word, look different and/or have a different name.
Nowadays, a well-designed app can run on
tvOS ︎ iOS/iPadOS ︎ macOS
(not necessarily the other way around)
which is remarkable anyway.
That being said, it seems that Zwift developers couldn’t care less.
I don’t think this is true. We’ve already heard that they are working on native builds for macOS, and we don’t know what else may flow from that work. My guess is that Zwift developers are also interested in this work and frustrated by the slow progress. If you need to blame someone, focus on the leadership. They set the priorities and sign up to take the heat for those choices. And they decide how much gets publicly communicated.