[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Orekit Developers] SOCIS 2011 and Android
Le 25/07/2011 15:22, Alexis ROBERT a écrit :
> Hi,
Hello Alexis,
>
> I know this is basically a copy-paste of the form I've submitted on
> the SOCIS website, but on the SOCIS website we can't have feedback and
> adapt the submission to your needs.
No problem to copy your application here, as it allows more people to
view it, whereas the access to the form at SOCIS site is limited to
mentors only.
>
> I'm very interested in the task "Create a space flight dynamics pocket
> calculator application for android mobile devices" as I've never
> ported an existing framework to Android, and I think it's pretty
> exciting. In fact, I've already did a little Android application but
> it was not very interesting technically speaking as it was a
> dictionary (excepting the C/JNI engine to speed up index parsing for
> low-end phones with small CPUs). I've also made a little patch on the
> Android's SMS app which has been merged by Google, but that's not very
> related to this task :)
>
> In order to test the feasibility of porting Orekit to Android, I've
> already done some testing, and I've been successfully able to build
> Dalvik bytecode from Orekit and Apache Common Math jar files, and to
> run src/tutorials/fr/cs/examples/frames/Frames1.java on my Android
> phone.
>
> # time dalvikvm -classpath test-orekit.jar Test
> time doppler (m/s)
> 2008-10-01T00:00:00.000 -2925.114
> 2008-10-01T00:10:00.000 -3069.084
> 2008-10-01T00:20:00.000 -1331.910
> 2008-10-01T00:30:00.000 1664.611
> 2008-10-01T00:40:00.000 3143.549
> 2008-10-01T00:50:00.000 2832.906
> 2008-10-01T01:00:00.000 1556.662
> 2008-10-01T01:10:00.000 -140.889
> 2008-10-01T01:20:00.000 -1860.637
> 2008-10-01T01:30:00.000 -3195.728
> 2008-10-01T01:40:00.000 -3538.053
> real 0m 55.71s
> user 0m 43.80s
> sys 0m 1.47s
> # uname -a
> Linux localhost 2.6.37.6-cyanogenmod-01505-g81b06a8 #1 PREEMPT Sat Jun
> 18 13:14:06 EDT 2011 armv7l GNU/Linux
This is a very positive result. The fact it runs without changes is
already an interesting result.
>
> This was run on a Nexus One on Android 2.3 (with JIT enabled). As this
> was not the first run, data was in cache and so the latency due to
> reading data from the sdcard should not be accounted.
>
> There is two main issues I may encounter. The first would be the
> physics part, in fact I'm just undergraduate in Physics, and I might
> not be able to fully understand some computations and I hope this will
> not be a problem. In fact if I just have some pointers on how to do
> the computation in Java it would be fine.
This is fine, mentoring implies helping the student who is not required
to already have all the needed skills as he/she is still a student.
>
> The second would be performance. In fact, phones CPU are very slow
> even if the Dalvik VM tries to reduce this bottleneck. For instance,
> Frames1.java takes 55 seconds to run on a Nexus One (1GHz ARMv7 CPU
> with 512MB of RAM) when it takes 4 seconds on a Core 2 Duo Linux
> laptop (T8100 2.10GHz with Java 1.7.0-b147 on ArchLinux). It would be
> useful to profile Orekit and identify the bottlenecks and try to
> optimize them to reduce garbage collector stress, or such other things
> which are not noticeable on a desktop computer but are highly
> noticeable on an ARM CPU.
This is an interesting idea.
>
> In fact my proposed planning would be slightly different from the one
> which is published on the wiki (the required days are *very*
> approximative) :
>
> 1. Understand the list of computation needed in the final application
> and write a little text-mode test app in J2SE (~7 days)
> 2. Draw the UI on paper (tablet+phone) and submit it to the
> mailing-list for approval (~3 days)
> 3. Make the actual Android application (~7 days)
> 4. Move the computations in a Worker thread to make the UI responsive,
> while making sure that rotation still works (this is not as easy as it
> first sounds, mixing rotation and worker threads are not an easy task
> on Android as a rotation deletes the window class and keeps the worker
> thread working, but there is ways to fix this) (~2 to 3 days)
> 5. Identifying bottlenecks and try to fix them (rest of the time)
That looks fine to me.
best regards,
Luc
>
> Thanks :)
>
> Alexis Robert
>