Database Users

MIPS Technology fot 5X Greater Speed

has anyone heard of this: Myriad’s Dalvik Turbo VM replaces the standard Android Dalvik engine, accelerating performance up to 5x on real-world Android™ applications running on MIPS-Based™ devices. It goes on to say, "With Dalvik Turbo VM, MIPS licensees can create SoCs with faster, more complex applications and richer game graphics optimized for Android smartphones and other high-performance consumer devices without requiring significant increases in device memory. The VM also provides substantial battery life improvements when running resource intensive tasks, all while retaining full compatibility with existing software. Myriad’s Dalvik Turbo VM is operational on all current versions of Android up to and including versions 2.1 (Éclair) and soon to be available for 2.2 (Froyo). Here's a link to an article. http://www.mobilegadgetnews.com/index.php?showtopic=33922 they further say, An evaluation version of the optimized VM will be available free-of-charge through the Android on MIPS community at www.mipsandroid.org as of August 1, 2010. For information on commercial distribution, contact Myriad Group at [email protected]. Sure sounds too amazing to be true. What's the catch? Can anyone comment please

JIT Optimization

Is all the 2.2 roms for vibrant JIT Optimization enabled?
I heard that JIT would make our Vibrant more fast....

seems not, jit in 2.2 only optimized for some cpus, the cpu vibrant used is been optimized in android 2.3, same as nexus s

2.2 has jit. jit typically improves performance on all phones running it, but jit's improvements are dependent on what app you are running.

