We're aware of the shortcomings of the current garbage collector and believe me, it's one of the things we'd really love to see improved as soon as possible :)
On Fri, Apr 3, 2009 at 2:04 AM, Mariano Kamp <mariano.k...@gmail.com> wrote: > Anton, thanks. Very interesting. > On Fri, Apr 3, 2009 at 2:24 AM, Anton <socialhac...@gmail.com> wrote: >> >> Check out >> http://android-developers.blogspot.com/2009/02/track-memory-allocations.html >> >> Romain Guy points out in this post that the android garbage >> collector cannot optimize small short lived objects. These are >> exactly the sort of objects that could be created in a physics engine >> when it needs to generate dynamic collision constraints. A good >> solution in this case is to use a pool of constraint objects because >> they are all going to be the same size/object. The best solution in >> my mind would be for the compiler to do escape analysis on the objects >> and stack allocate them when it sees that they will never escape the >> function. I have been told that the Java byte code can't reference an >> object on the stack. It's possible that the Dalvik byte code can, I >> don't know. >> >> I don't have a reference for this, but I assume that Dalvik's >> inability to optimize small short lived object comes from the fact >> that it uses a mark and sweep GC. On all of my profiling, I see the >> GC take at least 100ms to run. For a game that means you miss from >> three to 10 frames of animation and it makes for a pretty noticeable >> hick up. And I don't think it's my application that is causing the >> garbage collector to fire. Unless the OpenGL ES calls do some memory >> allocation, which is entirely possible. I realize that any background >> task could move to the run queue and take some time away from my >> engine, it just happens to be the garbage collector most of the >> time. :) >> >> So the result is that the Garbage collector is problematic for me >> in two ways. First, it's not optimized to deal with the sort of small >> objects that tend to make for good encapsulations of mathematical >> types (like Fixed point number classes or Vector or Matrix classes). >> And secondly it takes a long time to run when it does garbage collect, >> resulting in dropped frames. >> >> -Anton >> >> On Apr 2, 3:32 pm, Mariano Kamp <mariano.k...@gmail.com> wrote: >> > It's maybe a bit off topic, but how do you know that Android's gc is >> > rudimentary? Have you got a link handy? >> > I only found >> > this:http://developer.android.com/guide/practices/design/performance.html >> > >> > On Thu, Apr 2, 2009 at 11:59 PM, Anton <socialhac...@gmail.com> wrote: >> > >> > > Shaun, thanks for checking it out. Yah, I agree that the real >> > > complexity of a physics engine comes from joints and contact >> > > constraints. The constraints in my demo are simple minimum distance >> > > constraints. I have a 2D rigid body physics engine that I'm thinking >> > > more and more about porting over to Android as well. This demo was >> > > more of a calibration for myself to see how much computation I can do, >> > > and what optimizations lead to the largest improvements. I'll >> > > probably turn it into a fun toy for the Market and then look into >> > > rewriting my rigid body engine for Android. >> > >> > > Reading through Simpull I noticed that you allocate a new Vector3f >> > > in your Verlet update routine. I think that will be a killer on the >> > > Android platform because of it's rudimentary garbage collector and >> > > limited RAM. My solution was to allocate an array of fixed point >> > > numbers, four per ball. Effectively a vector pool that didn't require >> > > any management because the number of balls never changed. >> > >> > > On Apr 2, 6:31 am, shaun <shashepp...@gmail.com> wrote: >> > > > I took a look at Anton's demo on a G1 device, and I was glad to see >> > > > the integration of accelerometer as it really added value. I assume >> > > > the calculations for collision detection and response are fairly >> > > > basic, which allows for that performance. >> > >> > > > Simpull will also provide good performance for a scene of that >> > > > nature >> > > > (all verlet, no joints). At least I believe it will. The point >> > > > where >> > > > simpull becomes slow is when a more complex scene is in play with >> > > > 10s >> > > > of objects with many joints connecting some of them. Since the >> > > > engine >> > > > is all verlet and no rigid body dynamics, joints are one way to >> > > > acheive a similar result, but with a very bad performance hit due to >> > > > all the new temporary objects and new calculations. >> > >> > > > I would be super impressed to see a demo like Anton's with rigid >> > > > body >> > > > dynamics involved with at least some rectangles, if not other >> > > > polygons >> > > > and perhaps a joint or two. That is where the performance degrades >> > > > quickly in my experience. >> > >> > > > On Apr 1, 2:45 pm, mscwd01 <mscw...@gmail.com> wrote: >> > >> > > > > Thanks Lajos for pointing APE out, I hadn't heard of it until now. >> > >> > > > > Unfortunately your link to your Android port is broken, can you >> > > > > mend >> > > > > it as I dont fancy spending another hour porting another library >> > > > > to >> > > > > Android :D >> > >> > > > > Thanks >> > >> > > > > On Mar 31, 9:50 pm, lkelemen <tridc...@gmail.com> wrote: >> > >> > > > > > Hello everyone, >> > >> > > > > > I was also disappointed with jbox2d's performance so I checked >> > > > > > APE >> > > > > > (Actionscript Physics Engine) fromhttp://www.cove.org/ape/. >> > > > > > It was converted to java (http://www.cove.org/ape/java_ape.zip) >> > > > > > so I >> > > > > > started to convert the java version to Android. >> > >> > > > > > The performance is quite OK for 10-20 objects at the first start >> > > > > > of >> > > > > > the app but if you exit with the back key and restart it form >> > > > > > the >> > > > > > installed copy >> > > > > > (either in the emulator or on the dev phone) then it gets slower >> > > > > > and >> > > > > > slower with each start. If you restart it from the emulator (by >> > > > > > reinstalling it) then it is faster again. >> > > > > > Neither the pressed keys are not working (probably it is because >> > > > > > of >> > > my >> > > > > > poor Android programming knowledge). >> > >> > > > > > Here is a zipped Android project of it. Please experiment with >> > > > > > it and >> > > > > > send results to here i.e. is it slow for you also after >> > > > > > re-re-re-.. >> > > > > > staring?www.kotiposti.net/lkelemen/android/testape2d.zip >> > >> > > > > > thanks >> > > > > > Lajos Kelemen >> > >> > > > > > On Mar 31, 9:26 pm, shaun <shashepp...@gmail.com> wrote: >> > >> > > > > > > I started going down the path of Object pooling. It seemed >> > > > > > > the >> > > only >> > > > > > > solution when taking an existing engine and making work on a >> > > resource >> > > > > > > constrained system like Android on a phone. Determining the >> > > strategy >> > > > > > > for returning objects to the pool proved quite tough for me. >> > > > > > > I >> > > have >> > > > > > > no doubt there are some experts on embedded systems >> > > > > > > programming >> > > with >> > > > > > > tons of experience with object pooling. We just would be too >> > > > > > > lucky >> > > if >> > > > > > > that person(s) was also experienced with Java, physics engines >> > > > > > > and >> > > had >> > > > > > > a passion for open source and games! Is that too much to ask? >> > > LOL!! >> > >> > > > > > > On Mar 31, 12:17 pm, mscwd01 <mscw...@gmail.com> wrote: >> > >> > > > > > > > Thanks for your feedback Shaun, I too unfortunately think a >> > > bespoke >> > > > > > > > engine will need to be written for Android, which is a real >> > > > > > > > pity >> > > as >> > > > > > > > the iPhone has several physics engines which can easily >> > > > > > > > handle >> > > > > > > > hundreds of objects. >> > >> > > > > > > > Having said that Anton (2nd reply) has said he has an engine >> > > running, >> > > > > > > > it would be nice to see a demo of this if that'd be >> > > > > > > > possible? >> > >> > > > > > > > Clark, i'd definately host any .apk's on my own site, I >> > > > > > > > wouldn't >> > > put >> > > > > > > > it on the marketplace if it wasn't a "finished" app - do >> > > > > > > > people >> > > > > > > > actually do that?! >> > >> > > > > > > > I think i'll stay away from developing games with physics >> > > > > > > > for the >> > > time >> > > > > > > > being and concentrate on something else, I cant see it being >> > > feasible >> > > > > > > > to include it any time soon which is a real pity. >> > >> > > > > > > > On Mar 31, 3:28 pm, shaun <shashepp...@gmail.com> wrote: >> > >> > > > > > > > > I am the author ofsimpull. >> > >> > > > > > > > > Sorry guys for the demo being out of whack forSimpullto >> > > > > > > > > the >> > > Core. >> > > > > > > > > The version of PulpCore that I integratedsimpullwith did >> > > > > > > > > not >> > > support >> > > > > > > > > Chrome, but you should be able to see it in IE, FF Safari. >> > > > > > > > > It >> > > is nice >> > > > > > > > > to take a look at that demo to get a feel for what the >> > > > > > > > > engine >> > > is >> > > > > > > > > capable of, but the performance does not translate over to >> > > > > > > > > the >> > > fixed >> > > > > > > > > point branch/version ofsimpullwhen running on Android. >> > >> > > > > > > > > I ran tests on both the emulator and the actual device and >> > > there was a >> > > > > > > > > significant increase in performance because of the fixed >> > > > > > > > > point >> > > > > > > > > implementation, but I got very frustrated that it still >> > > > > > > > > did not >> > > > > > > > > support the amount of objects in a scene that I considered >> > > > > > > > > good >> > > for a >> > > > > > > > > physics-based game. It seemed to handle ~10 objects >> > > > > > > > > moving and >> > > > > > > > > colliding OK. It has been a while since I was playing >> > > > > > > > > with it, >> > > so I >> > > > > > > > > do not really remember the exact number of objects or the >> > > > > > > > > frame >> > > rate. >> > > > > > > > > I mostly remember being upset with it. >> > >> > > > > > > > > I am leaving the physics ideas for games out of the >> > > > > > > > > picture >> > > when >> > > > > > > > > thinking Android for now. Someone would have to write a >> > > > > > > > > ground >> > > up >> > > > > > > > > engine with all the performance and memory concerns of >> > > > > > > > > Android >> > > in >> > > > > > > > > mind, which was not the case withSimpull.....I created it >> > > > > > > > > for >> > > > > > > > > applets, then thought to port over to fixed-point for >> > > > > > > > > Android. >> > > It >> > > > > > > > > works well with small scenes, but certainly not the staple >> > > engine to >> > > > > > > > > use in my opinion. >> > >> > > > > > > > > Also, Phys2D will not run worth a damn on Android. I >> > > > > > > > > tried it >> > > and I >> > > > > > > > > even went through some heavy performance tuning. Garbage >> > > collection >> > > > > > > > > is the major issue even after all I did. I seriously >> > > > > > > > > doubt >> > > JBox2D >> > > > > > > > > will run well either. I'll stick to what I said earlier, >> > > > > > > > > a >> > > ground-up >> > > > > > > > > solution by someone smarter than me is probably required. >> > >> > > > > > > > > On Mar 31, 9:49 am, "admin.androidsl...@googlemail.com" >> > >> > > > > > > > > <admin.androidsl...@googlemail.com> wrote: >> > > > > > > > > > Not tried but if you can provide us with some example >> > > > > > > > > > source >> > > code or >> > > > > > > > > > put something on the market, I'm sure we could take a >> > > > > > > > > > look. >> > >> > > > > > > > > > G1 performance is significantly faster than emulator, >> > > > > > > > > > but >> > > there are >> > > > > > > > > > limitations. >> > >> > > > > > > > > > Particularly with garbage collection and memory >> > > > > > > > > > allocation on >> > > code >> > > > > > > > > > that gets run continuously in loops, so I don't know how >> > > optimised >> > > > > > > > > > these physics engines are for this purpose. >> > >> > > > > > > > > > Would be interesting to find out though. >> > >> > > > > > > > > > On Mar 31, 12:52 pm, mscwd01 <mscw...@gmail.com> wrote: >> > >> > > > > > > > > > > Oh I forgot to re-ask... >> > >> > > > > > > > > > > "Has anyone tested Phys2D or JBox2D on an actual >> > > > > > > > > > > device to >> > > see if they >> > > > > > > > > > > run better than on the emulator? >> > >> > > > > > > > > > > I have a feeling the performance will better on a G1 >> > > > > > > > > > > than >> > > the emulator >> > > > > > > > > > > for some reason! >> > >> > > > > > > > > > > On Mar 31, 12:51 pm, mscwd01 <mscw...@gmail.com> >> > > > > > > > > > > wrote: >> > >> > > > > > > > > > > > I did take a look atSimpull, however the demo >> > > > > > > > > > > > application >> > > failed to >> > > > > > > > > > > > run as it relied on some library which wasn't >> > > > > > > > > > > > supplied or >> > > referenced >> > > > > > > > > > > > to - I just got annoyed after spending two days >> > > > > > > > > > > > failing >> > > to get Phys2D >> > > > > > > > > > > > and JBox2D to work in Android and didn't bother >> > > > > > > > > > > > trying to >> > > work out the >> > > > > > > > > > > > problems! >> > >> > > > > > > > > > > > I might give it another look though... >> > >> > > > > > > > > > > > On Mar 30, 10:41 pm, Streets Of Boston < >> > > flyingdutc...@gmail.com> >> > > > > > > > > > > > wrote: >> > >> > > > > > > > > > > > > I wonder how well this one works on Android: >> > >> > > > > > > > > > > > > http://code.google.com/p/simpull/ >> > >> > > > > > > > > > > > > -- Anton Spaans >> > >> > > > > > > > > > > > > On Mar 30, 4:58 pm, Anton <socialhac...@gmail.com> >> > > wrote: >> > >> > > > > > > > > > > > > > I have a simple 2D physics >> > >> > ... >> > >> > read more » >> > > > > > -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
