This does not reflect for the very important fact the work per clock has significantly increased meanwhile. I have Intel Core 2 Quad at 2.4 GHz now in my computer. Even its performance as a single core is higher than what I had with 3.6 GHz Intel Pentium 4, while the power consumption is much lower.

This is one thing I see as a good with the multicore revolution - nobody seems to be obsessed with the GHz any more, and it is the performance which is increased instead.

From what I can tell, Software Pipelines operates at a courser level, wrapping an entire application in each node, then providing an API for nodes to communicate with one another either on the same machine or across a network via web services. Does it provide a standard library of operators, or simply a contract which you must abide by to take advantage of the coordination system?

Software Pipelines is an approach for bringing concurrency to an application along with order and control of the threads - from the application layer. Most business applications can't run in a compute grid because they have these types of requirements (FIFO ordering, human interaction, splits/joins, etc.) that they can't hand over to the app server or OS. This typically gets solved with multi-threaded programming. Of course you can still write multi-threaded code to solve this, but most people don't want to.

If the next version of WinDos includes this advanced new feature then Microsoft will only be like three decades behind the state of the art.

-HJC

I agree, however, that if you want to sync threads MANUALLY, and you go beyond the standard J2EE and .NET API contracts, or you throw them aside all together, then you're in deep doo doo (technical term).

I really hope PeakStream and others don't wade into OLTP, SOA and Enterprise Service Bus "blueprints", because I think the value of your platform will diminish to near-zero. It's actually the poor sods who are forced to use straight C, Java, COBOL or C# that have a huge uphill battle on multicore -- and you will only find those developers in very specific markets solving very specific problems AWAY from OLTP, SOA, Web Apps etc...

Of course, it just so happens that DataRush crushes these non-J2EE data parallel problems http://www.pervasivedatarush.com/benchmarks

:-)

Threading Maturity Model
http://ztrek.blogspot.com/2007/02/responses-to-threading-maturity-model.html

The Personal Threading Maturity Model
http://www.knowing.net/default,month,2007-01.aspx

I will try to "de-marketing-ize" as much as possible ;) I'm not familiar with DataRush (apart from what i just got from the web site) so I can't really comment on what they have done.

The limitation in app servers with multi-core is primarily around applications with ordering requirements. If the app doesn't care about order, then the OS, app server, SMP, etc. can spawn new threads as needed and it should scale fine. But if the application logic requires ordering ('A' must happen before 'B'), then they have no way of knowing how to avoid race conditions or other problematic behavior.

This problem is not unique to java. It is a basic issue of concurrency - how to do more than one thing at a time and still ensure that order happens as required by the business logic.

Yes, it can be done with multi-threaded programming, and many apps are already set up for this. But many are not, so the question is how to get them ready for concurrency without significant rewrites.

There is another thing to consider - do you want your concurrency model embedded in your application logic? It's a bit like databases - the data model doesn't reside inside the application logic (although people used to do that way back when). Abstracting your concurrency model out of the application code can have benefits, such as being able to performance tune without modifying source code.

BTW, to answer your question, the Rogue Wave implementation is multi-language, so it supports Java, C++, .NET, BPEL. We have used it for bulk batch apps and for transactional.

When to use which?

Let's cut through the marketing b.s. and talk turkey so developers will learn something in this blog. I dare ya :-)

PS: I totally do not get the comments about multicore + app servers = slight problem. I don't see the issue because the OS and SMP multicore server abstract any/all issues from the JVM that spins up concurrent threads. There are 1000 "contracts" all the way up and down the stack that would prevent surprises. So I am most definitely missing the point here. Can we talk a couple levels deeper starting from EJB bean pooling and driving down the stack? I need to see where the issue is for J2EE-like use-cases.

PPS: I see all the issue with batch data processing apps. Not with OLTP or ESB/SOA apps. Just don't see it...

For example, any application that has to ensure ordered processing will have this issue. The JVM, OS, app server, etc. don't know the business logic of the application, so they cannot execute parallel tasks in a way that is consistent with the application's ordering requirements. In fact, they may execute the tasks in a way that is at odds with the application.