the reason jit isn't apparent on our phones is due to pretty much 2 reasons.
1) is due to how samsung built the CPU in our phones.
While it is arm a8 based, there are other things companies add to it to make it more targeted. Samsung designed part of this different than qalcom did.
2) Google's coding
Google implemented jit with a "spcific" generalization for it (i.e, they kinda based it around qalcom cpu's). Since the vibrant had a different implementation of a specific feature that benifited from jit, the jit optimization was rendered "unoptimised" and therefore we have a "slower" jit effect.
In real world practice, jit doesn't help our phones that much, it's more synthetic.

geoffcorey said:
the reason jit isn't apparent on our phones is due to pretty much 2 reasons.
1) is due to how samsung built the CPU in our phones.
While it is arm a8 based, there are other things companies add to it to make it more targeted. Samsung designed part of this different than qalcom did.
2) Google's coding
Google implemented jit with a "spcific" generalization for it (i.e, they kinda based it around qalcom cpu's). Since the vibrant had a different implementation of a specific feature that benifited from jit, the jit optimization was rendered "unoptimised" and therefore we have a "slower" jit effect.
In real world practice, jit doesn't help our phones that much, it's more synthetic.
Click to expand...
Click to collapse
i'm curious where you are getting this info... cause i can't find anything from google saying they optimized jit for the snapdragon.
snapdragon and hummingbird use the same isa, so while the hw implementation is different that shouldn't realistically have much impact on performance.
but that isn't as relevant as the fact that jit is reducing the necessity to interpret (and reinterpret) code which is where a lot of the performance benefits of jit are.

funeralthirst said:
i'm curious where you are getting this info... cause i can't find anything from google saying they optimized jit for the snapdragon.
snapdragon and hummingbird use the same isa, so while the hw implementation is different that shouldn't realistically have much impact on performance.
but that isn't as relevant as the fact that jit is reducing the necessity to interpret (and reinterpret) code which is where a lot of the performance benefits of jit are.
Click to expand...
Click to collapse
iirc humming bird and snapdragon (well qalcom chips for the most part) implement SIMD is different bit sizes.
qalcom uses 128bit while hummingbird uses 64bit. Since google worked with a lot of qalcom chips, i'm assuming the 2.2 jit was optimized more for the higher bit length SIMD than what samsung used. With 2.3, google optimized for larger and smaller SIMD bit lengths.

geoffcorey said:
iirc humming bird and snapdragon (well qalcom chips for the most part) implement SIMD is different bit sizes.
qalcom uses 128bit while hummingbird uses 64bit. Since google worked with a lot of qalcom chips, i'm assuming the 2.2 jit was optimized more for the higher bit length SIMD than what samsung used. With 2.3, google optimized for larger and smaller SIMD bit lengths.
Click to expand...
Click to collapse
yeah, i remember seeing that somewhere with the SIMD bit length. so now, is it something that can be optimized or is it simply a hw limitation/difference?

Yes, Google optimized hit to work with both the Samsung simd and the Qualcomm simd in 2.3. But it 2.2, the Samsung simd optimization isn't there and there really isn't a way to work around it.
Sent from my SGH-T959 using XDA App

geoffcorey said:
Yes, Google optimized hit to work with both the Samsung simd and the Qualcomm simd in 2.3. But it 2.2, the Samsung simd optimization isn't there and there really isn't a way to work around it.
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
seems like it would manifest somewhere, but so far running cm7 i'm getting maybe a little better performance than 2.2 roms. same linpack and quadrant. granted cm7 is far from perfect. more what i'd expect just from progress on the os than an optimization. and what about moto? are the omaps just screwed until google decides that moto is their next nexus manufacturer?

funeralthirst said:
seems like it would manifest somewhere, but so far running cm7 i'm getting maybe a little better performance than 2.2 roms. same linpack and quadrant. granted cm7 is far from perfect. more what i'd expect just from progress on the os than an optimization. and what about moto? are the omaps just screwed until google decides that moto is their next nexus manufacturer?
Click to expand...
Click to collapse
i think the omaps have a wider SIMD bit length than samsung chose, so they saw improvements in the 2.2 jit.
I think the reason CM7 hasn't show much optimization is jit is because it still has a lot of debugging enabled in the kernel level.

funeralthirst said:
seems like it would manifest somewhere, but so far running cm7 i'm getting maybe a little better performance than 2.2 roms. same linpack and quadrant. granted cm7 is far from perfect. more what i'd expect just from progress on the os than an optimization. and what about moto? are the omaps just screwed until google decides that moto is their next nexus manufacturer?
Click to expand...
Click to collapse
CM7 Quadrant CPU score:5800
2.2 Roms Quadrant CPU score:1500
But i think it just skip the H.264 decoding test to achieve the high score(like the HTC devices which have qualcomm cpu)

plane501 said:
CM7 Quadrant CPU score:5800
2.2 Roms Quadrant CPU score:1500
But i think it just skip the H.264 decoding test to achieve the high score(like the HTC devices which have qualcomm cpu)
Click to expand...
Click to collapse
really? my quadrant is about 1500 on cm7 and an average of about 14mflops on linpack. and mflops should directly relate to simd/neon implementation.

plane501 said:
CM7 Quadrant CPU score:5800
2.2 Roms Quadrant CPU score:1500
But i think it just skip the H.264 decoding test to achieve the high score(like the HTC devices which have qualcomm cpu)
Click to expand...
Click to collapse
the number is not important, it's the breakdown of numbers (i.e. what's the number in the i/o portion of that score?).

OpenCL... you seen this?

Hi guys, just alerting you to the presence of this: http://www.engadget.com/2013/01/04/opencl-mod-for-the-kindle-fire-hd/
Seems pretty good, eh? You think amazon will end up working with this? It'd be pretty awesome. :victory:

jamajenx said:
Hi guys, just alerting you to the presence of this: http://www.engadget.com/2013/01/04/opencl-mod-for-the-kindle-fire-hd/
Seems pretty good, eh? You think amazon will end up working with this? It'd be pretty awesome. :victory:
Click to expand...
Click to collapse
good

