Totally disagree with the notion that compilers need to somehow gleen implied parallelism from the source code. If anything.NET and J2EE taught us is that developers can indeed consume relatively complex frameworks to achieve threaded/concurrent application design. In this case,.NET and J2EE take care of OLTP computing architectures.
For data-intensive batch processing, we have http://www.pervasivedatarush.com/ and other frameworks. Yes, you have to be able to build self-contained components that can be assembled in a dataflow graph of sorts... but developers had to learn the same craft when EJB's were invented.
Bring on the cores, Intel. Do you feel lucky? Do ya?
Well, if you are building data-intensive apps (gigs and terabytes of data in a batch processes), then you use http://www.pervasivedatarush.com/ and not OpenMP....or COBOL !!
Well, it doesn't solve world hunger, but parallel processing on an 80-core chip?
Yup...can eat this sucker for breakfast... well, when it can support a JVM that is:-)
This was a good focus group (oh, you didn't realize?) on the state of software as it relates to multicore architectures. I'm going to try and summarize what has got to be apparent to most people reading all these threads.
a) Education in software development community must continue. Witness Intel's unprecedented outreach to global universities upon the launch of what I call "the multicore arms race" last year. Whether you are in the "j2xs is stupid" camp or the "j2xs is a crazy alarmist, but has a point" camp -- you can't deny the total disarray of responses. Guess what Mr(s) CIO, these are the people coding the software running your business. Take note here and tell me there is no way icebergs can bring down Titanic (good movie... I cried...). Look here and tell me the dot-net hockey stick growth curve will never end (uh...oops) -- meaning 'the one with the loudest mouth is NOT right... (s)he is just loud, man.'
b) I was not commenting on the 3% of developers that make up concurrency, grid computing, gaming (hard stuff!), most infrastructure ISV's (can invest in PhD's), etc... I was commenting on the 98% of the rest of us who code business software in Global 2000 organizations. I was commenting on the 200,000,000 lines of COBOL (that I helped write while with Accenture) powering corporations that doesn't have a single hint of parallelism in it. Last 5 years of Perl code? Nope, no parallelism. Last 5 years of Python? Nope, no parallelism. A significant portion of consultants on large projects in the 90's were actually MBA's who learned to program 3 months prior... wonder if that's still the case? Wonder if 98% of consultants have cracked the book on concurrent programming, OpenMP, MPI or Haskell yet?
Fully agree the J2EE, ESB camps are more or less immune due to bean pooling and threading support; however, each EJB cannot run parallel code (container won't allow) and there are many 20 second bean executions out there that could run in 8 seconds. Ever run Foo.Sort()? Not parallel; should be. Most likely an edge case?
c) Yes, if each core in each CPU continues to double in clock-speed every year, then this post will go down in the history books as truly "from da-end-of-da-world desk". But it's not me saying that clock speeds likely won't double every year (until breakthrough in physics occurs), it's the chip vendors themselves.
d) Yes, if your server has 40 running processes after boot up, then your apps will _seem_ to speed up because they have their own little "core kingdom" to use. My point wasn't 2007...it was 2010 when you have 64+ cores and the clock speed is still not increasing. 128+ cores and still no clock speed increase. Hmmm... those non-OLTP business apps don't _seem_ to be speeding up anymore do they? Yet you are paying through the nose for new processor technology. Your CFO will be asking about Return on Assets (ROA) soon...
In closing, I would like to address the small fraction of you that couldn't find "deadly slow" in the IBM article. I had put "(my words)" in my post to slashdot... for some reason that phrase went MIA when the post hit the air. The title, in retrospect, should have included a question mark on the end (in true passive-aggressive Internet behavior).
Slashdot Mirror
Totally disagree with the notion that compilers need to somehow gleen implied parallelism from the source code. If anything .NET and J2EE taught us is that developers can indeed consume relatively complex frameworks to achieve threaded/concurrent application design. In this case, .NET and J2EE take care of OLTP computing architectures.
For data-intensive batch processing, we have http://www.pervasivedatarush.com/ and other frameworks. Yes, you have to be able to build self-contained components that can be assembled in a dataflow graph of sorts... but developers had to learn the same craft when EJB's were invented.
Bring on the cores, Intel. Do you feel lucky? Do ya?
Well, if you are building data-intensive apps (gigs and terabytes of data in a batch processes), then you use http://www.pervasivedatarush.com/ and not OpenMP....or COBOL !!
Yes! Thank you! And here's some help with those apps on 80-core chips...
http://www.pervasivedatarush.com/
Well, it doesn't solve world hunger, but parallel processing on an 80-core chip? :-)
Yup...can eat this sucker for breakfast... well, when it can support a JVM that is
http://www.pervasivedatarush.com/
Smart poster...
This was a good focus group (oh, you didn't realize?) on the state of software as it relates to multicore architectures. I'm going to try and summarize what has got to be apparent to most people reading all these threads.
...it was 2010 when you have 64+ cores and the clock speed is still not increasing. 128+ cores and still no clock speed increase. Hmmm... those non-OLTP business apps don't _seem_ to be speeding up anymore do they? Yet you are paying through the nose for new processor technology. Your CFO will be asking about Return on Assets (ROA) soon...
... for some reason that phrase went MIA when the post hit the air. The title, in retrospect, should have included a question mark on the end (in true passive-aggressive Internet behavior).
a) Education in software development community must continue. Witness Intel's unprecedented outreach to global universities upon the launch of what I call "the multicore arms race" last year. Whether you are in the "j2xs is stupid" camp or the "j2xs is a crazy alarmist, but has a point" camp -- you can't deny the total disarray of responses. Guess what Mr(s) CIO, these are the people coding the software running your business. Take note here and tell me there is no way icebergs can bring down Titanic (good movie... I cried...). Look here and tell me the dot-net hockey stick growth curve will never end (uh...oops) -- meaning 'the one with the loudest mouth is NOT right... (s)he is just loud, man.'
b) I was not commenting on the 3% of developers that make up concurrency, grid computing, gaming (hard stuff!), most infrastructure ISV's (can invest in PhD's), etc... I was commenting on the 98% of the rest of us who code business software in Global 2000 organizations. I was commenting on the 200,000,000 lines of COBOL (that I helped write while with Accenture) powering corporations that doesn't have a single hint of parallelism in it. Last 5 years of Perl code? Nope, no parallelism. Last 5 years of Python? Nope, no parallelism. A significant portion of consultants on large projects in the 90's were actually MBA's who learned to program 3 months prior... wonder if that's still the case? Wonder if 98% of consultants have cracked the book on concurrent programming, OpenMP, MPI or Haskell yet?
Fully agree the J2EE, ESB camps are more or less immune due to bean pooling and threading support; however, each EJB cannot run parallel code (container won't allow) and there are many 20 second bean executions out there that could run in 8 seconds. Ever run Foo.Sort()? Not parallel; should be. Most likely an edge case?
c) Yes, if each core in each CPU continues to double in clock-speed every year, then this post will go down in the history books as truly "from da-end-of-da-world desk". But it's not me saying that clock speeds likely won't double every year (until breakthrough in physics occurs), it's the chip vendors themselves.
d) Yes, if your server has 40 running processes after boot up, then your apps will _seem_ to speed up because they have their own little "core kingdom" to use. My point wasn't 2007
In closing, I would like to address the small fraction of you that couldn't find "deadly slow" in the IBM article. I had put "(my words)" in my post to slashdot
-j2xs