Now that the first half of the first contest is behind us, and we did not win, we have published our Java/Android source code.
Before modifying the code, or even reading it, we recommend you fully read this post. It portrays the current state of the code, which is not very complete, so a quick introduction will save you some headache later on.
Please understand that the entire work was made by 2 students who juggled between studies, work, social life and deadlines, so your patience is required. Having said that, we believe this code is a great starting point for many great things to come.
The current state of the code follows:
BOINC -
There are 2 distributions of the translated BOINC code. One for Java and one for Android.
1. Java distribution - This is the original translation of code from C++ to Java. It was done quite robotically (by human beings), and in a mass form. Entire classes or files were taken and translated without regarding other dependencies. The belief was that the translation of the entire code, while keeping the same conventions through out the translation, will result in a more-or-less working version.
Nearing the deadline, while still not close to code complete, we switched our mode of operation and started bringing the code to a stage it compiles. This meant commenting out large pieces of code that were less important for us, or that have yet to be translated. There are also many stubs of classes we did not use eventually that are still filled with TODO's.
So currently the code is in a state it compiles and runs, but is lacking some functionality that is found in the original C++ version. There are also testing issues - these are summarized below.
Once the project passed compilation we branched out to the Android distribution and, unfortunately, continued working on both of them simultaneously.
2. Android distribution - This one is the more stable of the two, but it includes libraries from android.* and not java.*. The transition to pure Java is quite immediate, by just replacing some imports, and maybe consequently altering few lines of code. (e.g. Android.string had no isEmpty() - a minor difference).
This distribution underwent more testing than the Java one. Resulting modifications/corrections were sometimes brought back to the Java code and sometimes not. Heap of apologies for this foul handling, but this is the result of deadline pressure.
For running and testing applications in the Android environment, you can find great documentation on Google's site - http://code.google.com/android/adc.html
Also, there is stub code that lays out the file system as our project anticipates it. This was done for our submission to work out-of-the-box , and can be removed for production stages.
SETI -
Only an Android version of SETI is found, but the transition to regular Java is quite straight forward.
Example work units were processed with the original version and compared to the results of the ported version. Currently they seem to match exactly, up to the string representation of some of the numbers - maybe important for the scheduling server.
Graphics were not ported, but the Android OS supports openGL, and we definitely plan to port them. We believe the graphics view could be one of the main appeals for the mobile use. Maybe the graphics could show the last processing state, because the main processing will be done at night, while the graphics could serve as a neat screensaver through out the day, so there's need for some information to be shown.
And a work for Carmi who was done all the work on the SETI port -
"Comments: S@H (Java) is a 1-1 port of the original, save these:
(1) No SSE et al. functions
(2) There's a set of functions that choose the best chirping/fft functions for use, in runtime.
I stubbed this set - it simply chooses the non-SSE/FPU/etc. functions that I translated."
Testing -
Only the main functionality of requesting for work, receiving and processing it was basically tested. We couldn't even test the response mechanism, since the scheduling servers did not really recognize our client.
Huge parts of the code were probably not run as a result of basic testing, and supporting only limited functionality. For example, we currently support only one project on the Android client, so no logic of multiple projects was tested.
Performance -
There were many inquiries regarding the performance of the Java code, and the Android code.
Several optimizations were made on the SETI side, but no proper benchmarking has taken place yet. Memory seems to be a critical issue for the mobile devices, but how limiting it might be still remains to be seen.
We encourage you to benchmark the C++ vs. Java performance, as this is an old dispute, and is intriguing in the BOINC context. Also, if you have access to testing platforms, it would be wonderful to receive some real performance numbers (the Android emulator is _incredibly_ slow).
Conventions and Design Guidelines -
Initially we set strict conventions appropriate for Java: Don't have public properties (only getters/setters), change my_variable_name to myVariableName, etc.
This proved extremely difficult for the translation process. Despite the obvious added work, we kept to the conventions up to a point it was obvious we needed to seriously speed things up. So you can find both c-style and java-style coding conventions in the code. Our hope is that the conventions will be kept, and updated for those parts of code that were hastily written.
That's it for the introduction. Later posts will summarize the new Java oriented design of the code, and comment on whatever issues we forgot to mention.
Hope you find this code to your liking :)
Carmi & Oded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A small correction -
a Java package for SETI@Home does exist; it should run out of the box in Standalone mode, if you provide it with a workunit file in the same directory.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Now that the first half of the first contest is behind us, and we did not win, we have published our Java/Android source code.
Before modifying the code, or even reading it, we recommend you fully read this post. It portrays the current state of the code, which is not very complete, so a quick introduction will save you some headache later on.
Please understand that the entire work was made by 2 students who juggled between studies, work, social life and deadlines, so your patience is required. Having said that, we believe this code is a great starting point for many great things to come.
The current state of the code follows:
BOINC -
There are 2 distributions of the translated BOINC code. One for Java and one for Android.
1. Java distribution - This is the original translation of code from C++ to Java. It was done quite robotically (by human beings), and in a mass form. Entire classes or files were taken and translated without regarding other dependencies. The belief was that the translation of the entire code, while keeping the same conventions through out the translation, will result in a more-or-less working version.
Nearing the deadline, while still not close to code complete, we switched our mode of operation and started bringing the code to a stage it compiles. This meant commenting out large pieces of code that were less important for us, or that have yet to be translated. There are also many stubs of classes we did not use eventually that are still filled with TODO's.
So currently the code is in a state it compiles and runs, but is lacking some functionality that is found in the original C++ version. There are also testing issues - these are summarized below.
Once the project passed compilation we branched out to the Android distribution and, unfortunately, continued working on both of them simultaneously.
2. Android distribution - This one is the more stable of the two, but it includes libraries from android.* and not java.*. The transition to pure Java is quite immediate, by just replacing some imports, and maybe consequently altering few lines of code. (e.g. Android.string had no isEmpty() - a minor difference).
This distribution underwent more testing than the Java one. Resulting modifications/corrections were sometimes brought back to the Java code and sometimes not. Heap of apologies for this foul handling, but this is the result of deadline pressure.
For running and testing applications in the Android environment, you can find great documentation on Google's site - http://code.google.com/android/adc.html
Also, there is stub code that lays out the file system as our project anticipates it. This was done for our submission to work out-of-the-box , and can be removed for production stages.
SETI -
Only an Android version of SETI is found, but the transition to regular Java is quite straight forward.
Example work units were processed with the original version and compared to the results of the ported version. Currently they seem to match exactly, up to the string representation of some of the numbers - maybe important for the scheduling server.
Graphics were not ported, but the Android OS supports openGL, and we definitely plan to port them. We believe the graphics view could be one of the main appeals for the mobile use. Maybe the graphics could show the last processing state, because the main processing will be done at night, while the graphics could serve as a neat screensaver through out the day, so there's need for some information to be shown.
And a work for Carmi who was done all the work on the SETI port -
"Comments: S@H (Java) is a 1-1 port of the original, save these:
(1) No SSE et al. functions
(2) There's a set of functions that choose the best chirping/fft functions for use, in runtime.
I stubbed this set - it simply chooses the non-SSE/FPU/etc. functions that I translated."
Testing -
Only the main functionality of requesting for work, receiving and processing it was basically tested. We couldn't even test the response mechanism, since the scheduling servers did not really recognize our client.
Huge parts of the code were probably not run as a result of basic testing, and supporting only limited functionality. For example, we currently support only one project on the Android client, so no logic of multiple projects was tested.
Performance -
There were many inquiries regarding the performance of the Java code, and the Android code.
Several optimizations were made on the SETI side, but no proper benchmarking has taken place yet. Memory seems to be a critical issue for the mobile devices, but how limiting it might be still remains to be seen.
We encourage you to benchmark the C++ vs. Java performance, as this is an old dispute, and is intriguing in the BOINC context. Also, if you have access to testing platforms, it would be wonderful to receive some real performance numbers (the Android emulator is _incredibly_ slow).
Conventions and Design Guidelines -
Initially we set strict conventions appropriate for Java: Don't have public properties (only getters/setters), change my_variable_name to myVariableName, etc.
This proved extremely difficult for the translation process. Despite the obvious added work, we kept to the conventions up to a point it was obvious we needed to seriously speed things up. So you can find both c-style and java-style coding conventions in the code. Our hope is that the conventions will be kept, and updated for those parts of code that were hastily written.
That's it for the introduction. Later posts will summarize the new Java oriented design of the code, and comment on whatever issues we forgot to mention.
Hope you find this code to your liking :)
Carmi & Oded.
A small correction -
a Java package for SETI@Home does exist; it should run out of the box in Standalone mode, if you provide it with a workunit file in the same directory.