PowerVR GPU OpenCL mod for the Kindle Fire HD Series
jamajenx said:
Hi guys, just alerting you to the presence of this: http://www.engadget.com/2013/01/04/opencl-mod-for-the-kindle-fire-hd/
Seems pretty good, eh? You think amazon will end up working with this? It'd be pretty awesome. :victory:
Click to expand...
Click to collapse
jamajenx,
This is a great find! Thank you, we will have to take a peek at the code to see how we can better improve the overall PowerVR GPU Graphics performance.
We have tested Chainfire 3D Pro: https://play.google.com/store/apps/details?id=eu.chainfire.cf3d.pro&hl=en
This had a nice improvement on the overall OpenGL performance on the Kindle, give it a try. Just in case OpenCL and OpenGL is confusion to the reader, here is more information.
OpenGL (Open Graphics Library) is one of the most popular tool-sets available for graphical processing, and many computer games and CAD tools rely on it for 3-Drendering. Originally developed by Silicon Graphics in the early 1990s, OpenGL has been ported to Windows, Linux, Mac OS, and many embedded devices. On desktop computers, a modern OpenGL application consists of two parts: a host application that runs on the CPU and special-purpose routines called shaders that execute on the graphics processing unit, or GPU. In general, the CPU handles complex graphical routines such as physics and geometry and the GPU performs simple tasks like assigning positions to verticals and colors to pixels.
In contrast, OpenCL (Open Compute Language) is only a few years old and isn't nearly as well-known as OpenGL. However, it allows developers to access GPUs (and many other devices) for purposes other than graphics. Because of this general-purpose GPU (GPGPU) processing, OpenCL is frequently employed to crunch numbers at high speed, and common OpenCL applications include data sorting, statistical computation, and frequency analysis. An OpenCL application consists of a host application that runs on the CPU and general-purpose routines called kernels that can execute on any OpenCL-compliant device, including a GPU.

prokennexusa said:
jamajenx,
This is a great find! Thank you, we will have to take a peek at the code to see how we can better improve the overall PowerVR GPU Graphics performance.
We have tested Chainfire 3D Pro: https://play.google.com/store/apps/details?id=eu.chainfire.cf3d.pro&hl=en
This had a nice improvement on the overall OpenGL performance on the Kindle, give it a try. Just in case OpenCL and OpenGL is confusion to the reader, here is more information.
OpenGL (Open Graphics Library) is one of the most popular tool-sets available for graphical processing, and many computer games and CAD tools rely on it for 3-Drendering. Originally developed by Silicon Graphics in the early 1990s, OpenGL has been ported to Windows, Linux, Mac OS, and many embedded devices. On desktop computers, a modern OpenGL application consists of two parts: a host application that runs on the CPU and special-purpose routines called shaders that execute on the graphics processing unit, or GPU. In general, the CPU handles complex graphical routines such as physics and geometry and the GPU performs simple tasks like assigning positions to verticals and colors to pixels.
In contrast, OpenCL (Open Compute Language) is only a few years old and isn't nearly as well-known as OpenGL. However, it allows developers to access GPUs (and many other devices) for purposes other than graphics. Because of this general-purpose GPU (GPGPU) processing, OpenCL is frequently employed to crunch numbers at high speed, and common OpenCL applications include data sorting, statistical computation, and frequency analysis. An OpenCL application consists of a host application that runs on the CPU and general-purpose routines called kernels that can execute on any OpenCL-compliant device, including a GPU.
Click to expand...
Click to collapse
Just noticed, it says incompatible with ics, any risks from doing this on fire hd?

jamajenx said:
Just noticed, it says incompatible with ics, any risks from doing this on fire hd?
Click to expand...
Click to collapse
OH GOD OTHER MORE, chainfire 3d is compatible with kindle fire hd and some ics and jb devices!

Chainfire3D OpenGL Upgrade
jamajenx said:
Just noticed, it says incompatible with ics, any risks from doing this on fire hd?
Click to expand...
Click to collapse
jamajenx,
We have tested successfully tested Chainfire3D on the Kindle. Yes, we noticed that warning, I do not understand except to say the ugarde went well and Chainfire3D did increase the OpenGL Gaming Performance.

Does linaro make a difference?

I notice some ROMs and kernels use linaro. I have tried them and others. I don't notice a difference in speed or battery. What is the advantage?
Sent from my Nexus 7 using XDA Premium HD app

The kernel sources compile faster. LOL
Hard to imagine that would be important to an end user.
There are probably some corner cases where code that is specifically crafted to take advantage of compiler features will execute more efficiently, but that's not the case when comparing compilation of identical sources by two different compilers.

It does on older phones like when I built Roms for the galaxy exhibit 1ghz one core 512mb ram phone, linaro literally doubled the speed but on the n7 Google has it pretty much fully optimised
Sent from my Nexus 4 @1.72 GHz on Stock 4.2.2

