Good post @Garcia-. I'd like to respond to every point so to reduce the risk of losing the readers attention, I'll do it in reverse chronological bullet format:

If we erased every EETimes article that seemed like an advertisment there would a lot less to read. Sans Junko's most welcome cold-water post about her Washer and Grill on a Date, I enter the entire trail of IoT as evidence. It reeks of a huge PR campaign. But it's all over these pages and I accept it as inevitable. Are the flashy, obvious ad-banners on the sides and tops of the articles we read the only way publications like these make money?

I share your appreciation about the exposure of the real status of Internet software. I didn't know much of that legacy story but it makes perfect sense. Intuitively, a casual observer would think that all internet infastructure would have moved along with the times, but then again, anyone in a corporate environment ought to be weary of dealing with old processes that are still in place for no other reason than reliability and familiarity. What's also interesting to me is that they're going after this market in the first place. If the whole system is disperate and kludgy then wow, what a nation-big task it'll be to find out who owns all this stuff and then convince them to pay for upgraing it? I suppose it'll involve calls to the likes of Jeff Bezos and Larry Flint.

Thwarting the poo-pooers is a needed function in discourse. Kudos to you. And that's coming from a serial poo-pooer.

Some stuff I'm not allowed to talk about yet, but I gathered a lot of input from comments and emails and sent it to the folks at SVIRAL and they've given me a lot of responses -- I'm travelling at the moment and up to my armpits in alligators fighting fires -- but I'll post a follow-up column with all the questions and answers when I get back.

@TanjB: I strongly disagree with your opinion. This column was in my "TO-READ" list and I've really enjoyed the content presented in each of the three pages.

Maybe you are used to the subtleties of concurrent programming and even HW algorithm acceleration (as I am) and this stuff is obvious for you, but not everyone has this background. I think that the examples that Max has exposed are really illustratives about how hard is squeezing all the juice from a multi-core/multi-threaded architecture.

I've also enjoyed how he has exposed the real status of the Internet software and that most of the critical software building blocks are inherited from the early golden-age of open software (GNU, UNIX...).

And finally, about if this is an "ad", this is just a column presenting a new glowing technology from a start-up company. Before emiting a quick judgement and veredict, let's see if they are able to demonstrate their achievement in more applications and HW architectures: I'm frankly eager to know more about this.

- some folks claim they have magic pixie dust which can fix this, unlike any of the dust we have seen and tried in the past 50 years (some of which actually works and is widely used on all the low hanging fruit)

This doesn't sound much more promising than the hype I've heard before. I think I can expect a few more years getting paid doing parallelism the old-fashioned way: Verilog.

One good problem to test parallel architectures is the N-body simulation (simulating the motion of say, hundreds of stars in a cluster). It's a good problem because at each time step each body's new velocity vector is a function of every other body's position, so it's not very easy to split the sim into separate tasks/threads.

As the patent explains, their approach is a lot more than "two additional constructs" as one might expect, and I'm under the impression that if you want to enjoy performance and true scalability you will have to heavily refactor/rewrite your code (see the "pixel" example). You have new keywords, new operators, new semantics, but all in all nothing unexpected to allow programmers to write parallel programs. By the way, when they say "multi core" they mean "heterogeneous cores", and this is even more interesting (and difficult). In a way they've created an OpenCL-like streaming language for all kinds of cores (the patent summary even includes FPGAs!)

That said, stream programming has existed for decades (as the patent's authors/SVIRAL founders themselves point out), so whether their flavor works better than past attempts remains to be seen. They also have another related patent on a specific hardware design to execute streaming programs faster: http://www.google.com/patents/US20110179252

The SVIRAL "technology" link on their web pages mentions "patented technology", and a quick search of the USPTO database for patents with SVIRAL in the Assignee field came up with patent 8,782,196, a hardware scheduling mechanism that looks like a hardware scheduler based on an implementation of Dijkstra semaphore-protected buffers.

A quick Google search also shows that they got $20M of funding to make "distributed data centers" out of black (idle) cores. I smell a bit of hype in that, but we'll eventually get to see what they *really* mean.

There haven't been many new ideas in this field for a long time, but as someone pointed out, their innovation may simply be a way of making something well-known more accessible. We'll see.

The use of multi-threading in today's software is actually rampant, though often done behind the scene in libraries where average programmers don't have to deal with the full complexity. Looking at the Activity Monitor on my Mac, I see Skype with 28 threads, Itunes with 24, Arduino SDK with 23, Safari with 22, Xcode with 18, Flash Player (Safari content) with 18, Mail with 17, etc., etc. Only a dozen (all classic UNIX code) of the roughly 500 active processes have 1 thread. The only way modern computers function at all, given the difficulty of doing good multi-thread locking/protection/deadlock prevention, is for the libraries to be automating a lot of it. Hopefully that's what SVIRAL is up to -- it's hard to move the needle on skill level of all the programmers in the world.

@Paul: There is also the constraint that the software must run on existing hardware which generally does not provide minimal-cost (in latency and energy) communication, being based on generic cache coherence.

I have not yet been brought into the "inner circle" -- but I hope to be able to discover more and report back in the not-so-distant future.