"...the validity of multi threading is under attack. Veteran programmer Knuth said in a recent interview that multi threading may not be up to the task and could fail. As such, he is "unhappy" with the current trend towards multi-core architectures."

“To me, it looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks! I won’t be surprised at all if the whole multi threading idea turns out to be a flop..." Knuth said."

A very clear explanation of why writing parallel apps is a challenge with procedural languages, versus declarative approaches. Although Java is procedural, our Java implementation of dataflow is avoids this pitfall.

"The ability to assign a memory location with variable data is the cornerstone of computer programming. It turns out the ability to re-assign that same memory location is perhaps one of the biggest consternations in the parallel programming world. At the time, multiple assignment seemed like (and was) a good idea. Coupled with a looping control structure, massive calculations could be performed. For instance, one could write a program to sum the numbers from 1 to 100 (and beyond with simple variable change):"

Let SUM = 0
FOR I = 1 to 100
LET SUM = SUM + I
NEXT

"While incredibly useful, multiple assignment creates “state” within the program because the value of variables can change as program runs. The typical programming language allows you to manage the state of program variables. i.e. the memory location that holds the variable SUM changes over time. As any programmer will tell you, program state is easily managed on a single Von Neuwman CPU through the plethora of programming languages. (Some may argue this point, however.) On a large number of CPUs, managing coupled program states becomes extremely difficult. In a parallel environment, it is up to the programmer to manage the state of I and SUM. In a sequential single CPU environment, the programmer can assume I = 100 after the loop completes. In a parallel environment, where the loop may have been broken into parts, I may equal 10 on one CPU, and 20 on another. Of course, the example is simple and obvious. Creating large complex parallel applications does not present such luxuries, however."

"The simple powerful idea of multiple assignment has come back to bite us in the asymptote."

"Again and again, executives said that finding enough programmers who are able to write "parallel" code -- programs that efficiently divide workloads across distributed processors -- is almost impossible. As Wall Street firms rely on multicore processing and even distributed computing to handle the ever-growing number of trade-related messages that are sensitive to any increase in data latency, the divergence between the capabilities of the technology and the capabilities of the programmers is becoming painfully evident.",

This article is a simple illustrative introduction to Amdahl's Law.

"Indeed, just as with parallel processors, there is a point of diminishing return. Adding the first 10 riding mowers reduced the time by 36 minutes. Adding another 30 only saved me 4 minutes. Adding 100 mowers makes little sense since I’ll never get below 20 minutes. (Although I would love to see such a lawn mowing demolition derby — in my neighbors yard of course.)"

I didn't know there was an Itanium Solutions Alliance, but this article includes the road map for Intel's continued commitment to Itanium, notably, going to a single-die quadcore.

I noticed a display for the Itanium JVM in the Intel booth at JavaOne, and it is also mentioned in the article, but it doesn't specify the OS. We are looking forward to testing on it as soon as we can.

As you can see here, we achieved great results in our scalability tests on the 32-core HP Integrity server running the HP-UX JVM, developed by HP.

These unit growth numbers are very impressive as well:"...On another front, the Itanium Solutions Alliance announced that worldwide annual Itanium-based factory system revenue and system volume continued to grow in 2007, with a year-over-year increase of 30.8 and 36.3 percent, respectively. The Asia-Pacific region led the way, with year-over-year growth in factory system revenue and system volume of 61 percent and 45 percent, respectively."

Dr. Tim Mattson of Intel is someone to whom we listen closely. He has a better sense of the current situation than nearly anyone else we have spoken with, and he understands and appreciates our efforts with DataRush. He recently spoke at the IEEE DATC Electronic Design Processes Workshop, and this article highlights some of his points.

Mattson demolished another favorite idol of computer science: the parallel programming language. It’s a well-known trait of computer scientists that they will try to solve every problem with a new programming language. The parallel programming problem is no exception. Mattson displayed an eye chart listing the names of nearly 250 parallel programming languages developed just during the 1990s. “This is silly,” said Mattson, “If creating a new language was the solution, the problem would already be solved. This is not the path to a solution.”

Although less frequently now, cccasionally we are still asked about our choice of Java as the language we used to create DataRush. There were many reasons, all valid, but my initial response when I heard the question was why not Java? I had not understood how much market perception still existed around the original impressions from a decade ago -- Java is slow, is big, is constraining. But those who are actively writing applications today are clear on the reality of Java today. We were recently told that in one of our most interesting arenas, financial services, over 50% of new applications are being developed in Java, for example. But the topic still comes up, and I was pleased to be pointed to this link showing the top 10 languages over time.

The TIOBE Programming Community index gives an indication of the popularity of programming languages. The index is updated once a month. The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, MSN, Yahoo!, and YouTube are used to calculate the ratings.

As we begin deploying the first real production apps using DataRush, we find ourselves studying and digging ever deeper into the best ways to improve performance. (see Jim Falgout's JDJ cover story for some discussion of this). We are fortunate that we have good tools and sharp engineers, but more information is always better. This interesting article discusses some aspects of the JVM as a black box, and the challenges of that perspective.

"...most important of all, so long as the JVM remains a black box, the "myths, legends and lore" will haunt us forever. Remember when all the Java performance articles went on and on about how method marked "final" were better-performing and so therefore should be how you write your Java code? Now, close to ten years later, we can look back at that and laugh, seeing it for the micro-optimization it is, but if challenged on this idea, we have no proof. There is no way to create demonstrable evidence to prove or disprove this point. Which means, then, that Java developers can argue this back and forth based on nothing more than our mental model of the JVM and what "logically makes sense"."

"Some will suggest that we can use micro-benchmarks to compare the two options and see how, after a million iterations, the total elapsed time compares. Brian Goetz has spent a lot of time and energy refuting this myth, but to put it in some degree of perspective, a micro-benchmark to prove or disprove the performance benefits of "final" methods is like changing the motor oil in your car and then driving across the country over and over again, measuring how long until the engine explodes. You can do it, but there's going to be so much noise from everything else around the experiment--weather, your habits as a driver, the speeds at which you're driving, and so on--that the results will be essentially meaningless unless there is a huge disparity, capable of shining through the noise."