iPad Pro Desktop style apps for iPad Pro?

[EthanNixon]

Actually, I think that in native apps, the A9X might be faster than i5 native apps. If you compare them equally. Looking at Geekbench, which is one of those apps designed to be native, you can see how the A9X is as fast, and in some cases faster, than the i3/i5 processors. It all depends on the software guys.

There is no such thing as a native i5 application. There can never be a benchmark that treats an x86 and ARM CPU the same. There are instruction sets that ARM processors cannot compute, but certain x86 processors can. All of these "universal benchmark" applications cannot use these instruction commands, as the ARM CPU cannot handle them. Geekbench is an extremely basic benchmark and should not ever be considered a credible source.

A true benchmark would be getting an i5 to run on iOS or get the A9x to run x86 programs. Neither will happen, so neither should be compared.

Until there is a benchmark that is universal and supports proper x86/64 instructions, we will never know the true speed comparison. iOS has an insanely low overhead compared to Mac OS X or Windows, and I can guarantee that the A9x would not be able to run either of those operating systems efficiently.

Aka, no point in comparing them to each other. There will never be a proper, fair way to evaluate either CPU without constraining it.

 

[Krevnik]

There is no such thing as a native i5 application. There can never be a benchmark that treats an x86 and ARM CPU the same. There are instruction sets that ARM processors cannot compute, but certain x86 processors can. All of these "universal benchmark" applications cannot use these instruction commands, as the ARM CPU cannot handle them. Geekbench is an extremely basic benchmark and should not ever be considered a credible source.

Honestly, you lost me when you tried to suggest there is a common set of instructions between ARM and x86. Please read up on the topic better before making claims like these, because they are wrong. ARM and x86 are not binary compatible in any way shape or form. The instruction set is 100% incompatible with each other. You can't run an ARM64 app on ARM32 either. And an x86-64 app won't run on x86. Specifically, you have lots of small changes to the instruction set that make the two mostly incompatible. That's why you have fat binaries on Mac and iOS to carry both the 32-bit and 64-bit compiled versions of the apps.

I don't write apps using CPU instructions either. I write them in a language like C/C++, Objective-C, C#, Swift, etc, etc. The expressions described in this higher language is compiled down to instructions for a given CPU for me. So my code can be universal, and take advantage of a particular instruction set at the same time, via compiler optimizations. And if I am writing a benchmark, those compiler optimizations are vital for giving some actual representation of the real thing.

Again. A benchmark is taking a task, in code, and running it on the CPU. The final result you get is measured in terms of raw time for that task (averaged over multiple iterations to flush out variation). While it is measuring both CPU performance and how good the compiler is, it does give you something resembling reality. Because the reality is that the compiler you use matters. And in Apple-land, you use Apple's compilers, or you use Apple's compilers. Nobody writes a program from scratch in assembler anymore, so measuring what you can get if someone decided they lost their mind and wanted to do it isn't really helpful in any practical sense.

And you do want your benchmarks to be basic, as they remove variables from what you are trying to measure. But you want a variety of basic tasks to get measurements of different areas of the processor that will behave differently. Now you can start getting into really niche stuff like vector instructions, but if your code can't be auto-vectorized by the compiler, odds are you aren't going to do it by hand unless you have to. And very few programmers have to. And I don't mean "1 in 10" or anything that high. I mean more like "1 in 100" if that.

 

[EthanNixon]

Honestly, you lost me when you tried to suggest there is a common set of instructions between ARM and x86. Please read up on the topic better before making claims like these, because they are wrong. ARM and x86 are not binary compatible in any way shape or form. The instruction set is 100% incompatible with each other. You can't run an ARM64 app on ARM32 either. And an x86-64 app won't run on x86. Specifically, you have lots of small changes to the instruction set that make the two mostly incompatible. That's why you have fat binaries on Mac and iOS to carry both the 32-bit and 64-bit compiled versions of the apps.

I don't write apps using CPU instructions either. I write them in a language like C/C++, Objective-C, C#, Swift, etc, etc. The expressions described in this higher language is compiled down to instructions for a given CPU for me. So my code can be universal, and take advantage of a particular instruction set at the same time, via compiler optimizations. And if I am writing a benchmark, those compiler optimizations are vital for giving some actual representation of the real thing.

Again. A benchmark is taking a task, in code, and running it on the CPU. The final result you get is measured in terms of raw time for that task (averaged over multiple iterations to flush out variation). While it is measuring both CPU performance and how good the compiler is, it does give you something resembling reality. Because the reality is that the compiler you use matters. And in Apple-land, you use Apple's compilers, or you use Apple's compilers. Nobody writes a program from scratch in assembler anymore, so measuring what you can get if someone decided they lost their mind and wanted to do it isn't really helpful in any practical sense.

And you do want your benchmarks to be basic, as they remove variables from what you are trying to measure. But you want a variety of basic tasks to get measurements of different areas of the processor that will behave differently. Now you can start getting into really niche stuff like vector instructions, but if your code can't be auto-vectorized by the compiler, odds are you aren't going to do it by hand unless you have to. And very few programmers have to. And I don't mean "1 in 10" or anything that high. I mean more like "1 in 100" if that.

I said there are different instructions between x86 and ARM... I literally said what you have already said. Thanks for reiterating it though.

Oops, I reread my post and that isn't what I meant to say. I know they aren't compatible in any sense. Using generic means of producing results will never show how powerful something is/can be. Geekbench does just that, a super basic benchmark. I would never base the performance off something like geekbench, but for some reason that is the "go to" performance test now.

 

[Billy95Tech]

The iPad Pro may not run OS X, but that doesn't mean, developers can't make their desktop app fit for the iOS.

Exactly!!!