bftb0 said:
The kernel sources compile faster. LOL
Click to expand...
Click to collapse
For many codebases, moving to a newer version of gcc actually slows down the compilation process: http://gcc.gnu.org/ml/gcc/2012-02/msg00134.html
But switching to clang (where possible) sometimes helps.
Most compiler developers are focused heavily on producing optimal (and correct) output; compile time is a secondary consideration. It's relatively easy to write a compiler that runs fast but generates slow/bloated code. Good optimization requires a great deal of computation (and often RAM too).
There are probably some corner cases where code that is specifically crafted to take advantage of compiler features will execute more efficiently, but that's not the case when comparing compilation of identical sources by two different compilers.
Click to expand...
Click to collapse
Each new generation of gcc adds more techniques for optimizing existing code. You can see the effects when a standard benchmark is built by different compilers and run on the same system: http://www.phoronix.com/scan.php?page=article&item=gcc_42_47snapshot&num=3
As you can see, the changes are fairly subtle.
With respect to rebuilding Android using another compiler: you're more likely to notice a difference if your workload is heavily CPU-bound and if your current ROM was built by a much older compiler.

SW686 said:
Each new generation of gcc adds more techniques for optimizing existing code. You can see the effects when a standard benchmark is built by different compilers and run on the same system: http://www.phoronix.com/scan.php?page=article&item=gcc_42_47snapshot&num=3
As you can see, the changes are fairly subtle.
Click to expand...
Click to collapse
Yup. That was precisely my point - subtle to the point that they are only observable via careful benchmarking - but (despite claims to the contrary by enthusiastic folks on the internet) probably not discernible by users in a blind trial comparison without the aid of a stopwatch. Our raw perception of "how long something takes" simply is not accurate at the few-percentage-points level... and that's what the OP stated "I don't notice a difference".
Put another way, if a short one-second task becomes a 950 ms task I won't be able to notice the difference, or if a 60 second task becomes a 57-second task, I won't be able to notice that either (without a stopwatch). Both are 5% improvements.
Which is not to say that folks can't be interested in knowing they have a kernel or tweak that is 2% "better" than everybody else's - but they shouldn't over-sell the perceptibility of the actual gains involved.
I would like to see benchmark measurements of IRX120's claim; I have a hard time believing Samsung left a 100% performance gain "on the table" for a phone which was just released one month ago...
cheers

bftb0 said:
I would like to see benchmark measurements of IRX120's claim; I have a hard time believing Samsung left a 100% performance gain "on the table" for a phone which was just released one month ago...
Click to expand...
Click to collapse
To take a 50% performance hit due to the compiler, they would have to screw up something big, e.g. using a softfp toolchain on hardware that supports hard float[1]. Or accidentally building everything with -O0.
Even then, only the part of the workload using floating point would suffer, and that's nowhere near 100% for most operations. Maybe certain benchmarks.
So, as you said, most users probably wouldn't notice. These devices aren't exactly used for Bitcoin mining or computing Mersenne primes.
Also, ever since Froyo, Dalvik has implemented JIT to optimize hotspots. JIT code is typically generated by the VM, not by the native C compiler. This means that a large percentage of the cycles consumed by an application could be spent on instructions emitted by Dalvik directly, and not from anything originating in gcc.
And of course, applications that perform heavy computation often ship with their own native (binary) libraries. So switching to the Linaro toolchain is unlikely to have much of an impact on games or non-WebView browsers.
[1] http://www.memetic.org/raspbian-benchmarking-armel-vs-armhf/

[Review WIP] Testing Threadripper 1950X & Intel Core i9-7900X

As mentioned in the "Behind the Scenes" update, we now have a CPU sample from AMD and Intel to do some high end desktop testing.
If there is something you want to have tested, please add it here. If we don't include it in the review we'll add that information here.
My plan of attack on both is as follows:
1) Stock CPU behavior. RAM will be set at XMP settings. Make sure this works as this is our baseline.
2) Overclock beahvior. The Threadripper 1950X will be tested using a different all-in-one cooler due to the size of the CPU.
I have a cooler that will already work with the 7900X - 240mm only though.
CPU tests (Phoronix Test Suite), Android build times are always tested.
We're adding building Android Studio from source, but I will do that last.
Still struggling to get temps monitored while doing these tests. I may research this further.

Is this review still coming, I'm interested in AOSP build times.