ARMvX?

[mingw android]

Seems from:

https://mail.google.com/mail/?shva=1#inbox/13225300fda7cbbd which
links to http://hilbert-space.de/?p=22

...that gcc (this was the code sorcery 4.3.3 version, Android uses
4.4.3 now so things may be better) doesn't handle the intrinsics very
well for Neon (lots of pointless stores and reloads). I reckon it'd be
worth doing a re-test on this, comparing the gcc output again with
4.4.3.

But anyway, 1.5x speed up is better than nothing.

Also, we can guarantee, with armv7a, that vfp3-d16 is available.

Interesting pdf I found:

http://cfile7.uf.tistory.com/attach/205BDC114C41C159142819

It actually looks like thumb-2 often outperforms arm (I'd previously
seen 30% reduction in code size for a 5% drop in performance) due to
memory accesses...

One downside of providing a lot of different versions of the libs is
that we'll be potentially exposing developers to more bugs in GCC, and
ones they may not catch until their apps are released...

On Fri, Sep 2, 2011 at 1:24 PM, BogDan <bog_dan_ro at yahoo.com> wrote:
> Hi,
>
> I'll try to clarify the things a little bit more:
> We are talking about two separate set of libraries and tow separate sets of cpu flags:
> 1. The qt libraries used to compile your application.
> This libraries are compile using official Android cpu flags for arm-v5 and for arm-v7a
>
> (without neon instructions), this cpu flags will be used also to compile your application.
> This cpu flags are not tunned to use any cpu specific instructions set because
>
> we have to ensure your app will run on all platforms.
> This libraries will be shipped by the SDK.
>
>
> 2. The qt libraries deployed by Ministro.
>
> This libraries will use different cpu flags from the one shipped with the SDK,
>
> we'll try tune the cpu flags in order to run faster on specific cpus. Why ?
>
> Because even if your app is not compile with tunned cpu flags it will run
>
> faster because it will use libraries tunned for that cpu. Also most of
>
> the code run by the cpu it will be from Qt libraries not from your
> application so it is very important to have cpu specific tunned qt libs.
>
>
> I thinking to provied the following cpu configurations:
>  - arm-v5 this one will be the same with the one shipped by the SDK.
>  - arm-v6 without fpu
>
>  - arm-v6 with fpu
>
>  - arm-v7 without neon
>  - arm-v7 with neon, even if neon can be detected at runtime and it is used
>
> in a few places in Qt I believe it will be better to compile everything using
>
> neon, because AFAIK gcc produces faster code when this flag is turn on.
>
>
> Minsitro will check your cpu capabilities and will download appropriate
> Qt libs for your cpu, so, your apps will use the best qt libs possible.
> This is why I don't believe bundling qt libs into your package is a solution,
> only for arm you'll need to ship 5 different libs to get the best performance.
>
> Cheers,
> BogDan.
>
>
>>________________________________
>>From: Espen Riskedal <espen at cutehacks.com>
>>To: thomas.senyk at nokia.com
>>Cc: bog_dan_ro at yahoo.com; necessitas-devel at kde.org
>>Sent: Wednesday, August 31, 2011 4:46 PM
>>Subject: Re: ARMvX?
>>
>>On Tue, Jul 19, 2011 at 9:49 PM,  <thomas.senyk at nokia.com> wrote:
>>> Ah I see.
>>>
>>> This document helped me understand that Android has a solid definition (hadn't expected that) of what ABI versions it supports.
>>> Now everything makes a lot more sense :)
>>
>>I agree, this was an eye opener. I think "CPU-ARCH-ABIS.html" should
>>be required reading now! :D
>>
>>Summarized, at the moment there are three ABIs (this is from NDK v6b):
>>
>>"armeabi"
>>- ARMv5TE instructions
>>- no HW floating points
>>- Thumb-1 (or ARM)
>>
>>"armeabi-v7a"
>>- extends and is compatible with armeabi
>>- adds ARM Architecture v7-a instructions
>>- adds Thumb-2
>>- adds HW floating points (vfpu) but calling conventions are kept
>>compatible with armeabi
>>- optionally adds: NEON and friends (should be detected at runtime)
>>
>>"x86"
>>- Pentium Pro instruction set
>>- MMX, SSE, SSE2 and SSE3 instruction set extensions
>>
>>My question then is, why do we plan to build for a lot more
>>variations? On Linux NEON is detected at runtime, but we're planning
>>non-NEON and NEON builds. Why?
>>
>>Another part that explained a lot to me:
>>
>>"It is also possible to build machine code for *two* distinct ABIs by using:
>>
>>   APP_ABI := armeabi armeabi-v7a
>>
>>This will instruct the NDK to build two versions of your machine code: one for
>>each ABI listed on this line. Both libraries will be copied to your application
>>project path and will be ultimately packaged into your .apk.
>>
>>Such a package is called a "fat binary" in Android speak since it contains
>>machine code for more than one CPU architecture. At installation time, the
>>package manager will only unpack the most appropriate machine code for the
>>target device. See below for details."
>>
>>Let's hope Apple doesn't sue them for stealing the Universal binaries concept :D
>>
>>espen
>>
>>
>>
> _______________________________________________
> Necessitas-devel mailing list
> Necessitas-devel at kde.org
> https://mail.kde.org/mailman/listinfo/necessitas-devel
>