We don't know of any industry accepted benchmarks in this field. We have conducted testing internally and some of the tests showing speedup are shown on www.axon7.com at:
http://axon7.com/flx/home/jibu_in_depth/the_scheduler/
http://axon7.com/flx/home/jibu_in_depth/the_parallel_class/
We plan to conduct further tests in the near future - also comparing Jibu to the competitions.
Yes and no. Jibu’s main advantage is that it is suited for traditional applications that need to max out the machine but also for programs where event-based coordination is needed such as GUI applications, embedded systems, robotics, etc. Also, the API is kept as simple as possible to reduce the learning curve. Finally, Jibu is both cross platform and cross language.
Another key difference is that Jibu works for all major languages. So, you can use one approach in all you applications - Simpler. That is why we say Jibu is "Simply Faster"
MapReduce is aimed at clusters of many computers and not for the same shared memory applications that Jibu can be used for. The same goes for Hadoop.
The key thing missing from existing OS vendors and platforms is a uniform high-level approach that deals equally well with performance oriented multi-core programming and traditional event-based concurrent programming.
Providers of operating systems typically supply API's that enable programmers to do basic things such as I/O, basic threading etc. upon which vendors of programming languages and libraries can build more advanced products and features.
Even though most programming languages are supplied with threading libraries, and third party products exists -- some of which include functionality which overlaps with Jibu -- no other players provide as much functionality on as many programming languages and platforms.
Jibu provides a uniform approach across 4 of the most widespread languages. It contains constructs that make it simple to utilize all the processing power in a given system. It also provides constructs inspired by CSP (Communicating Sequential Processes) that make traditional concurrent programming very easy.
The initial spec JSR 166 is already embedded into Java and what is now being worked on for Java 7 is JSR166y. See the above comment. Jibu contains features not in JSR 166y and vice versa and the API is quite different. Also remember that, with Jibu, the actual concurrency code is trivial to port to .NET, C++ and
Not significantly. As Jibu is a software library that adds code on top of the code written by the programmer there will be an overhead - code takes time to execute, which is unavoidable. What is more interesting is whether code using Jibu is slower than code written from scratch by the programmer. Except in trivial cases, Jibu will be faster because all cores are exploited automatically and the load is distributed dynamically among cores ensuring maximum core utilization. Also, the number of threads run by Jibu is kept as close as possible to the number of cores in the machine executing the program in order to obtain the best concurrency level possible - eliminating the need for superfluous and time consuming context switches.
As all machines are going multi-core the gains realized when scaling a program to take advantage of all cores vastly outweighs the overhead incurred by the library itself.
Another performance measure might be how long it takes to develop, debug and maintain an application and here Jibu is clearly superior to normal thread programming because much of the low level stuff like thread handling, synchronization and load balancing is abstracted.
Thread-hot is a term used to describe an API where the programmer using that API doesn't see the threads at all but interacts only with high-level objects. All thread management is hidden and scalability issues are handled automatically inside the library. Jibu is a thread-hot API where the programmer only uses tasks instead of threads. Inside Jibu, tasks are automatically mapped to threads and executed and the number of threads is automatically adjusted to match the number of cores on which the program is executing.
Removing a lot of the complexity arising from programming multi-core computers results in reduced training and development time as well higher quality products containing fewer bugs.
At this time Open Source is being considered. Specifically we contemplate making the non-commercial edition open source, but nothing has been decided yet. Another option being considered is giving paying customers access to the Jibu source code.