Horsepower of Apple's A8 & iPhone 6 extend iOS's gaming lead over Android's Google Play

12467

Comments

  • Reply 61 of 121
    I love all these "experts" who are unaware that RAM is the absolutely one and only thing that is always on, no matter what, being refreshed thousands of times a second.

    iPads have much larger batteries than iPhones—they'll get 2GB of RAM first: I gar-on-tee!
  • Reply 62 of 121
    gwmacgwmac Posts: 1,807member

    And what happens when Apple decides to pull the trigger and take their foot off the brakes and go quad core and clock it at 2GHz or higher. If a dual core clocked this low with only 1GB of RAM is not only competitive but beats flagship Android phones next year expect a massacre. (well, worse massacre than this year in benchmarks)  Apple has regained that 3 year lead they had with their first  iPhone. Good times ahead for Apple and no way Samsung or any Android maker can catch up anytime soon. Tim Cook doubters go hang yourselves please. 

  • Reply 63 of 121
    richl wrote: »
    ascii wrote: »
     
    Those might be tests but they're not real world tests. When did you last buy an app that had 5 buttons, each of which ran a different list sort?

    You say they're replacing ObjC not C, but that doesn't really make sense. ObjC is C when you're not doing OO. And you shouldn't be doing OO everywhere, OO is great for GUI control libraries, collection classes, or anywhere there's a natural hierarchy in the business domain but elsewhere you'd just be using the tools for the sake of it. 

    The designers of Cocoa knew this. You can tell looking at the class library that they didn't make classes for absolutely everything (like you get in a language like Java), they made classes where OO really added something, and otherwise you can just get an off the shelf C library and link it in to your program (one example I used recently was the Bignum C library because ObjC didn't have a BigInteger class). C and ObjC are complementary and supposed to be chopped and changed in the same program. So they are replacing both, so it's fair to compare C performace with Swift performance.

    Writing an app in Swift doesn't exclude the use of C, just like writing an app in Objective-C doesn't exclude the use of C. Swift is very much a replacement for Objective-C, not C. This a point repeatedly made by Apple's engineers as WWDC 2014.

    As for when to use Objective-C and when to use C, I disagree to an extent. Objective-C has features like ARC that make it worthwhile in most situations. Unless you're writing a code where performance is by far and away the most important factor or you're accessing Foundation-level APIs, Objective-C should be the default option.

    As I understand it:
    1. many Obj-C classes use Foundation APIs which are [mostly] written in C
    2. Swift currently uses these same APIs by internal access to the current Obj-C classes
    3. Swift APIs are being rewritten to access the Foundation APIs directly -- obviating Obj-C to access these APIs
    4. Swift and Obj-C will co-exist for the foreseeable future to allow migration to pure Swift

    I suspect that a Swift programmer, if desired, will be able to access/include C APIs and Libraries ... and it will be at least as easy as you currently access them in Obj-C.
  • Reply 64 of 121
    <span style="line-height:22.399999618530273px;">Over </span>
    <span style="line-height:22.399999618530273px;">its first 3.5 years</span>
    <span style="line-height:22.399999618530273px;"> on the market, </span>
    Nintendo 3DS has sold 44M, a fraction of units the original DS sold when it launched in 2004 (70). That number should be going up. It's dropped off dramatically just like iPods. People aren't buying dedicated game devices like they used to, just as they aren't buying as many standalone cameras, GPS units, etc. Because of the iPhone. 

    Apples and oranges. The DS also launched at $149.99 in a much stronger economy, and quickly hit a price point of 129.99, where the majority of sales happened. The 3DS launched at $249.99 in a much crappier economy (which still hasnt recovered) and still persists at $169.99 for the regular unit. ASP of games has gone up as well.

    Now, if you were looking at the PS Vita, then the comparison works. 3DS doesn't.
  • Reply 65 of 121
    asdasdasdasd Posts: 5,686member
    As I understand it:
    1. many Obj-C classes use Foundation APIs which are [mostly] written in C
    2. Swift currently uses these same APIs by internal access to the current Obj-C classes
    3. Swift APIs are being rewritten to access the Foundation APIs directly -- obviating Obj-C to access these APIs
    4. Swift and Obj-C will co-exist for the foreseeable future to allow migration to pure Swift

    I suspect that a Swift programmer, if desired, will be able to access/include C APIs and Libraries ... and it will be at least as easy as you currently access them in Obj-C.

    No it's a fair bit trickier. To get to C++ you need an intermediate objective C++ file for instance. Swift isn't closer to the iron than objective C, quite the opposite.
  • Reply 66 of 121
    asdasdasdasd Posts: 5,686member
    I love all these "experts" who are unaware that RAM is the absolutely one and only thing that is always on, no matter what, being refreshed thousands of times a second.

    iPads have much larger batteries than iPhones—they'll get 2GB of RAM first: I gar-on-tee!

    Of course they will. News flash. The iPhone 6 and 6 plus have very large batteries compared to previous iterations. So Apple could have increased the amount of RAM compared to previous generations with gains in battery life anyway. Chose not to. It could also run faster and on more cores. If people think that's impossible for iOS they should explain why.
  • Reply 67 of 121
    I love all these "experts" who are unaware that RAM is the absolutely one and only thing that is always on, no matter what, being refreshed thousands of times a second.

    iPads have much larger batteries than iPhones—they'll get 2GB of RAM first: I gar-on-tee!

    You are describing Dynamic RAM or DRAM ... There is also Static RAM or SRAM.

    SRAM maintains its state without refreshing (less power). It can be faster, take more space and be more expensive -- see article quoted below.


    But, this may be of interest -- RAM manufacturer Micron has a large contract with an unnamed customer [rumored to be Apple].

    http://www.foxbusiness.com/industries/2014/01/08/micron-shares-rise-on-strong-results-possible-apple-contract/

    There are other rumors about Micron's new DDR4 RAM technology:

    http://appleinsider.com/articles/14/04/03/micron-ddr4-ram-rumored-to-improve-battery-life-speed-in-apples-future-iphones-ipads-macs


    And, there has been quite a bit of research about using SoI (Silicon on Insulator) technology. Simply stated, instead of creating circuits on silicon (as currently done) -- a layer of silicon is deposited on an insulator. The insulator is non-conductive and rapidly dissipates heat ... This means that the circuit traces can be closer together, have little leakage and use less power == smaller, faster, less power.

    What makes this really interesting is that one of the best known insulators is sapphire ... SoS (Silicon on Sapphire).

    At the very least, SoS DRAM could be made more efficient (less power/heat) and smaller.

    Or, for SoS SRAM -- it might be able to get the size down enough that size is not a major disadvantage to using SRAM in iDevices.

    Hmm ...



    What is the difference between static RAM and dynamic RAM?

    Your computer probably uses both static RAM and dynamic RAM at the same time, but it uses them for different reasons because of the cost difference between the two types. If you understand how dynamic RAM and static RAM chips work inside, it is easy to see why the cost difference is there,­ and you can also understand the names.

    Dynamic RAM is the most common type of memory in use today. Inside a dynamic RAM chip, each memory cell holds one bit of information and is made up of two parts: a transistor and a capacitor. These are, of course, extremely small transistors and capacitors so that millions of them can fit on a single memory chip. The capacitor holds the bit of information -- a 0 or a 1 (see How Bits and Bytes Work for information on bits). The transistor acts as a switch that lets the control circuitry on the memory chip read the capacitor or change its state.

    A capacitor is like a small bucket that is able to store electrons. To store a 1 in the memory cell, the bucket is filled with electrons. To store a 0, it is emptied. The problem with the capacitor's bucket is that it has a leak. In a matter of a few milliseconds a full bucket becomes empty. Therefore, for dynamic memory to work, either the CPU or the memory controller has to come along and recharge all of the capacitors holding a 1 before they discharge. To do this, the memory controller reads the memory and then writes it right back. This refresh operation happens automatically thousands of times per second.
    This refresh operation is where dynamic RAM gets its name. Dynamic RAM has to be dynamically refreshed all of the time or it forgets what it is holding. The downside of all of this refreshing is that it takes time and slows down the memory.

    Static RAM uses a completely different technology. In static RAM, a form of flip-flop holds each bit of memory (see How Boolean Gates Work for detail on flip-flops). A flip-flop for a memory cell takes 4 or 6 transistors along with some wiring, but never has to be refreshed. This makes static RAM significantly faster than dynamic RAM. However, because it has more parts, a static memory cell takes a lot more space on a chip than a dynamic memory cell. Therefore you get less memory per chip, and that makes static RAM a lot more expensive.
    So static RAM is fast and expensive, and dynamic RAM is less expensive and slower. Therefore static RAM is used to create the CPU's speed-sensitive cache, while dynamic RAM forms the larger system RAM space.

    http://computer.howstuffworks.com/question452.htm
  • Reply 68 of 121
    asdasdasdasd Posts: 5,686member
    gwmac wrote: »
    And what happens when Apple decides to pull the trigger and take their foot off the brakes and go quad core and clock it at 2GHz or higher. If a dual core clocked this low with only 1GB of RAM is not only competitive but beats flagship Android phones next year expect a massacre. (well, worse massacre than this year in benchmarks)  Apple has regained that 3 year lead they had with their first  iPhone. Good times ahead for Apple and no way Samsung or any Android maker can catch up anytime soon. Tim Cook doubters go hang yourselves please. 

    Yes. That was my point. Apple is way ahead in software so doesn't need to max out its hardware specs. When it does android is toast.

    I still don't understand the controversy.
  • Reply 69 of 121
    Dan_DilgerDan_Dilger Posts: 1,583member
    Quote:

    Originally Posted by tmay View Post

     

    The one area that is lacking on the A8 is multicore physics, Android taking advantage of Qualcomm's multicore SOC.

     

    So, Apple being Apple, what are the odds that some of that A9 die will  support an OpenCL/Physics engine(s) in addition to the GPU's?




    It may be a better approach to use the existing, powerful GPU to run OpenCL-type "GP-GPU" tasks, which Apple is now supporting in Metal.

     

    So rather than adding entirely new, task-specific processing cores to the SoC that will usually be sitting idle, developers can take advantage of existing hardware and the API they already know how to use for graphics. 

  • Reply 70 of 121
    asdasdasdasd Posts: 5,686member
    Btw another good article from DED. Credit where tis due. I used to be fairly critical but he's knocking out a few good ones these days.
  • Reply 71 of 121
    Lots of informative stuff....

    Agreed. If they could ever replace DRAM with Static RAM, that would revolutionize the industry. Not just phones and tablets, but computers as well. I hope they're close.
  • Reply 72 of 121
    asdasd wrote: »
    As I understand it:
    1. many Obj-C classes use Foundation APIs which are [mostly] written in C
    2. Swift currently uses these same APIs by internal access to the current Obj-C classes
    3. Swift APIs are being rewritten to access the Foundation APIs directly -- obviating Obj-C to access these APIs
    4. Swift and Obj-C will co-exist for the foreseeable future to allow migration to pure Swift

    I suspect that a Swift programmer, if desired, will be able to access/include C APIs and Libraries ... and it will be at least as easy as you currently access them in Obj-C.

    No it's a fair bit trickier. To get to C++ you need an intermediate objective C++ file for instance. Swift isn't closer to the iron than objective C, quite the opposite.


    First my post (above) that you quote -- was responding to accessing C constructs in Swift vs accessing C constructs in Obj-C.


    I guess I must be dense then ....

    The code below is from a Swift Playground -- The Blue-Highlighted construct uses CoreGraphics C code to set the TableView frame -- I don't think that is tricky at all -- actually, rather easier to code than Obj-C :

    var tableView = UITableView(frame:CGRect(x: 0, y: 0, width: 320, height: 320), style:.Plain)



    The full code is shown below:
    import UIKit  // includes Foundation
    
    class TestTableDelagate : NSObject, UITableViewDelegate {
        
        func tableView(tableView: UITableView!,
            heightForRowAtIndexPath indexPath: NSIndexPath!) -> CGFloat {
                return 44.0
        }
        func tableView(tableView: UITableView!,
            didSelectRowAtIndexPath indexPath: NSIndexPath!) {
                println("Selected row: ", indexPath)
        }
    }
    
    class TestDataSource : NSObject, UITableViewDataSource {
        var names:[String]
        
        override init() {
            self.names  = ["one", "two", "three"]
            super.init()
        }
        func tableView(tableView: UITableView!, numberOfRowsInSection section: Int) -> Int {
            return names.count
        }
        func tableView(tableView: UITableView!, cellForRowAtIndexPath indexPath: NSIndexPath!) -> UITableViewCell! {
            let cell = UITableViewCell(style: UITableViewCellStyle.Value1, reuseIdentifier: nil)
            var ip = indexPath
            cell.accessoryType = UITableViewCellAccessoryType.DetailDisclosureButton
            cell.textLabel.text = names[indexPath.row]
            return cell
        }
        
    }
    
    let testTableDelagate = TestTableDelagate()
    var testDataSource = TestDataSource()
    
    var tableView = UITableView(frame:CGRect(x: 0, y: 0, width: 320, height: 320), style:.Plain)
    tableView.delegate = testTableDelagate
    tableView.dataSource = testDataSource
    tableView.reloadData()
    
    testDataSource.names += (["four", "Five", "Six", "seven"])
    tableView.reloadData()
    
  • Reply 73 of 121
    singularitysingularity Posts: 1,328member
    Quote:

    Originally Posted by Gatorguy View Post





    Yes there is.image



    Have you ever noticed "this app is compatible with all of your devices" or "this app is not compatible" or whatever if you search from the desktop? In fact if you search apps from your Android device itself you shouldn't even be offered apps that aren't compatible with it.

     

     

    Quote:

    Originally Posted by pmz View Post

     



    No I have never seen anything to that effect, nor do other users, and there is absolutely nothing stopping me from installing titles that will NEVER work on my devices.


     

     

    Quote:

    Originally Posted by pmz View Post

     

    Did they even need to extend the lead?

     

    I have these little Android devices I use for product testing, and I noticed there is nothing to stop me from going to Google Play and buying (paying for) a major title game that absolutely positively will not run on my device, or probably 90% of all existing devices that run on something called "Android". My Android devices are so awful they usually crash when even attempting to load something from Google Play.

     

    There may be "games" out there....but just like the ancient antiquated PC game market....don't bother unless you have the absolutely latest overclocked hardware to run it.


     

    Quote:

    Originally Posted by Gatorguy View Post





    Yes there is.image



    Have you ever noticed "this app is compatible with all of your devices" or "this app is not compatible" or whatever if you search from the desktop? In fact if you search apps from your Android device itself you shouldn't even be offered apps that aren't compatible with it.

     

     

    Quote:

    Originally Posted by pmz View Post

     



    No I have never seen anything to that effect, nor do other users, and there is absolutely nothing stopping me from installing titles that will NEVER work on my devices.


    you aren't looking very hard are then. If you go to googleplay on the desktop and you have multiple android devices it will tell you exactly which ones can or can run the App and wont show Apps that are incompatible with a mobile device

  • Reply 74 of 121
    asdasdasdasd Posts: 5,686member
    Dick that isn't bringing in a c library written elsewhere - it's just using a c foundation struct syntax. CGRect is toll free bridged to a swift class or struct afaik.

    It's probably possible but I know that c++ isn't.
  • Reply 75 of 121
    maltamalta Posts: 78member
    Quote:
    Originally Posted by pmz View Post

     



    No I have never seen anything to that effect, nor do other users, and there is absolutely nothing stopping me from installing titles that will NEVER work on my devices.


     

    You might want to actually know what you are talking about. That or get your eyes checked.

    Also you CAN NOT install apps incompatible with your device

     

    image

     

    image

     

    image

    You will notice that Install is grayed out and I am not able to install this app.

  • Reply 76 of 121
    asdasd wrote: »
    Dick that isn't bringing in a c library written elsewhere - it's just using a c foundation struct syntax. CGRect is toll free bridged to a swift class or struct afaik.

    It's probably possible but I know that c++ isn't.

    Yeah ...

    But the OP's assertion, below, was that Apple was switching to Swift from C -- assumably to make programming easier, while sacrificing runtime performance.

    As I understand it -- you will lose nothing (you can still use C) -- but you gain the advantages of Swift. And as long as Apple provides a bridging interface between Swift and Obj-C -- it is a simple matter (a bridging .h file) to give Swift access to anything Obj-C and its subordinates can do.

    I don't program in C (well, maybe a little) or C++ -- but if you can do this with Obj-C, I don't see how Adding Swift to your toolkit removes any existing capability ...

    Educate me?

    ascii wrote: »

    This article is spot on, Android's problem is "Software squandering expensive hardware." What the article doesn't mention is that Apple is heading down the same road with their switch from C to Swift, which sacrifices runtime performance to make life easier at coding time. In other words it puts the needs of the coder ahead of the needs of the user.


    Finally, we have this thing called the Apple Watch. I think most people assume that the Apple Watch will run a flavor of iOS 8 ...

    If so, it likely would be beneficial to program in a language like C that is closer to the iron.

    But, that can only take you so far ...


    Consider this:

    Likely, one of the most common things to display on the Apple watch will be a short list (say, 10 or less) of items to select/drill down.

    Bill
    Donna
    Sam
    Wendy
    Zack

    Piece of cake … iOS has UITableView for that …

    But, that UITableView contains Cells (or Cell Views with Fields) — and all are contained within a UIView, within a ScrollView — managed by a ViewController, a XIB or Storyboard, with a DataSource and Delegate, under control of an AppDelegate …

    Including NLs our data is 26 characters … but, we’ll likely store it in an array, dictionary, Plist … JSON, XML ...

    All of a sudden, we have a verbose, complex data package on which we must perform a Danse Macabre to manipulate it into some esoteric View format to display on the watch.

    Dios Mio! We have a list of 5 items containing 26 characters -- and we're reinventing the wheel to get it on the watch screen.

    Yeah, you could probably do it more efficiently in C ... but should you be doing it at all?


    Screw that -- here's a scrollable list packet -- display it on the screen, and tell me which one gets selected.


    To me, that's the promise of Swift (and the other enhancements to Xcode) -- to package the data that's being used with what it's being used for.

    If I want to get that list to the Apple Watch -- don't need no XML, JSON, Views, Controllers, delegates ...

    Here's a self-contained data packet that includes everything you need ... And the real beauty of it:

    The packet is less than 50 characters long

    The packet can be displayed with 2-3 instructions -- regardless of language.

    To me, that's the promise of Swift (and the other enhancements to Xcode) -- to package the data that's being used with what it's being used for.
  • Reply 77 of 121
    misamisa Posts: 827member
    revenant wrote: »
    i am always blown away on how the iPhone can be beaten by specs, but still provide an a** kicking phone. android software is like MS software- it has to be able to run on so many devices with different specs. and who knows if you can get the update or not.
    and the last i knew, some games were not so great depending on the phone. there are pages to help android users get the games that play nice with their phones.
    i know the closed system can be a little annoying here and there, but i will take it over the less secure and power needy alternative. 

    Think about games made for the SNES (which had a CPU slower than a 8088) and compare it to the Sega Genesis, TG16, various arcade games, and then look at the DOS/MAC/Amiga games of the day.

    My favorite reference game is "Lemmings"
    SNES version: Voices, full audio, play with a controller
    Amiga version: Comparable to the SNES version including the two player mode.
    PC version: Adlib sound, single player, higher resolution, 16-color only.

    A few other examples:
    "The Simpsons" Arcade game, the PC port is pretty terrible when compared to the actual Arcade version.
    "Mega Man X", The visuals are comparable between the SNES and DOS version but the audio is still terrible on the DOS version.

    Even though the SNES or the Arcade version was comparably weak hardware, the DOS version required a more powerful system and gave a much poorer experience.

    If we look at games like Final Fantasy 7, Final Fantasy 8, or Tomb Raider, the graphics were better on the PC-Windows version simply because the PC had a higher resolution display than a Television, but the music was still awful, and the video compression for the pre-rendered scenes and videos were still console level.

    This is basically what happens when you port a game from iOS to Android, even though the Android device may be more powerful, the developers are not going to take advantage of it, because the platform is harder to deal with, and the sheer variety of configurations means that the majority of people who do use Android are going to get an inferior experience because their devices are substantially weaker. For the small amount of people who may have the Samsung Galaxy series they might get a "on par" with iPhone performance, everyone who bought some other Android device is guaranteed an inferior experience.

    Pretty much everyone doing "3D" mobile is using Unity, despite various shortcomings of it. Unity doesn't optimize the compressed textures for the target devices because it doesn't know what each target device supports, some of those devices only support certain texture formats in software, so the "Android version" will be painfully slower just from that alone.

    I reverse engineered one Unity game to see what textures were being used. It was using a mix of PVRTC (used by iOS devices), EAC/EA2 (Ericsson) and ATI 3DC(Adreno), of which only the first two are supported by Apple... yet this was an Android build.
  • Reply 78 of 121
    relicrelic Posts: 4,735member
    Quote:
    Originally Posted by Mac-sochist View Post



    I love all these "experts" who are unaware that RAM is the absolutely one and only thing that is always on, no matter what, being refreshed thousands of times a second.



    iPads have much larger batteries than iPhones—they'll get 2GB of RAM first: I gar-on-tee!

    There is little data to support the addition 1GB of RAM would have added a noticable affect on battery life. Noticable, is the keyword, of course there is power being drained but was it enough for Apple engineers to say, nope, we can't do this, I doubt it, no I highly doubt it. I recently spent a better portion of a week reading up on this, do the research yourself, there just isn't anything that suggests what your saying is true, the battery performance would have been minute. Maybe if Apple came forth with some other, thus far unreleased data that proved your theory I would be more resceptable. As of right now though I just don't believe Apple's decision to only include 1GB of RAM in their phones had anything to do with battery performance. Can you please provide a good technical write up on this proving the theory becasue I would really like to put this to rest.

  • Reply 79 of 121
    gatorguygatorguy Posts: 24,176member
    pmz wrote: »

    No I have never seen anything to that effect, nor do other users, and there is absolutely nothing stopping me from installing titles that will NEVER work on my devices.

    :no: I'll call BS on that one. Ain't happenin. . .

    Even remote app install from Google Play tells you. Further if you access Google Play from your Android device itself it won't even show an incompatible app for install.

    Edit: I see some other kind members have already posted screenshots. Here's an explanation of how it works as you apparently have no idea about installing from Google Play.

    http://android.stackexchange.com/questions/54557/why-am-i-unable-to-install-some-apps
  • Reply 80 of 121
    relicrelic Posts: 4,735member
    Quote:
    Originally Posted by Gatorguy View Post





    image I'll call BS on that one. Ain't happenin. . .



    Even remote app install from Google Play tells you. Further if you access Google Play from your Android device itself it won't even show an incompatible app for install.



    Edit: I see some other kind members have already posted screenshots. Here's an explanation of how it works as you apparently have no idea about installing from Google Play.



    http://android.stackexchange.com/questions/54557/why-am-i-unable-to-install-some-apps

    Actually if he's running the latest version of Android and a none Intel processor he could side load pretty much whatever he wanted too and it would work. There are however apps that do require certain hardware to run, i.e. Nvidia Tegra or K1 games but there aren't many and you could usually find a version of the same software that would work. I would say he is 98% correct. I too have yet to come across something that I wanted and couldn't side load, even though Google Play said it wasn't compatible.WhatsApp is a perfect example when you try to install it on a tablet. though side it loading works just fine. I'm sure you could find examples but most likely it's something very obscure and a better alternative exists.

Sign In or Register to comment.