But the reason why developers are shackled to Objective C is to make sure processes finish in human time, and this is fundamentally a performance bottleneck in mobile hardware.
I use monotouch. Compiles to ARM assembly. Not seeing any problems.
For a generation of coders accustomed to limitless managed memory, high-level programming abstractions, and thousands of deeply functional opensource libraries, mobile is a step back to the Byzantine world of Commodore 64s.
Really? An 8bit 1Mhz processor with 64Kb? Or is it a 600Mhz 32bit processor with 262,144kb. Sure it doesn't match up to my i7, but when java first came out we had Pentium 90s. The lack of ObjC library support is changing as more developers pile on, and if you go with C# then that's pretty much solved.
(As a kid in the UK, you had a ZX Spectrum, a C64 or a BBC Micro. The next gen Commodore was the Amiga. The next gen BBC was the Archimedes. The Archimedes had the ARM2. Same instruction set as an iPhone... in 1988. I shipped a game on it. 100% Assembly. Much prefer C# to hand-rolled assembly, so its not just the new kids.)
Yes but Moore's law is applied to phones differently, because battery life is as important as processing power, or even more so.
This is the reason the 600Mhz processor in your phone will have worse performance than a normal 600Mhz processor. Mhz is useless as a measure for performance and it became popular only because of marketing campaigns by Intel, when they had an edge in the Mhz race. A more useful measure (other than running unbiased benchmarks) would be MIPS (millions of instructions per second) and MFLOPS (millions of floating-point instructions per second).
For example an ARM11 from 2002 at 412 MHz was able of 515 MIPS (millions instructions per second), while a Pentium Pro from 1996 was capable of 541 MIPS at 200 MHz. Also an Intel Core i7 EE is capable of 177,730 MIPS at 3.33 GHz, while an AMD Phenom 2 X6 from 2010 is capable of 78,440 MIPS at 3.3 GHz.
Basically your 600Mhz mobile processor is not the same processor you had when playing Counter-Strike a couple of years ago. That's because it is optimized for consumption rather than performance.
While I agree with you that the instructions matter, are your numbers x86 (or arm) instructions, or are they micro-instructions that your high level instruction set is translated in to? If so, the other factor is how many micro-instructions your instruction is broken down in to.
I use monotouch. Compiles to ARM assembly. Not seeing any problems.
For a generation of coders accustomed to limitless managed memory, high-level programming abstractions, and thousands of deeply functional opensource libraries, mobile is a step back to the Byzantine world of Commodore 64s.
Really? An 8bit 1Mhz processor with 64Kb? Or is it a 600Mhz 32bit processor with 262,144kb. Sure it doesn't match up to my i7, but when java first came out we had Pentium 90s. The lack of ObjC library support is changing as more developers pile on, and if you go with C# then that's pretty much solved.
(As a kid in the UK, you had a ZX Spectrum, a C64 or a BBC Micro. The next gen Commodore was the Amiga. The next gen BBC was the Archimedes. The Archimedes had the ARM2. Same instruction set as an iPhone... in 1988. I shipped a game on it. 100% Assembly. Much prefer C# to hand-rolled assembly, so its not just the new kids.)