Android Boinc!

[tansaku]

Hi All,

So I managed to get the non-android seti-java/boinc-cvs running after
finding the installation instructions:

https://sourceforge.net/projects/boincoid/files/Compile%20Version/Project%20CVS/

Was pleasantly surprised that that worked, or at least I think it
worked - not really in a position to interpret the logs yet, but no
obvious errors :-)

Still got about 70 errors in the boinc android client - is that
completely independent of the non-android version perhaps?

I did find discussion in the sourceforge site of some people (Bill
Edgar, Army Andy) already fixing the pre-1.1 android issues:

https://sourceforge.net/projects/boincoid/forums/forum/812689/topic/3042530
https://sourceforge.net/projects/boincoid/forums/forum/812689/topic/3359959

but it seems like these fixes have not been propagated into the CVS,
so I've emailed the individual users involved to ask if there is a
currently working android version somewhere ...

CHEERS> SAM

[Eric J Korpela]

I believe I had similar problems the last time I tried to compile BOINCoid, which I believe as using the Android 2.1 SDK.  Not having time to deal with it, or learn the API difference, I just moved on to other things. 

[Eric J Korpela]

FYI, in my spare time I'll be slowly porting things in boinc/lib to
java as a way to reintroduce myself to java. Don't let anyone who
thinks I should be doing something else know.

So far I've done base64.java . I'm trying to make the API as
consistent with the C++ version as I can, so I in some cases I'll end
up reimplementing some things that are already found in standard java
APIs to match libboinc idiosyncrasies. Or, in the case of base64, it
exists in the android api, but isn't a standard part of the java API.

Anyway, once I've implemented them, Android ports should be reasonably
easy. For an android port of base64.java, replace all the code with
calls to android.util.Base64 with appropriate compatibility flags.
It's too bad that there's not a preprocessor in java, or it could be
done with #ifdefs. Is there a standard java way of doing such things
efficiently?

Haven't decided when I'll be checking these things in to the BOINC svn
repository.

[Samuel Joseph]

Hi Eric,

Good to know.

Given what I've learnt so far, I think I need to pause for reflection.
I'm hoping I can get some of my students involved in this in September.

I feel that I need to know more about the details of Seti@home - more
work required on my part.

If the Seti@home client is basically specified in C++ and that is what
is being maintained, then it sounds like maitaining a Java version to
keep pace with that is always going to be an overhead. Of course if
that's something you can manage, then an Android port of the Java code
you maintain would be a much more realistic proposition.

I guess there is ongoing overhead of porting the the base C++ component
to different platforms, but I am slightly surprised that there would be
so many changes. My impression was that the basic algorithm was a
series of fast fourier transforms that were relatively fixed, and there
was just a huge amount of data that needs transforming ...

It makes me wonder if a better approach would be some sort of C++
executable for Android built using the NDK, or some higher level
specification of the algorithms that need to be run, e.g. in some sort
of algorithm scripting language, which might then be run by a Android
Java client ....

I'm planning a couple of lectures on Seti@home in my fall internet
programming course ...

http://www.techhui.com/events/csci-3632-internet-programming

I'll probably come back to you next month when I'm setting that up ...

Regarding ifdefs and Java I think this stackoverflow post explains the
standard approach:

http://stackoverflow.com/questions/1813853/ifdef-ifndef-in-java

HTH

CHEERS> SAM

p.s. open source open source open source :-)

--
Sam's Technical Blog
http://linklens.blogspot.com

[Eric J Korpela]

On Fri, Aug 12, 2011 at 3:12 AM, Samuel Joseph <tan...@gmail.com> wrote:

> I feel that I need to know more about the details of Seti@home - more work
> required on my part.
>
> If the Seti@home client is basically specified in C++ and that is what is
> being maintained, then it sounds like maitaining a Java version to keep pace
> with that is always going to be an overhead.

Yes, I've thought about how to make it happen in a somewhat automated
way, but I haven't come up with anything that would be effective. The
best I've been able to come up with is just to have dependencies in
the Makefiles so that the .java files depend on the .cpp files. The
make action would just be to print a message and exit, since updating
would be a manual process.

> Of course if that's something
> you can manage, then an Android port of the Java code you maintain would be
> a much more realistic proposition.

The hard part of an Android port, I think, would be maintaining any
native functions that are required.

>
> I guess there is ongoing overhead of porting the the base C++ component to
> different platforms, but I  am slightly surprised that there would be so
> many changes.  My impression was that the basic algorithm was a series of
> fast fourier transforms that were relatively fixed, and there was just a
> huge amount of data that needs transforming ...

The basic functions are pretty well defined. You need an transpose, a
complex FFT, a real FFT, a fast folding algorithm (FFA), a chirping
function, and a few others. The big problem is that the optimum way
to perform those functions isn't even consistent to different
revisions of the same processor family. If you look at the output of
SETI@home with the -verbose flag set you'll see that it tests a large
number of possible functions before it picks which one it wants to
use.

First, I would just pick basic algorithms for each and make a working
(but slow) SETI@home that uses the default functions. Then you can
think about how you want to implement optimized versions. JNI? I
assume the per call overhead is large, so that may mean you have to
move the Java-Native boundary to a higher level. It's probably worth
it because being able to use NEON SIMD when available and other
instruction set level optimizations can really boost performance.

> It makes me wonder if a better approach would be some sort of C++ executable
> for Android built using the NDK, or some higher level specification of the
> algorithms that need to be run, e.g. in some sort of algorithm scripting
> language, which might then be run by a Android Java client ....

That's a thought. The disadvantage is when we get to non-ARM
architectures we'd still like a application that works.

>
> I'm planning a couple of lectures on Seti@home in my fall internet
> programming course ...
>
> http://www.techhui.com/events/csci-3632-internet-programming
>
> I'll probably come back to you next month when I'm setting that up ...
>
> Regarding ifdefs and Java I think this stackoverflow post explains the
> standard approach:
>
> http://stackoverflow.com/questions/1813853/ifdef-ifndef-in-java
>

Thanks, that's very helpful. I'll have to see if this works with
non-existent APIs. Anyhow, I think I'll check in what I've done so
far sometime in the next week.

[Eric J Korpela]

An additional think to about with SETI@home is that the classes
relating to the science database schema_master.{cpp,h} (which are also
used in the application, with the DB code #ifdefed out) are generated
by an awk script that uses the database schema (schema_master.sql) as
input. Yes, I am insane, why do you ask? Doesn't everyone write
their compilers in awk?

It should be possible to modify the script to output java files.
Doing so may make your head explode.