Announcement

Collapse
No announcement yet.

Qualcomm Announces 64-bit Snapdragon Processors

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by robclark View Post
    fwiw, on the ifc6410/snapdragon-600, it seems pretty stable to overclock the gpu to 487MHz.. also, the android kgsl kernel driver seems to (by default) trade off quite a bit of performance for power. So even the current (already old) stuff has some headroom.

    (btw, thanks for that link.. I didn't actually realize the different a320 variants had different # of ALU)
    That's a decent overclock considering passive cooling and, I'd imagine, a vrm without much headroom.

    Judy found the link today from one of the comments in the anandtech article about the Qualcomm announcement regarding the 808 and 810 today.

    Comment


    • #22
      Originally posted by schmidtbag View Post
      Not that I have a problem with 64 bit ARM, but what exactly is the point for non-server purposes? The highest RAM content I've seen on a non-server ARM system was 2GB. Considering the simplicity of the architecture, I doubt there's going to be a significant performance improvement switching to 64 bit. I'd much rather see more plug'n'play features.
      Samsung Note 3 have 3 GB RAM.
      Upcoming OnePlus One have 3 GB RAM too.
      During this year, there will be more phones and tablets with 3 GB RAM.

      Also its not only 64-bit, but its also going from ARMv7 to ARMv8 which is a drastically improved instruction set architecture.

      Comment


      • #23
        Originally posted by uid313 View Post
        Samsung Note 3 have 3 GB RAM.
        Upcoming OnePlus One have 3 GB RAM too.
        During this year, there will be more phones and tablets with 3 GB RAM.

        Also its not only 64-bit, but its also going from ARMv7 to ARMv8 which is a drastically improved instruction set architecture.
        just fyi, at least some of the SoC's have 2GiB of address space dedicated to I/O, so anything more than 2GiB of RAM requires LPAE (or 64b)..

        Comment


        • #24
          Originally posted by rrohbeck
          I want an ARM based low power desktop.
          I want a high powered one

          Comment


          • #25
            Originally posted by schmidtbag View Post
            Not that I have a problem with 64 bit ARM, but what exactly is the point for non-server purposes? The highest RAM content I've seen on a non-server ARM system was 2GB. Considering the simplicity of the architecture, I doubt there's going to be a significant performance improvement switching to 64 bit. I'd much rather see more plug'n'play features.
            ARMv8 is quite drastically different from ARMv7.
            ARMv7 had many flaws, and ARMv8 was not just an incremental version with some new instruction additions.

            I've heard just recompiling software for ARMv8 increases the performance quite much.

            Comment


            • #26
              Originally posted by uid313 View Post
              ARMv8 is quite drastically different from ARMv7.
              ARMv7 had many flaws, and ARMv8 was not just an incremental version with some new instruction additions.

              I've heard just recompiling software for ARMv8 increases the performance quite much.
              not sure about "quite much".. extra registers and few other tweaks certainly help. But the big reason apple's 64b chip is faster is that it is so damn wide. Don't expect, for example, a 64b cortex-a53 to be faster than a 32b krait, for example. That is why qcom ended up rolling out 64b first in the mid/low end parts.. I guess a53 available earlier than a57, but not faster than existing top end 32b stuff.. so just the way the timing worked out.

              Comment


              • #27
                Originally posted by robclark View Post
                not sure about "quite much".. extra registers and few other tweaks certainly help. But the big reason apple's 64b chip is faster is that it is so damn wide. Don't expect, for example, a 64b cortex-a53 to be faster than a 32b krait, for example. That is why qcom ended up rolling out 64b first in the mid/low end parts.. I guess a53 available earlier than a57, but not faster than existing top end 32b stuff.. so just the way the timing worked out.
                Same as the migration from 32 to 64bit, then? There was no advantage in speed, just a bigger address space, which then resulted in better overall performance if you needed the memory 64bit could address. And because the memory speed was also only ever given to 64-bit, then yes, the CPU speed was also given a boost as well. And numerous other bits and pieces. Is that what you're saying? Or is it a more Intel Gen4-style optimisation that's just seriously actually really better than Gen3 (IvyB)? Or both?

                Comment


                • #28
                  Originally posted by stiiixy View Post
                  Same as the migration from 32 to 64bit, then? There was no advantage in speed, just a bigger address space, which then resulted in better overall performance if you needed the memory 64bit could address. And because the memory speed was also only ever given to 64-bit, then yes, the CPU speed was also given a boost as well. And numerous other bits and pieces. Is that what you're saying? Or is it a more Intel Gen4-style optimisation that's just seriously actually really better than Gen3 (IvyB)? Or both?
                  well, there are some tweaks (like making the PC not a normal register) which I assume are intended to make it easier to be more out of order, etc. Which I expect will make things easier to implement a fast high-end armv8. Some new instructions, etc. So some improvement. I doubt much of that improvement is realized on a53 (which is in-order short pipeline, designed to be the .little in BIG.little)..

                  32bit arm is kind of a nice simple/clean architecture in some ways.. but it was designed in much simpler times. I think some of the choices in armv8 were made to make it easier to scale up to much higher performance parts.

                  so, tl;dr: armv8 does not cause fast, but armv8 enables fast ;-)

                  Comment

                  Working...
                  X