Read a recent article on Fork-Join Processing by one of our developers about the issues with multi-core development and why you need this product.

What is Fork-Join?

Think of a fork in the road where each path eventually comes back together — joins.

Fork-Join breaks an application into several parts for parallel processing and joins the results at the end.

Figure 1: Fork-Join Structure

Let’s say we have an array of one thousand numbers. We need to do a procedure on each of these numbers and add the total.

Listing 1: Array Processing



for ( int i = 0; i < 1000; i++) {

total += doProcedure(array[i]);

}

If the procedure takes one second (wall-clock time) to complete, then it is going to take one thousand seconds (over 16½ minutes) to complete this task.

Fork-Join could

separate (fork) the large array into ten arrays of one hundred elements each,

processes each array on a separate CPU, and

join the results when finished.

That would take one hundred seconds (just over 1½ minutes), one tenth of the original time. The more CPU's available, the faster the result.

This abstraction closely resembles the standard scientific model of Divide-and-Conquer.

Figure 2: Divide-and-Conquer

This is what high performance computing is all about — simultaneously processing humongous amounts of data on as many CPU’s as available. Map/Reduce, sorting, and countless array processing applications all can use Divide-and-Conquer to solve their problems.

And there's more. Lots, lots more, so keep reading.

Would you like to segregate processing into separate Java ™ Virtual Machines without the gargantuan overhead of commercial application servers?

Do you need many flavors of RMI Servers from the simple to the complex?

Would you like to run a backend queuing and threading server embedded within any application?

Is it too time-consuming to develop a custom server that can handle

Timed, Autonomous, Urgent and Multi-Component requests?