For intel chips only?
I can't work out from the article if the compiler will emit native Arm code or not?
Intel has released the Intel C++ Compiler v13.0 for Android OS, its first attempt at delivering an optimizing C/C++ compiler designed specifically for Google's mobile platform. The release is notable for a number of reasons. First, the overwhelming majority of Android devices are currently built around chips based on the ARM …
I can't work out from the article if the compiler will emit native Arm code or not?
"No. The Intel C++ Compiler for Android OS produces code that runs only on Android devices that use Intel processors."
Isn't that a really small market?
"Isn't that a really small market?"
To channel Balldrick: No, it is even smaller than a really small market.
So, it is indeed difficult to ascertain what processors the compiler works with.
I would have had to create an account to read anything from the link I did choose to follow so decided to ask, as I thought that it was info the article should have been clear on.
>Isn't that a really small market?
This is no more than yet another demonstration of how desperate Intel is to get into phones. Can't imagine this is anything other than another marketing tool (created to give its chips a spurious boost on benchmarks and press releases)
Little hint to Intel: Less $$$$$ on marketing and more on R&D. All this "yeah, the last Atom was a bit shit really... but the next one will be nearly as good as ARM... honest" and fiddling benchmarks is becoming old and tired now. Here's an Idea: Why not try making a really good part for a change? Something good enough to sell itself? You never know... people might even buy a few.
I've been able to target multiple CPUs with the GNU tool chain for decades.
" ... can often output executable code that performs better .."
Having benchmarked various C compilers (including Intel's), I find marketing statements like that always jarring. If you compare good compilers, you will always find that one performs better than the other for some applications, but worse for some, and the combination of the specific target chip and compiler options also have a large effect (and not always in an obvious way: often turning on all superduper optimization options can actually make your code slower!).
If a vendor says his compiler makes faster code than the competitor's, at best he really means it makes faster code for some benchmarks under some particular option combination, and for some CPU version. This has almost no relationship with how the applications you care about will behave on the machines you use.
While I wholeheartedly agree with what you're saying, I will add that in my own past experiences I have found that the Intel compiler is outstandingly good at optimising code. Far better than any other compiler I've used.
Outstandingly good at optimising *for genuine Intel* silicon. There have been consistent, believable claims of dirty tricks in the Intel compilers. Not just generating code poorly optimised for rival silicon, claims that extra code is inserted specifically to slow them down.
As a result Intel's compilers should be avoided unless you know the programmes will run on Intel silicon.
Luckily there doesn't seem much scope for fun&games on the Android version, with no hint any other x86 CPUs will ever be inflicted on it. There is the slim niche of Android on PC, it would be interesting seeing if the compiler messes with AMD machines even without any real reason to do it.
But by how much?
gcc is continually improving and Intel even helps to make gcc better. That makes the difference between proprietary compilers and gcc smaller as time goes on.
Unless you're doing some obscenely computationally intensive tasks, the Intel compiler isn't going to make a jot of difference other than scoring Intel a tick-in-a-box. Not really worth all the signing up.
"Unless you're doing some obscenely computationally intensive tasks, the Intel compiler isn't going to make a jot of difference other than scoring Intel a tick-in-a-box. Not really worth all the signing up."
I'm from the HPC world and while I agree with the "computationally intensive" bit that's not the only reason for getting a compiler. Different compilers have different debugging capabilities and expose different problems in code, and so I always try out code with a number of different compilers while developing - to get sucked into a "one true compiler" mentality can be very dangerous. So while I'm not sure about the relevance of the execution speed here, the possibility of checking the code with another compiler can only be a good thing.
Compiler targets underlyingcore functions in Intel based Android phones --> users rave about sharper performance, crisper game play, whatever enabled by faster executing core code --> Word of mouth increases sales of Intel based Android phones --> Fat bonuses and trebles all round.
But that Ubuntu malarkey sounds like a real handicap on this plan.
And of course while in theory an Intel written compiler should have some great tweaks, since they should be the best motivated people to explore their own architecture there is one question.
Where are the benchmarks for execution, not compilation?
And given Intel's dealing with hardware benchmarks "proving" their embedded processors are better than ARM's (which they weren't) could you trust those results?
Hardly anyone actually uses Intel's compilers in the real world, the reason they bought it (I think from DEC/Compaq?) was to improve their results on SPEC benchmarks - i.e. marketing. They tune their compilers to "break" the benchmarks, and realize higher scores because there are usually some subtests that are weaker and amenable to such cheating.
The mobile benchmarks being used in the Android world like geekbench and Antutu are of such unbelievably shitty quality that Intel will be able to easily engineer their compiler to greatly improve over the scores gcc obtains, and hope to fool consumers into demanding x86 Android devices by making them think they're missing out on a lot of performance if they choose an ARM phone.
ICC has always produced code that runs significantly faster than GCC, and despite having had a decade and a half to catch up and AMD backing, GCC has failed to close the gap by much. Every x86 processor since the Pentium MMX has had vectorization capabilities, which means that for sensibly written code (tall order for most programmers, but bear with me) you will get code that runs 2-8x faster (MMX can process two 32-bit ints in parallel, SSE can process 4 floats or ints or 2 doubles in parallel) than non-vectorized code.
The 8x faster extreme is a bit of an oddity from back in the Pentium 4 days - it broke up operations into micro-ops in a way that didn't work too well without good compiler support, so code generated by most compilers ran slower, but ICC generated code faster. Pentium 4 flopped because it needed a decent compiler to make it run code faster clock-for-clock than the Pentium 3, but with a decent compiler it was actually faster clock-for-clock (by about 20%) for suitably written C or C++ code.
Last I checked ICC generated code ran no slower than GCC code in the worst case (pure pointer chasing, no processing), usually 30-50% faster (e.g. MySQL, google for the pre-Oracle paper on the subject), and up to 4-8x faster on tight number-crunching loops (e.g. custom curve fitting functions I was writing a while back).
I'm an open source supporter and contributor, but it's important to give credit where it's due and not let FOSS prejudice cloud judgements. GCC's vectorization support was years late to the party and is still after all this time nowhere nearly as good as ICC's.
I guess some developers may decide to compile two versions of their game/app one for Intel devices and one for the rest since its a free download, although without being a programmer i admit i don't know how much extra work is involved in compiling your code for the two different cpus. And if they begin charging for it i don't see many takers with the Intel Android market being so small
If you use NDK there's no other option but compiling for each target. NDK is there for raw speed and any platform you fall back to Java for (or rely on Intel's ARM->x86 translator layer) is crippled.
As I said up the page, with no x86 competition to monkey wrench there's no obvious downside to using Intels compiler. Apart from the insanely restrictive platforms it runs on. TBH though there's also not much point using it over gcc, there's so much variance in performance across Android devices losing a few percent hardly matters.
It's not just about benchmarketing. If you could get, say, 10% better battery life simply by compiling everything native with a better compiler, everyone using Atom-based Androids would benefit. And Intel *should* know all the tricks about minimising the power consumption of their own chips better than anyone else.
That I'll start to see more optimized apps and more numbers of apps that work with my Motorola Razr i ?
As an added benefit, all generated binaries are guaranteed to be Patriot Act compliant.
Really, why not? Chuck in your email address, and that's it. There's nothing more to it. What geek turns up his/her nose at a compiler?
Now I just need a phone running Android with an Intel processor...