Announcement

Collapse
No announcement yet.

ARM On Ubuntu 12.04 LTS Battling Intel x86?

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

  • #41
    Originally posted by WillyThePimp View Post
    Let's go with the antithesis. Let's say we should expect no (significant) gains on either platform from compiling with non-vectorized SIMD instructions. Neither platform is using a 64 bits userspace, nor SIMD, anyways. This is for compatibility's sake, of course. If Canonical wants its OS on ARM devices, they have to support the most basic feature: A FP unit, because as I said, a so much of a leadeing SoC as Tegra 2 is, it hasn't got NEON. That's why I'm sure no SIMD instrucctions were used on the ARM machine.

    Also, VFP and NEON are two very elegant SIMD instruction sets. While we cannot claim NEON implementation superiority over SSE(x), doing so the other way is equally wrong, it's a lie. Anyways, the default SSE2 in x86_64 is the first SSE that introduced, as far as I know, double precision formats for integer and fp operations, but VFP, in the other hand, is baseline for every modern ARM core and supports it. Shall we compare SSE vs NEON on 32 bits kernel? I'm pretty sure Atom is gonna keep loosing. ANd this is, with a much more mature support for it's architecture at compiler level, overall better system specs and higher power consumption.
    While SSE2 is a double percision IEEE754 compliant SIMD unit, VFP isn't. Actually VFP isn't even a SIMD unit. VFP does vector ops by sequencing scalar ones.
    On the other hand, the NEON instruction set doesn't have double precision instructions and its single precision is not fully IEEE754 compliant. Other disadvantages of NEON that i can think of are a shared register file with VFP while SSE has it's own registers (XMM) and moving a value from a NEON/VFP register to an ARM register is very slow, causing a 20 cycle pipeline stall.
    So VFP is nowhere near as fast as SSE2 and NEON has much more limited use compared to SSE2.

    Comment


    • #42
      Originally posted by ldesnogu View Post
      Not sure it makes sense to compare against Atom 64-bit given that the low power versions (Medfield included) don't have it. Also it seems SSE is not that much faster than x87 according to Agner Fog tables, though I agree it should be used.
      Like atom01 pointed out, the gain doesn't come from x64 but because SSE2 is the default fp instruction set for the x64 Ubuntu kernel. The same gains can be expected on the Atom Medfield when using the x86 kernel with SSE2 flags set.

      Comment


      • #43
        Originally posted by WillyThePimp View Post
        Let's go with the antithesis. Let's say we should expect no (significant) gains on either platform from compiling with non-vectorized SIMD instructions. Neither platform is using a 64 bits userspace, nor SIMD, anyways. This is for compatibility's sake, of course. If Canonical wants its OS on ARM devices, they have to support the most basic feature: A FP unit, because as I said, a so much of a leadeing SoC as Tegra 2 is, it hasn't got NEON. That's why I'm sure no SIMD instrucctions were used on the ARM machine.

        Also, VFP and NEON are two very elegant SIMD instruction sets. While we cannot claim NEON implementation superiority over SSE(x), doing so the other way is equally wrong, it's a lie. Anyways, the default SSE2 in x86_64 is the first SSE that introduced, as far as I know, double precision formats for integer and fp operations, but VFP, in the other hand, is baseline for every modern ARM core and supports it. Shall we compare SSE vs NEON on 32 bits kernel? I'm pretty sure Atom is gonna keep loosing. ANd this is, with a much more mature support for it's architecture at compiler level, overall better system specs and higher power consumption.
        I think you somewhere missing the point. SSEx now is a full replacement for old and outdated x87 in all respects and this is the reason why it should be used for testing in 32-bit systems also. x87 is still used in 32-bit Ubuntu to maintain compatibility with older cpus but this does not contradicts the fact that Intel is going to use SSEx in the upcoming android x86. I may guess that Intel is keeping x87 in Atom just for compatibility with legacy software and it is not optimized performance-wise. As for NEON vs. SSEx tests - I would not be so sure about potential winner (especially when you consider that NEON is not replacement for VFP)..

        Comment


        • #44
          Originally posted by atom01 View Post
          And again, I'm not sure that neon was not used in pandaboard benchmarks.
          And again NEON can't be used for floating-point, even in single precision it does not conform to IEEE, so I doubt it was used

          Comment


          • #45
            Originally posted by ldesnogu View Post
            And again NEON can't be used for floating-point, even in single precision it does not conform to IEEE, so I doubt it was used
            Not for fp math, but it might be used to speed up memory move/copy (by using 128-bit registers).

            Comment


            • #46
              Originally posted by atom01 View Post
              Not for fp math, but it might be used to speed up memory move/copy (by using 128-bit registers).
              That's true for Cortex-A8 but not for Cortex-A9, where using NEON to do memcpy doesn't bring any speedup. The reason is that Cortex-A8 has a special 128-bit path for NEON ld/st that A9 doesn't have. So no speedup it to be expected here.

              Comment


              • #47
                Articles like this should also have power comparison graphs, not just saying "ARM wins" on that front, which doesn't really say much.

                Comment


                • #48
                  NEON should substantially increase performance on these benches

                  Without knowing the details of the test suite (which indeed is a serious disadvantage), I would have to surmise that NEON wasn't enabled in the build. It's a real PITA to get NEON support but a real performance payoff if you have it. Note these posted benchmarks...


                  Comment


                  • #49
                    Originally posted by Zetbo View Post
                    The situation with Android is ridiculous. I have HTC Desire and this is my first and probably last Android phone(unless the situation changes). It's rooted and running oxygen rom. I like it now, but I'm not going to buy a new one unless the manufacturer guarantees that they will support it atleast 2 years. These phones are so full of proprietary crap(graphics,radio,camera) that the rom-community have very hard time dealing with these things.
                    This is also the case in laptops. I reinstall Windows 7 on my HP, but nothing works as expected, no shortcut keys, no bluetooth... Nvidia driver were easy to obtain, but drivers from HP were all named in obscure hex code. It is not different, if not even harder, from reinstalling a Debian, where I can even get a nice synaptics driver.

                    Do not expect Win phones to fix these problems. Shame to those hardware producers.

                    Those hardware manufacturers should follow an existing open standard or at least open their API. That would make life of both Linux and Windows easier.

                    Comment

                    Working...
                    X