Hey, check this out, JIT~

[OperationMove]

This will be very interesting to try once we get a rom with 3d acceleration. Let's see what we can really do with this phone! As it stands though, we still have to wait on that.

[haldi15]

mine is 2nd!! look for haldi on linpack

[qzan]

is it normal for the phone to restart during the installation?

[Danation]

is it normal for the phone to restart during the installation?

Make sure to clear your dalvik cache after installation and before rebooting.

[qzan]

Make sure to clear your dalvik cache after installation and before rebooting.

am talking when am entering adb commands, before i even reach the reboot part, does this happen to anyone else?



i set it up an this is my results, but blur an gapps keep fc

[Danation]

Yeah, Blur doesn't seem to like it.

Eclair2Cliq handles it great, though. I did find a bug today (the first.) Kindle won't work when JIT's enabled

[toxigenicpoem]

How so? Running native code is always going to be faster than interpreting.

If we were running native code that would be true, but we are not, your still running dalvik-byte, compiled to machine language at run time or "just-in-time". The DalvikVM team also knowledges that JIT can not uniformly speed up applications.

[Danation]

My answer was a reply to another post. The first post said that JIT would cause long term speed problems.

However, since JIT compiles to machine code, it will always be equal or faster than interpreting, except on initial startup (unless the implementation is horrible, which would be surprising.)

[toxigenicpoem]

My answer was a reply to another post. The first post said that JIT would cause long term speed problems.

However, since JIT compiles to machine code, it will always be equal or faster than interpreting, except on initial startup (unless the implementation is horrible, which would be surprising.)

Dalvik-JIT doesn't just compile everything to machine code, it selectively predicts which code would best benefit from a compilation to machine code (i.e. a huge string of mathmatic operations in a row aka Linpack), meaning your running both JIT and Dalvik-Byte together, every application run in JIT requires an extra 100K sandbox. With limited RAM, on a blur rom - I would agree with Handler, overtime JIT would make the Cliq Slower because of the limited amount of RAM we have.

Deblurred Builds are another story, and SWAP could effectively cancel out any problems. So I still don't agree with you (but completely respect your opinion), because I don't think your looking at the overall platform we're using, and just categorizing JIT in general as beneficial. The Dalvik-VM also accepts Fast and Portable modes, it all matters on the hardware.

[Danation]

I somehow missed this post.

I didn't realize that the Dalvik-JIT compiled stuff to machine code selectively. I guess there are trade-offs either way, but for good performance, I would prefer a full JIT.

[denkai]

has anyone tried JIT with swap on, and what size swap do you think best toxic? (I have my card set up to I believe 24MB or 32MB swap, but it is currently disabled.)

[j_r0dd]

i am un-sticking this thread. JIT will break the system on 2.1 devices atm