Dan Bricklin Shreds Wikipedia’s "Spreadsheet" page

Dan Bricklin has posted a thoughtful article on Wikipedia’s “Spreadsheet” page. Bricklin quickly establishes that the page is well below par and may be tainted by someone’s personal agenda. Given Bricklin’s knowledge and involvement with this important topic, the critique should certainly be taken seriously, both as an indictment of the page as it currently and, more deeply, as a warning sign of trouble with the Wikipedia model. I don’t want to get into a debate weighing the relative value of dead-tree versus online journalism, but anyone interested in the subject ought to read and reflect upon Bricklin’s article.

Google Buys Peakstream, Hot Young Player in General Purpose GPU (Concurrent) Programming

 Google’s interest in concurrent programming is no surprise — indexing the Web involves a lot of parallelism — but their acquisition of Peakstream, developers of a low-level programming tool, is startling.

To quickly review: today’s Graphics Processing Units (GPUs) are every bit as complex and powerful as the CPU. As opposed to mainstream CPUs, though, they are already highly parallel, with up to several dozen pipelines. I say “already” because highly parallel processing units is the future that awaits us all; it’s one reason why I’ve been writing lots of articles about GPUs (the other reason being that graphics are hella’ cool).

The trade-off for the high parallelism of GPUs is that they don’t have anywhere near the flexibility of CPUs; the pipelines are quite rigid, with severe restrictions on memory access and code length. GPUs are architected to quickly perform matrix math on big parallel arrays (geometry and pixels), and for such tasks, they are blazingly fast. This graph shows the advantage of a GPU-based Mandelbrot set calculation I wrote.

A sufficiently motivated programmer with a highly parallel task can sometimes recast his problem so that it conforms to GPU architecture (arrays become textures, calculations become pixel coloring, etc.). This is what is known as “General Purpose GPU” (GPGPU) programming. Such recasting is difficult, especially across the broad ecosystem of GPUs, each with differing performance capabilities and characteristics. (For instance, that Mandelbrot shader I wrote exceeds the code length supported by my $350-in-2006 graphics card.)

Peakstream is one of several companies that promises to make GPGPU programming easier. Since GPGPU is a fairly extreme task, it is no surprise that there are also academic and FOSS tools. 

Last Fall, Peakstream started making PR noise. As soon as I saw their press release, I expressed interest in seeing their technology. I never heard back from them. They also nominated themselves for a Jolt Award. But, when asked to provide access to their technology so that we could, you know, evaluate it, we never heard back from them. At the time, I wrote them off as having put the PR cart in front of the technology horse. In retrospect, perhaps Google had already begun their acquisition inquiries.

One way or the other, the question of what Google is going to do with Peakstream’s technology is fascinating. Are they going to use it as an internal advantage? What I don’t get about that is: they’re Google. My investigation of GPGPU libraries and tools was a major influence on my conclusion that there is no near-term “one size fits all” solution to concurrent programming — the hardware is too demanding and too specific to be abstracted away. I am highly dubious that Google would trade a modicum of programming ease for a significant penalty in run-time performance. That’s not how Google works.

My analysis of GPGPU is that the only thing that would really be worthwhile is a complete compiler chain. And not your CS201 “Introduction to Compilers” compiler, but a serious-voodoo compiler, with hardware-specific transforms, dynamic profiling, etc. If Peakstream had that (and the talent to put such a thing together), then I could imagine Google absorbing the company for internal use.

The other, more interesting, possibility is that they intend to offer Peakstream’s technology to the masses. But while it’s fair to say that Google has created a programming platform with APIs to their hosted services, a GPGPU tool is the furthest thing from a Web Service imaginable. GPGPU is as low-level as it gets: C-like languages are considered “high level” and the tools are binary libraries and compilers. These are the types of tools that one expects to come from Intel, AMD, and Nvidea. Why would Google get involved?

Perhaps the answer lies in that “already” that I threw out all those paragraphs ago. Whoever — and I mean whoever — figures out a way to get the mainstream through the manycore tsunami dictates the development platform for the 2010s. Maybe Google is interested in having a say.

Book ‘Bots Battling Builds Bizarreness?

Have you ever noticed that “Buy This Book Used…” prices from Amazon and the like are often bizarre? Often they’re strangely specific — “$43.72” — and often they’re insanely overpriced “Paperback 23rd Printing of Programming with dBase II: $1,234.56”

Jeff Duntemann thinks it’s due to ‘bots. If it’s not, it’s not a bad idea for a business:

 

 

Register yourself with Amazon et al. to receive used-book requests

Set constant minimum_acceptable_profit_per_book

Set constant hoped_for_profit_per_book

Set constant cost_of_remailing

On receipt of used-book request{

check your used_book_quotes dictionary for a price

if you don't have a price{

   make the same used-book request

   record quoted price from other suppliers

   set price = quoted price from other suppliers + cost_of_remailing + hoped_for_profit_per_book

}

else #You do have a price

{

   quote price

   if accepted {

       sell, achieving profit >= minimum_acceptable_profit_per_book

   }

else #not accepted

   {

      diminish price towards: quoted price from other suppliers + cost_of_remailing + minimum_acceptable_profit_per_book

   }

}

}

The downside is that with multiple such agents in the system, you can see how “quoted price from other suppliers” would lead to a positive feedback loop.

"Service Unavailable" Woes: It Appears that dasBlog is Spontaneously Restarting

I’m aware that my blog has been troublesome lately (hopefully, your aggregator has borne the pain). I run dasBlog, which I generally like and in which I have an insane investment (oh, look, I started this blog 5 years ago this month). However, sometimes I envy those who use a hosted provider. Right now, my dasBlog logs seem to show that dasBlog is restarting every few minutes. The other exceptional thing is that the log is filled with “Validation of viewstate MAC failed” exceptions that very much appear to be the result of comment/referrer spam attempts. Are these exceptions, perhaps, causing the restarts? I dunno’. Anyway, I’ll try to see if there’s anything I can do about it…

IBM’s Telelogic Acquisition: Buying Marketshare, Not Expanding Market

I agree with Alan Zeichick’s analysis of IBM’s acquisition of modeling tool vendor Telelogic:  the overlap with IBM’s Rational product line is high, the acquisition “is a bid to buy market share….we’ve taken a powerful innovator and strong IBM competitor out of the market.”

The software development industry typically pendulums on modeling tools: excess, backlash, abandonment, code is king, frustration, some modeling helps, we can model everything, excess …

Right now, modeling is not popular. But I think it’s actually passed its nadir and, if history holds, we should see modeling increase in popularity. The problem for IBM and Rational is that part of the pendulum is the embrace of new modeling graphics/languages.