Announcement

Collapse
No announcement yet.

Qualcomm Announces 64-bit Snapdragon Processors

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

  • #16
    Originally posted by Tundra View Post
    has new instructions for encryption/decryption and SHA hashing.
    "Reduced Instruction Set Computing"

    I think building crypto algorithm into CPU is very bad, because:
    - it requires writing ASM to use them
    - algorithms change
    - they are quite big

    Comment


    • #17
      ugh. 64 bit addressing allows files to be directly mapped into memory and also allows developers to not have to worry about heap + stack space overflowing. The bookkeepimg required to deal with 32bit address limitations is utterly beyond irritating. If you have the ram, and ram is insanely cheap, use it and let the OS manage the paging stuff for you. I just don't want to deal with the lame artficial what if cases that 32bit forces you to deal with.

      Comment


      • #18
        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.
        AIUI, for armv8 it offers both the legacy 32bit mode, and 64bit mode. The big advantage, however, is that the new isa is supposed to be much more efficient (this is, apparently, the source of the majority of performance gains that are expected with the move from A7/A15 to A53/A57).

        Comment


        • #19
          Originally posted by Krysto View Post
          Adreno GPUs have been historically non-competitive, until Adreno 320 and Adreno 330. But if the latest one, that's coming in H1 2015 is only 80 percent better, then it won't even beat Tegra K1 from this year. Also, why does Qualcomm bother to license the ARM architecture if they're doing to use stock ARM anyway?
          The 220 and 225 weren't bad, actually, and they were energy efficient, unlike nvidia. Simliarly, checkout this (http://kyokojap.myweb.hinet.net/gpu_gflops/). The adreno 430 is supposed to get be about 82% faster than the 330 which puts it somewhere north of 235 gflops @ 450MHz. Compare that to nvidia's kepler which needs to run at 950Mhz to get their alleged 365gflops. Consider, also, that the adreno 430 has a faster bus (25GB/s vs around 17GB/s for nvidia) and that power draw difference (~1W for 330 vs ~3W for K1) AND if you qualcomm wanted to blow their power budget they might be able to clock their gpu as high as nvidia which would put it north of 470gflops @ 900MHz. IOW, nvidia didn't design a very efficient gpu, like usual.

          Comment


          • #20
            Originally posted by liam View Post
            The 220 and 225 weren't bad, actually, and they were energy efficient, unlike nvidia. Simliarly, checkout this (http://kyokojap.myweb.hinet.net/gpu_gflops/). The adreno 430 is supposed to get be about 82% faster than the 330 which puts it somewhere north of 235 gflops @ 450MHz. Compare that to nvidia's kepler which needs to run at 950Mhz to get their alleged 365gflops. Consider, also, that the adreno 430 has a faster bus (25GB/s vs around 17GB/s for nvidia) and that power draw difference (~1W for 330 vs ~3W for K1) AND if you qualcomm wanted to blow their power budget they might be able to clock their gpu as high as nvidia which would put it north of 470gflops @ 900MHz. IOW, nvidia didn't design a very efficient gpu, like usual.
            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)

            Comment


            • #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