Linked by Thom Holwerda on Thu 19th Jun 2014 09:58 UTC
Google

Ever since we first saw ART appear alongside the release of Android 4.4 KitKat, we all knew that it would eventually replace the aging and relatively inefficient Dalvik runtime compiler. Well folks, the time is now upon us, as commits made late last night to the AOSP master branch show Dalvik getting the axe and ART being set as the default.

Should deliver some decent performance improvements. I tried switching to ART months ago but ran into problems with some applications not working properly. Has the situation improved? Are any of you using ART?

Thread beginning with comment 590958
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Re:
by Berend de Boer on Thu 19th Jun 2014 19:24 UTC in reply to "RE: Re:"
Berend de Boer
Member since:
2005-10-19

Automatic garbage collection does not slow things down. You need to collect garbage, which you can do:

1. Manually. Programmers can't be trusted to do that, very hard in case of cyclic references.

2. Reference counting: big overhead.

3. Automatic, best method, but requires a good gc, ideally something that has a multi-generation heap, can compact the heap, and can run concurrently without pauses.

Reply Parent Score: 1

RE[3]: Re:
by Bill Shooter of Bul on Thu 19th Jun 2014 21:20 in reply to "RE[2]: Re:"
Bill Shooter of Bul Member since:
2006-07-14

Well, it sounds like you are talking about garbage collection in the abstract.

In Objective C it was so bad, they never even made it available in ios, and are removing it from a future version.

http://en.wikipedia.org/wiki/Objective-C#Garbage_collection

Reply Parent Score: 3

RE[4]: Re:
by moondevil on Thu 19th Jun 2014 21:49 in reply to "RE[3]: Re:"
moondevil Member since:
2005-07-08

It never stops to amaze me how Apple's inability to make GC work in Objective-C keeps getting used as example why GC is bad.

Apple's GC implementation was half-baked with lots of corner cases, requiring frameworks to be explicitly compiled with GC support to work well together. When not, lots of strange bugs used to pop up.

One just needs to browse the old developer pages to see how much corner cases which required developer's attention were required. The developer forums had quite a few ongoing discussions about hard to track down crashes.

Objective-C ARC only works better than GC, because it only applies to classes that follow Cocoa retain/release patterns, so in practice the compiler is writing what the developers were already doing by hand.

But better sell failure as the new solution is better.

Reply Parent Score: 3

RE[3]: Re:
by dpJudas on Thu 19th Jun 2014 21:44 in reply to "RE[2]: Re:"
dpJudas Member since:
2009-12-10

1. Manually. Programmers can't be trusted to do that, very hard in case of cyclic references.

And yet Modern C++ (shared_ptr+weak_ptr), Modern Objective C (ARC) and Swift (also ARC) are doing that just fine.

2. Reference counting: big overhead.

Depends. In most situations the overhead does not matter. On the other hand the overhead is constant, predictable and works for resource management as well.

3. Automatic, best method, but requires a good gc, ideally something that has a multi-generation heap, can compact the heap, and can run concurrently without pauses.

GC vs ARC have each their pros and cons. The big problem with the GC approach is that while memory is usually plentyful, other resources are not and the GC is incompatible with one of the easiest resource management tools: destructors. For example, for every place a C++ project uses scope and destructors, most GC based languages requires some kind of try/finally clause to ensure you do not get memory gathering or resource exhaustion issues.

And quite frankely most developers have just as hard a time remembering to type try/finally as they had remembering to type delete in the infamous 1990's C and C++ days.

Reply Parent Score: 2

RE[4]: Re:
by moondevil on Thu 19th Jun 2014 21:53 in reply to "RE[3]: Re:"
moondevil Member since:
2005-07-08

"1. Manually. Programmers can't be trusted to do that, very hard in case of cyclic references.

And yet Modern C++ (shared_ptr+weak_ptr), Modern Objective C (ARC) and Swift (also ARC) are doing that just fine.
" [/q]


Modern C++ RC is slower than incremental generational GC, specially if pointers are shared across threads.

Modern Objective C can only be used with classes that follow Cocoa retain/release patterns. Every thing else requires manual memory management.

Swift ARC still leaves lot of room to improvement according to the benchmarks being made available.

Reply Parent Score: 2

RE[4]: Re:
by emmbee on Thu 19th Jun 2014 22:31 in reply to "RE[3]: Re:"
emmbee Member since:
2014-06-19

The big problem with the GC approach is that while memory is usually plentyful, other resources are not and the GC is incompatible with one of the easiest resource management tools: destructors. For example, for every place a C++ project uses scope and destructors, most GC based languages requires some kind of try/finally clause to ensure you do not get memory gathering or resource exhaustion issues.


Well, you're right of course, but at the same time, destructors are not the easiest way to do resource management in C++. They're the only way. More specifically, the only code that's guaranteed to be executed in C++ is the destructors of stack allocated objects, therefore the only place to put resource deallocation is destructors. I'm not saying it's wrong, mind, just... let's not confuse virtue with necessity.

Reply Parent Score: 2