Database Develop

Nexus one 2.2 true cpu speed?

I use chess engines to benchmark processors. One such program is Droidfish.
Can anyone with the Nexus one 2.2 download and install Droidfish from the market (it's free). Open the program. Once opened, hit the 'M' underneath the chess board and choose Analysis Mode. Watch the nps number in the bottom right for 30 sec. Post the number it reaches here in this thread. For example, the Vibrant with Nero 3 (no voodoo) reaches 113000 nps after 30 seconds. I'm very curious of this number so that I can compare to the quandrant scores (to see how accurate they are).
Thanks!

111466 n1-cm6.1.1

109867 - At normal speed of 998 MHz
127000+ - something upon overclocking to 1113 MHz
My N1's configuration is in my signature

h1a8 said:
I use chess engines to benchmark processors. One such program is Droidfish.
Can anyone with the Nexus one 2.2 download and install Droidfish from the market (it's free). Open the program. Once opened, hit the 'M' underneath the chess board and choose Analysis Mode. Watch the nps number in the bottom right for 30 sec. Post the number it reaches here in this thread. For example, the Vibrant with Nero 3 (no voodoo) reaches 113000 nps after 30 seconds. I'm very curious of this number so that I can compare to the quandrant scores (to see how accurate they are).
Thanks!
Click to expand...
Click to collapse
Who is the developer of "chess engines" ?, no match on appbrain or on the market.
Installed the one from "AI Factory", there is no "M"

PhantomRampage said:
111466 n1-cm6.1.1
Click to expand...
Click to collapse
meechto said:
109867 - At normal speed of 998 MHz
127000+ - something upon overclocking to 1113 MHz
My N1's configuration is in my signature
Click to expand...
Click to collapse
So without overclocking it achieves the same as my vibrant. So the posted quadrant for cpu is grossly inflated.
Thanks.

CPU has different functions, and different CPUs perform the same commands differently. Snapdragon has much faster FPU, it shows in some benchmarks and doesn't show in others.

G1 ROM with JIT simple interface?

I'm looking for a fast ROM, battery is not so important, with JIT compiling that's stable....anything anyone can suggest?
Currently using Super AOSP (using it now, some apps don't run, otherwise stable). Radio=27.08, Haykuro SPL....
Most of the loads I've tried are either buggy or I can't load them for one reason or another (A lot of roms fail during load - is that my phone?)
I don't need a lot of bells and whistles, I do EMAIL, I do Web Surf and play an occasional game, but I don't really need lots of other things, I would gladly give up visuals for some increased speed - currently 2.6 MFLOPS (Linpack free).
Thanks.

best I can do for now....4 MFLOPS on G1
I think I found the best for me right now, Ginger Yoshi gives me 4 MFLOPS, which is not as good as I wanted, but I've set my sites lower.
It is very smooth - it does not feel refined, don't need it, everything works.
I can recommend SuperAosp, it is very refined, everything looks finished. It is not nearly as fast as Ginger Yoshi, but it is pretty and stable.
I did try several other loads, and I'm thankful that there are developers out ther, so I won't mention names, but at least one of these loads gets a lot of press on here and on my phone, I'd call it buggy.
Super Aosp and Ginger Yoshi are both stable.

It sounds funny, but try turning off JIT. It seems to make roms a lot more stable; I'd guess the G1 just isn't up to snuff for JIT. It makes benchmarks lower, but in practice it works much smoother.

Thanks for the reply!
I am turning off JIT...Then let the phone sit for a couple of mins to finish any housekeeping.
Ginger-Yoshi
JIT = Yes, Speed = 4.1 MFLOPS
JIT = No, Speed = 2.45 MFLOPS
Odd note, one of my non JIT runs ran at 1.6 MFLOPS, I didn't count it since it was so far out, not sure if there was housekeeping going on or what.
Second note, disabling JIT did make installations more stable - I was unable to install and sometimes download a specific application, disabling JIT allowed it to D/L and install.
Super-AOSP
JIT = Yes, Speed = 2.6 MFLOPS
1.6 Google - Rooted, speed to 528 MHz
2.4 MFLOPS
1.6 Google stock
1.4 MFLOPS
I've never run 2.0 or 2.1 so I don't know how they stack up, they do not have JIT, so maybe they are more efficient.
What I really wanted was a 1.6 OS with everything moved to the SD card AND JIT and CPU set to 528 MHz otherwise stock, I expect that is about as fast as this phone can go.
My limited experience:
I can't speak for anyone else but Super-Aosp and Ginger-Yoshi are very stable.
I tried several others that were not so stable, though they have lots of loyal fans, maybe their phones are better than mine.
I agree that we should be able to build a tight system without JIT that is faster, efficiency is the key.
A buddy of mine, has a very fast Android LG Optimus phone - it fly's he can run all sorts of animation, applications etc. and it doesn't seem to affect the speed of the phone...He runs 9 MFLOPS which is WAY above what everyone else with the same phone has...he told me that he isn't modifying the subroutines/calls, he's sort of linking scripts to make things run more efficiently. He's a physicist not a programmer.
He just constantly tinkers with it though - some bits are buggy, it's just a hobby for him, he has development tools right on the phone
My current Ginger-Yoshi runs just over 4 MFLOPS, which is less than I wanted but all I can find so far.

JIT is NOT a good match for this hardware, for the simple reason that JIT consumes more RAM.
What you have is a piece of hardware that is SEVERELY RAM LIMITED. Eating up even more of it causes necessary components to be booted out of memory, which ends up causing long periods of WAITING while those components RELOAD. It can also lead to instability, since the available memory will IN MANY CASES, be insufficient for loading even a single program into memory.
Counting FLOPS is a very poor measure of overall system performance. I would bet you that in terms of overall usability and wasted user time waiting, your phone will actually be FASTER with JIT DISABLED.
Ignore FLOPS. It is irrelevant.

dhkr234 said:
Ignore FLOPS. It is irrelevant.
Click to expand...
Click to collapse
I appreciate your argument and I 100% agree that the phone is ram limited, can you suggest another build that does not use JIT?
My current Ginger-Yoshi is faster and smoother than any 1.6 I've run (I have not run Super D, that was going to be my next target if G-Y was buggy).
That goes back to my original reason for this post...fast enough to play angry birds or whatever I'm doing.
You say to ignore FLOPS, that is the fairest test That I know for different phones,<Millions of> Floating Point Operations Per Second..that bypasses graphics co-processors and gets down the the meat of what's going on inside.
If you can suggest a ROM that runs better than G-Y I am very willing to try it, but right now the very best ROM I've tried is G-Y (not perfect but better than Anything I've run on this phone).

GolfnWrx said:
I appreciate your argument and I 100% agree that the phone is ram limited, can you suggest another build that does not use JIT?
Click to expand...
Click to collapse
I would expect that you can switch on/off JIT in your settings, so you can try if for you JIT helps or not. G-Y doesn't provide this? (Sorry for the question, but I've never tried it ...)
If there is no option within the ROM, you could add
Code:
dalvik.vm.execution-mode=int:fast
to you /system/build.prop to disable JIT, or
Code:
dalvik.vm.execution-mode=int:jit
to enable JIT.
Sent from my Gingerbread on Dream using XDA App

haha, sorry I guess I was not clear
yes, i can enable/disable JIT....what I was asking for though was a stable build that is faster than 2.5 MFLOPS.
There were some people last year that found a way to script one of the roms to be more efficient....IIRC they were able to get up to 3.7 MFLOPS....but I don't see them around any more....no JIT it was a rebuild of 1.6 I think..maybe 2.1, I just don't recall.
That might be the best way to go, or they might have hit an error...I didn't keep up with it.
Thanks for the reply though

So you want a script to spoof Linpack?
Sent from my Gingerbread on Dream using XDA App

dhkr234 said:
JIT is NOT a good match for this hardware, for the simple reason that JIT consumes more RAM.
Click to expand...
Click to collapse
Overall my opinion on JIT (vs. android version)
1.6 - caused some apps problems otherwise seemed the same w/ or w/o jit.. maybe more ram and slower
2.1 - extra ram caused problems with services and slow load times.. improvement at run time minimal.
2.2 - improvement at runtime noticeable but still high memory use and very slow load times
2.3 - incrreased memory use and loadtimes; but more minimal than earlier versions; with screen andimations off/fast perfomance may be acceptibal to many given the better performance of the browser and other higher processing tasks. [at least in a light weight rom]
(Of course this is my opinion durring use .. not a linpack score)

Speed up your Nook Color running ICS+

Hello all, today I will be showing you how to speed up your Nook Color a bit... these methods should work for CM9/CM10/CM10.1/Paranoid Android/etc., but I personally found these out while running PA ICS. The apps you may need to make your phone faster are Ram Manager (Free OR Pro) and No Frills CPU Control (In the case that your ROM doesn't have overclocking in settings). Basically, using these "tweaks" (minus overclock, as whenever I flash a ROM the first thing I do is overclock it), I went from a painfully slow (as in, I was ready to go back to Gingerbread) device to a somewhat faster device. I've seen huge differences in launching games and apps especially, and opening to app drawer seems to be smoother also.
CPU Overclock
Either using No Frills CPU Control or the built-in overclock, set your max CPU speed to the highest on the list (not exceeding 1200, but it shouldn't show anything above that anyhow). Change your governor to either Ondemand or Performance (I personally use Ondemand and have no problems with it). Most of you are probably already overclocked though, so please don't look at me like I'm stupid.
Swap Space
Open up RAM Manager and there should be an option to change your swap space at the bottom. I changed mine to about 48 and am content with that, although I must add it may make your SD card's life shorter. This will increase your RAM, thus allowing you to have more apps open at once.
Force GPU rendering
Open Developer Options in your settings app and check "Force GPU Rendering"... I'm guessing this is one of the biggest factors to my tablet becoming smoother, as from research it helps lower end devices achieve a better framerate, although it may decrease your battery life. Also, I cannot guarantee every app will run great with this. I tested a game (Dynamite Jack) with this setting enabled and it wasn't too shabby at all! But yes, I can definitely see a difference in the overall speed of my Nook Color.
Please tell me how these work for you

I tried these settings, but unfortunately didn't perceive any performance improvement.

Good call on RAM manager. Hadn't seen that before, its going on my NC and RAZR now

Can anyone tell me a good reason for that RAM Manager app to have the permissions it does? Location, Identity, and full network access?

Does NOT work. All this app " no frills CPU" does is provide a GUI front end for the settings already found for our nook color using CM 10+ in its "performace" settings. Also this app does not provide over clocking above our set 1100 MHz. You will need a custom over clocking kernel for the encore for this. Check over on the CM 10 kernel thread n the development section.

New Questions: Hyper Threading

There are some questions i've never seen posted about this phone, maybe they are not that easy to answer:
1) The Intel Atom Z2460-80 (i dont know which one it is) DOES support dynamic frequency switching or scaling or whatever (but the one developed by Intel), in the x86 structure, so: Does the Razr I use this or it just relies on governors?
2) Does it use the 2460 or the 2480 Atom? It doesn't really change anything but I wanna know...
3) Does Android environment support Hyper Threading? (I really hope it does, because Antutu shows two cores, maybe it does or is that app just guessing based on the cpu?
4) Does it run in x86 structure? (because i read it was running on ARM-like instructions but that doesn't sound right...

I'll answer you with what I know. It can be very wrong.
1) RAZR i uses Z2460. And yes, it relies on governors. With ICS Motorola has chosen Interactive governor. With JB they has chosen Ondemand.
2) Atom Z2480 doesn't exists.
3) I believe the Hyper Threading function is bases on the processor. What makes it upscale and downscale it's speed is the own processor, not the OS. Detecting and using more than 1 core it's another story.
4) I think you can't run the instructions of an architecture in the other. It's like speak German to Chinese people. That's why Intel has so much problem speaking with the dev to build their apps to x86. And even these days, we've arround 90% ~ 95% of ported apps.

