I never understood why BOINC is not written in Java or at least a Java version is offered.

In our office we noticed a speed increase of 10% - 30% for our server applications (HotSpot VM) compared to the former 1.5.0_09 version on Windows 2000.

Today I downloaded the new Java 1.6 JDK (for my 64 Bit Ubuntu Linux) and my Fractal programm runs _twice as fast_ as with the former 1.5.0_08 version!!!

BOINC projects/tasks have a similar structure as my fractal programm: they are pure number crunching algorithms. A Java version would instantly benefit from the new Java Version without any programm update. I guess, with the new Java 1.6, a Java version would also be faster than any statically compiled native code (as the Java HotSpot VM compiles highly optimized native code during runtime).

You also wouldn't have to offer specific versions for all the different operating systems and specific 64 Bit versions - just one single Java version that also performs automatically better on a 64 Bit Java VM. Or with a new Java virtual machine, as now seen with Java 1.6!

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

BOINC doesn't do ANY science crunching. That is done by the science application on each project, and these are written in whatever language is appropiate for their purpose.

Climateprediction models for instance are in Fortran, because the project uses the UK Met Office's supercomputer programs, all written over many decades in Fortran.

BOINC doesn't do ANY science crunching. That is done by the science application on each project, and these are written in whatever language is appropiate for their purpose.

Climateprediction models for instance are in Fortran, because the project uses the UK Met Office's supercomputer programs, all written over many decades in Fortran.

I know that BOINC itself doesn't crunch but the specific projects. But they have to be in a specific format as they must somehow be executed! You obviously can't write a project for BOINC in Java because BOINC doesn't run in a Java VM. So the projects need to be compiled first into machine code, right?

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

The main reason BOINC does not use Java is because Java is too slow. However I tend to think that, even though it is much slower, having a Java version would be a good idea. It would allow projects to support practically any platform by making a Java version.

---

BOINC WIKI

BOINCing since 2002/12/8

Java is not "too slow" as you would see if you would search google for _current_ comparisons. And how could you tell that Java is "much slower"? You didn't code Java versions of the BOINC projects, did you? Java was slow compared to other languages (i.e. compiled static code from C, C++, etc.) in the early years. Since then, many people just kept this "fact" and think that Java was slow and still is slow. But fact is, that the current Java 1.6 HotSpot JVM is very fast and often _much_ faster than compared statically compiled C/C++ binaries. Of course, you can find benchmarks that show that C/C++ is faster ... as you can find benchmarks telling the opposite. This just shows that it depends on the case. But it also shows that Java is not slower or "much slower" in general. (In our company, we reimplemented several VB and C application in Java resulting in performance increases of several 100% ... no joke! Java 1.6 shows an average performance increase of 25% just be replacing the Java 1.5 JVM with the Java 1.6 JVM.)

I wrote fractal generators since Commodore 64 times on several architectures, operating systems and languages (Basic, Pascal, Oberon, C, Java) and the current Java HotSpot VMs are not slower than compiled C code - not at all.

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

Gosh... another C64 fan. Who'd have thought it they still exist. I just played Digital Memories pt. 1 gray on my DVD player. ;-)

I see from your Seti profile that you are a Java developer. Since both BOINC and Seti are Open Source and both are thriving on volunteers to help them out, you could try for a port over. Or not?

---

@Ageless: yes, but this is a very time consuming project. Right now, I'm working in my rare spare time (I have 2 kids ...) on my own multithreaded fractal generator. This already takes up too much time, but I love it. Porting requires a lot of time just to understand the original code and the other source code languages.

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

since developers of science application have a tough task in advancing the science itself, actually some of them cannot spare both time and man-power in just porting source into java. Some of them like Charmm have been written for a long time before. I doubt devs will port a science application, which doesn't ensure to accelerate the computation. I'm not sure, but whether Java accelerate calculation or not depends on the characteristics of the computation. If they would have time to do such a thing they definately spend the time in improving the application itself. Make sure they're not corporations or well (even without) funded, too.

If you're good at writing / porting Java and do it by yourself, the work must be welcomed, though no science application written in Java is available. boinc is opensource, so anyone can work on it.

suguruhirahara

---

I can't imagine that Java will be within an order of magnitude of speed of Fortran when running heavy duty numerical applications.

---

I've been looking for HPC benchmark comparisons between Java and Fortran, but haven't found any more recent than 2005 yet (that article initially had a 4x performance penalty for Java versus Fortran, but then got it down to 2x after reworking the Java app).

---

2005 is "ages" in computer science - you should know. The latest Java 1.6 improved significantly over the former 1.5. I would love to re-write SETI@home in Java if it would work within the BOINC client - at least the pure number crunching part. My Java fractal generator is already as fast as most other fractal generators - with dump brute force calculation. I'm just starting to dive into optimizations. With plain technical optimizations, a lot can already be done. Other logic optimizations are dependend on the fractal and/or the image (type).

Concerning benchmarks: they only tell the half truth. You will get a false interpretation if you just rely on Benchmarks (no matter if the benchmarks shows that Java is slower or faster). But of course they can help to get an idea - if you consider lots of benchmarks from lots of different authors/coders.

Here's news about Java 1.6 performance increase compared to other/former JVMs: http://blogs.sun.com/dagastine/entry/java_6_leads_out_of

I can acknowledge this as our company server applications benefit heavily from this improvement (5 - 30% increase!). And as I've already mentioned: my fractal generator runs twice as fast for deeper zoomings.

So, you also have to consider what version of Java those Benchmarks use. Java 1.6 is considerably faster!

---

BOINC 7.2.42 (x86_64) on Linux Ubuntu 16.04 (64 Bit), AMD APU 7850K 3.7 GHz, 32 GB RAM.

Hello,

I actually would like use Java on BOINC. Is there anyone else working on this.
I'm starting to look at how to set it up. You can may be help me for optimization when I've got it started.
By the way, do you know about COLT, the Java Open Source Library for High Performance Scientific and Technical Computing.

Ranaivo

2005 is "ages" in computer science - you should know. The latest Java 1.6 improved significantly over the former 1.5. I would love to re-write SETI@home in Java if it would work within the BOINC client - at least the pure number crunching part. My Java fractal generator is already as fast as most other fractal generators - with dump brute force calculation. I'm just starting to dive into optimizations. With plain technical optimizations, a lot can already be done. Other logic optimizations are dependend on the fractal and/or the image (type).

Concerning benchmarks: they only tell the half truth. You will get a false interpretation if you just rely on Benchmarks (no matter if the benchmarks shows that Java is slower or faster). But of course they can help to get an idea - if you consider lots of benchmarks from lots of different authors/coders.

Here's news about Java 1.6 performance increase compared to other/former JVMs: http://blogs.sun.com/dagastine/entry/java_6_leads_out_of

I can acknowledge this as our company server applications benefit heavily from this improvement (5 - 30% increase!). And as I've already mentioned: my fractal generator runs twice as fast for deeper zoomings.

So, you also have to consider what version of Java those Benchmarks use. Java 1.6 is considerably faster!

I dont know, what Java HotSpot VM is, buth if it is not hardware, it cant run faster than C/C++. Java is running on java VM, and imho java VM doesnt consume nothing from CPU... some equation:

instructionC - number of instruction for computation, if the language is C
instructionJ - number of instruction for computation, if the language is Java
instructionJVM - number of instruction which consumes java VM to run java computation

if you say, that java is eqivalent to c program:

instructionC = instructionJ + instructionJVM

but java MUST do same mathematical operations as C. (if not, what you are computing?) So instructionC = instructionJ.

IMHO => instructionJVM = 0. Oki. Ill code some Java VM with 0 instructions...

So imho the momentaly codes should be optimalised, or rewriten to hardware, on which it is running. (if java cpu, than to java.)

On my pc (x86) Ill stay on native solutions.

PS: Iam programming my bachelor work on java, and its fine and fast. Buth for scientific computation on x86 I dont belive, that could be faster with same results.

PPS: also the little change and bad results: http://boinc.berkeley.edu/dev/forum_thread.php?id=1717&nowrap=true#9581

Hi,

in my opinion it might not make sense for some projects to port their science applications to Java because of the use of highly optimized compilers. However, what I quite don't understand is why the core client is not developed in Java.

It should be so much easier to develop all of the scheduling mechanisms and GUI elements using Java and then adding an abstraction layer for the specific OS in order to enable IPC to the particular process instances of the science apps.

Maybe someone could shed some light on this one... ;)

Well, simple reasons I can guess are: The devs don't know Java, and/or in the attempts to make as many users as possible run BOINC, they don't want to require a Java VM. In any case, it's already done in C++, so unless there are good reasons to "start over", they surely won't.

I actually thought of rewriting the core client in Java. Main stumbling block I noticed so far is how to create a shared memory block that is compatible with science apps... I guess JNI is the only way.

---

Hi, disregarding all the pros and cons, we have implemented BOINC in Java. :)
You can find the source in http://sourceforge.net/projects/boincoid.

It was originally written for Google's Android contest - more details in http://boincoid.sf.net.

Cheers,
Oded.