nomboly said:
There are some questions i've never seen posted about this phone, maybe they are not that easy to answer:
1) The Intel Atom Z2460-80 (i dont know which one it is) DOES support dynamic frequency switching or scaling or whatever (but the one developed by Intel), in the x86 structure, so: Does the Razr I use this or it just relies on governors?
2) Does it use the 2460 or the 2480 Atom? It doesn't really change anything but I wanna know...
3) Does Android environment support Hyper Threading? (I really hope it does, because Antutu shows two cores, maybe it does or is that app just guessing based on the cpu?
4) Does it run in x86 structure? (because i read it was running on ARM-like instructions but that doesn't sound right...
Click to expand...
Click to collapse
1. Frequency switching or scaling will still rely on a CPU governor and kernel drivers.
2. Atom_(system_on_chip)
3. The OS (Android) sees it as two logical threads, whats important is that they share some execution units and cache so it is not a completely independent execution of two logical threads but it does achieve better performance. To speak of it in an easy example If you were to run a threads where it takes each 1 second to finish on a single logical core of the CPU it would take 1 second if it was single core. It would approx take 2 seconds when it shares time between switching threads, but with HTT it might run it in 1.3 seconds. It really depends on workloads but it is a nice feature.
So it supports HTT (hyperthreading technology) in the sense that the OS sees it at like another core in the most fundemental sense.
4. It runs a lot of stuff in x86, but the dalvik VM has a library/plugin called houdini which can perform ARM binary code translation. So it can run a lot of native ARM apps without problems but you might encounter some exceptions eventually.

Omar-Avelar said:
1. Frequency switching or scaling will still rely on a CPU governor and kernel drivers.
2. Atom_(system_on_chip)
3. The OS (Android) sees it as two logical threads, whats important is that they share some execution units and cache so it is not a completely independent execution of two logical threads but it does achieve better performance. To speak of it in an easy example If you were to run a threads where it takes each 1 second to finish on a single logical core of the CPU it would take 1 second if it was single core. It would approx take 2 seconds when it shares time between switching threads, but with HTT it might run it in 1.3 seconds. It really depends on workloads but it is a nice feature.
So it supports HTT (hyperthreading technology) in the sense that the OS sees it at like another core in the most fundemental sense.
4. It runs a lot of stuff in x86, but the dalvik VM has a library/plugin called houdini which can perform ARM binary code translation. So it can run a lot of native ARM apps without problems but you might encounter some exceptions eventually.
Click to expand...
Click to collapse
Thank you both for replying to my question, and I've seen this second post as the most useful of the two. :good:

nomboly said:
Thank you both for replying to my question, and I've seen this second post as the most useful of the two. :good:
Click to expand...
Click to collapse
The apps that doesn't work in ICS on Razr i because of his x86 processor, should work now with Jelly Bean, as the game Subway Surfers. Before it didn't work on ICS on the Razr i, now it works perfectly after i updated to Jelly Bean
Sorry for my bad english.

(INFO)ABOUT THE NEW ART FEATURE(KitKat)

I have open this thread for all(me included)user with no idea about ART,so here are some infos about it,what is ART,how does it work,pro+cons.
Maybe its helpfull for some peeps here.Source: Android Police
Link p1
Link p2
-------------
Part 1:
It's fair to say that Android went through some chaotic years in the beginning. The pace of development was frantic as the operating system grew at an unprecedented rate. An as-yet undetermined future led to decisions that were made to conform to existing hardware and architectures, the available development tools, and the basic need to ship working code on tight deadlines. Now that the OS has matured, the Android team has been giving more attention to some of the components that haven't aged quite as well. One of the oldest pieces of the Android puzzle is the Dalvik runtime, the software responsible for making most of your apps run. That's why Google's developers have been working for over 2 years on ART, a replacement for Dalvik that promises faster and more efficient execution, better battery life, and a more fluid experience.
What Is ART?
ART, which stands for Android Runtime, handles app execution in a fundamentally different way from Dalvik. The current runtime relies on a Just-In-Time (JIT) compiler to interpret bytecode, a generic version of the original application code. In a manner of speaking, apps are only partially compiled by developers, then the resulting code must go through an interpreter on a user's device each and every time it is run. The process involves a lot of overhead and isn't particularly efficient, but the mechanism makes it easy for apps to run on a variety of hardware and architectures. ART is set to change this process by pre-compiling that bytecode into machine language when apps are first installed, turning them into truly native apps. This process is called Ahead-Of-Time (AOT) compilation. By removing the need to spin up a new virtual machine or run interpreted code, startup times can be cut down immensely and ongoing execution will become faster, as well.
At present, Google is treating ART as an experimental preview, something for developers and hardware partners to try out. Google's own introduction of ART clearly warns that changing the default runtime can risk breaking apps and causing system instability. ART may not be completely ready for prime time, but the Android team obviously feels like it should see the light of day. If you're interested in trying out ART for yourself, go to Settings -> Developer options -> Select runtime. Activating it requires a restart to switch from libdvm.so to libart.so, but be prepared to wait about 10 minutes on the first boot-up while your installed apps are prepared for the new runtime. Warning: Do not try this with the Paranoid Android (or other AOSP) build right now. There is an incompatibility with the current gapps package that causes rapid crashing, making the interface unusable.
How Much Better Is It?
For now, the potential gains in efficiency are difficult to gauge based on the version of ART currently shipping with KitKat, so it isn't representative of what will be possible once it has been extensively optimized. Thus far, estimates and some benchmarks suggest that the new runtime is already capable of cutting execution time in half for most applications. This means that long-running, processor-intensive tasks will be able to finish faster, allowing the system to idle more often and for longer. Regular applications will also benefit from smoother animations and more instantaneous responses to touch and other sensor data. Additionally, now that the typical device contains a quad-core (or greater) processor, many situations will call for activating fewer cores, and it may be possible to make even better use of the lower-powered cores in ARM's big.LITTLE architecture. How much this improves battery life and performance will vary quite a bit based on usage scenarios and hardware, but the results could be substantial.
What Are The Compromises?
There are a couple of drawbacks to using AOT compilation, but they are negligible compared to the advantages. To begin with, fully compiled machine code will usually consume more storage space than that of bytecode. This is because each symbol in bytecode is representative of several instructions in machine code. Of course, the increase in size isn't going to be particularly significant, not usually more than 10%-20% larger. That might sound like a lot when APKs can get pretty large, but the executable code only makes up a fraction of the size in most apps. For example, the latest Google+ APK with the new video editing features is 28.3 MB, but the code is only 6.9 MB. The other likely notable drawback will come in the form of a longer install time for apps - the side effect of performing the AOT compilation. How much longer? Well, it depends on the app; small utilities probably won't even be noticed, but the more complex apps like Facebook and Google+ are going to keep you waiting. A few apps at a time probably won't bother you, but converting more than 100 apps when you first switch to ART is a serious test of patience. This isn't entirely bad, as it allows the AOT compiler to work a little harder to find even more optimizations than the JIT compiler ever had the opportunity to look for. All in all, these are sacrifices I'm perfectly happy to make if it will bring an otherwise more fluid experience and increased battery life.
Overall, ART sounds like a pretty amazing project, one that I hope to see as a regular part of Android sooner rather than later. The improvements are likely to be pretty amazing while the drawbacks should be virtually undetectable. There is a lot more than I could cover in just this post alone, including details on how it works, benchmarks, and a lot more. I'll be diving quite a bit deeper into ART over the next few days, so keep an eye out!
---------------------------------------------
Part 2 in next post.....

Part 2
---------
By now you've probably heard about ART and how it will improve the speed and performance of Android, but how does it actually perform today? The new Android Runtime promises to cut out a substantial amount of overhead by losing the baggage imposed by Dalvik, which sounds great, but it's still far from mature and hasn't been seriously optimized yet. I took to running a battery of benchmarks against it to find out if the new runtime could really deliver on these high expectations. ART is definitely showing some promise, but I have to warn you that you probably won't be impressed with the results you'll see here today.
Reality Check
Let's be honest, benchmarking apps tend to be inaccurate and unreliable, often giving wildly varying results even when run in precisely identical situations. However, they are the only option available for recording meaningful and measurable values on performance. Further, since most popular benchmarks are built on the NDK (Native Development Kit), they won't gain any benefit from running under ART. Despite these limitations, there are some interesting and unexpected results that help us learn a little more about the current state of performance.
How The Benchmarks Were Run
Each benchmark was run at least 4 times on a completely stock Nexus 5 (it isn't even rooted) with both Dalvik and ART. To ensure there was no interference from apps at startup, a minimum of 5 minutes was given after a reboot before any tests were run. In addition to the 6 benchmarking apps listed below, I also tried 2 browser benchmarks (SunSpider & BrowserMark) in Chrome, but neither displayed significantly different scores. So, let's get to the results.
Linpack for Android
One of the key factors in getting good test results is knowing that the tools are measuring the right thing. While many of the benchmark apps target the NDK, a few stick to the SDK. The first and most consistent among them is Linpack for Android, a port of the already popular benchmarking app used throughout numerous computing platforms. It produces a score by performing a series of calculations on floating point numbers. I think this is an obvious choice after reading the description, "This test is more a reflection of the state of the Android Dalvik Virtual Machine than of the floating point performance of the underlying processor." Thanks to ART, scores are 10%-14% higher than they would be with Dalvik. Not too shabby…
Real Pi Benchmark
Calculating digits of Pi is another popular way of stressing a processor, and particularly suitable because most methods stick to integer calculations and avoid floating-point math entirely. Along with Linpack, this gives us coverage of both basic mathematical operations. On top of it, Real Pi happens to use native code to perform the AGM+FFT formula, but uses Java for Machin's formula. On the native side, ART came out about 3.5% faster, probably due to interface optimizations rather than mathematical performance. More importantly, testing with the java code turned out to be 12% faster. (link) Note: in this test, lower numbers are better.
Quadrant Standard
The previous tests are highly specific to mathematical performance, so it's time to branch out to test more of the system. Both Linpack and Real Pi show some positive improvement with ART, but Quadrant gave a result that borders on the amazing, perhaps even too good. The CPU score is off the charts for ART, almost doubling that of Dalvik, which is substantially better than even the most optimistic estimates we've heard so far... While tests for I/O, 2D, and 3D rendering show fairly negligible differences, Dalvik does take an oddly high 9% advantage in the memory test.
3D Mark
I was leery of using a benchmarking app that clearly focuses on the NDK, as it theoretically shouldn't be affected very much by ART. However, as the tests were run, an interesting pattern emerged where the Dalvik runtime repeatedly held a slight advantage. It's difficult to attribute a reason for Dalvik to do better here, but I'm open to theories.
AnTuTu Benchmark
Breaking performance down even further, AnTuTu helps to expose a pattern. It's increasingly clear that ART is making significant strides with floating-point operations, but doesn't usually turn out huge gains for integers. A strong showing in "RAM Operation" also hints at better use of caching as opposed to just raw memory I/O. These high scores indicate areas where the Dalvik virtual machine was probably very expensive, causing more extensive overhead. The other results weren't particularly remarkable except for the Storage I/O, which might suggest a couple of specific optimizations. One significantly low score appears for UX Dalvik, but it's not clear what AnTuTu is measuring, so this may not be particularly relevant.
CF-Bench
For the ultimate in number production, Chainfire's own benchmark tool takes out a lot of the guesswork by performing tests built on both the SDK and NDK. Again, native code displays a small but curious advantage on Dalvik. Here we can see the integer calculations are swinging back towards Dalvik, as well. Mostly confirming the pattern, floating-point operations demonstrate a significant speed gain, this time in the 23%-33% range.
Other Interesting Measurements
Measuring the first boot after switching runtimes isn't your typical test, no doubt, but the time it takes is quite striking. I wanted to record just how long it took to complete both the App Optimization step and then the total time to actually reach the unlock screen. When I ran this test, I had 149 apps installed.
The Other Stuff
While numbers can be helpful, they don't tell the full story. Benchmarks usually push the hardware to work as hard as possible for a few seconds, then switch to a new test that does the same thing. Sadly, this ignores details that aren't easily measured. I don't have a good way to measure the smarter timing of memory management (especially garbage collection) or better handling of multiple threads. While I can't show numbers for these things, I can demonstrate them. The classic test for a browser simply requires flinging the page as fast as possible and watching it try to keep up. After stress testing Chrome for Android with the mobile version of David's gigantic HTC One review, it turns out that even the supercharged SoC of the Nexus 5 can't quite keep up while running on Dalvik… ART, on the other hand, never lost a pixel. Take a look for yourselves.Videos below.
Fast scrolling with dalvik: http://youtu.be/JGyktLPvORU
with ART: http://youtu.be/L9lpCssSdMc
To be fair, switching to the desktop version and giving a single fling will easily send you into blank screen territory, but it's still obvious that the renderer catches up faster on ART than on Dalvik. When more optimizations are in place, maybe we won't be far off from flawless scrolling even in the desktop version. For another demonstration, a user by the name of spogbiper has posted his own side-by-side comparison with two Nexus 7s. The one running ART seems to be more responsive.
Summary And Conclusions
The numbers and the videos together paint a picture of where ART stands today. It will definitely make a difference, but its current incarnation just hasn't matured enough to deliver significant gains. Floating-point calculations and basic responsiveness are obviously reaping the benefits of the new runtime, but that's about it. There's little or no overall improvement for integer calculations, most regular code execution, or much of anything else. In fact, it looks like gamers would be better served by sticking to Dalvik, for now.
Why aren't the benchmarks blowing us away? If I were to make a guess, it's probably because the first goal in developing ART was to make sure it was functional and stable before the heavy optimizations came into effect. If that's the case, there is probably quite a bit of code for error-checking and logging just to ensure everything is operating as it should, which might even be responsible for more overhead than we had with Dalvik. Even in the places where ART doesn't outperform Dalvik, the numbers tend to remain reasonably close. As subsequent versions of the runtime emerge from Mountain View, we should expect to see the performance gap growing wider as ART pulls ahead.
Now for the real question: is it worth switching to ART right now? Google obviously isn't recommending it for regular users, and I tend to agree. While ART seems very solid and I feel like responsiveness is better - possibly just the placebo effect - there are still circumstances where it is unstable and causes apps to crash. If there is even a single instance where you have to switch back to Dalvik to get an app to run correctly, that inconvenience far outweighs the minimal performance gain you might have had. Once I've finished this series, I will probably stick to Dalvik for the remainder of KitKat; and I imagine most people will be better served by doing the same.
Introducing ART from: source.android.com
ART is a new Android runtime being introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer options. This is available for the purpose of obtaining early developer and partner feedback.
Important: Dalvik must remain the default runtime or you risk breaking your Android implementations and third-party applications.
Two runtimes are now available, the existing Dalvik runtime (libdvm.so) and the ART (libart.so). A device can be built using either or both. (You can dual boot from Developer options if both are installed.)
The dalvikvm command line tool can run with either of them now. See runtime_common.mk. That is included from build/target/product/runtime_libdvm.mk or build/target/product/runtime_libdvm.mk or both.
A new PRODUCT_RUNTIMES variable controls which runtimes are included in a build. Include it within either build/target/product/core_minimal.mk or build/target/product/core_base.mk.
Add this to the device makefile to have both runtimes built and installed, with Dalvik as the default:
PRODUCT_RUNTIMES := runtime_libdvm_default
PRODUCT_RUNTIMES += runtime_libart
------------------------------------------------------------
MANY GREEEETZ+STAY ADDICTED!!!!

Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app

velosa said:
Were hi find gapps art?thanks
Sent from my LG-E610 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.

-CALIBAN666- said:
look in app section here in l5 forum,i have uploadet a minipack,also there are more infos.
Click to expand...
Click to collapse
Thanks
Sent from my LG-E610 using XDA Premium 4 mobile app

thank you very much for your work about ART presentation ! very nice and perfect ! :good:
conclusion : don not use ART for the moment on CM11 ! ok ! wait more stability ...

i've downloaded gapps kk from cr3pt thread for cm 11, while i'm waiting for more stability i wanna ask you if they are art compatible.
Best presentation of ART!

When the gapps are odexed than yes.
STAY ADDICTED,GREEEETZ!!!