When Value Exceeds Price, Parallelize
20 Apr 2007
My father has been in direct marketing for years now and in sales for even more years before that. He’s picked up a number of colorful phrases along the way (some so colorful that they can’t be repeated here), but he often shares this fine nugget:
When value exceeds price, a deal is made.
I’ve always found that to be a Zen koan-like phrase, especially given that neither value nor price are necessarily fixed, and you can manipulate either to make a deal. When you can’t budge the price, bump the value. And when real value isn’t elastic, you do as great salesmen do and create perceived value. An Ariel Atom, strictly speaking, is just a car, a mode of transportation of comparable value to a Dodge Neon. Four wheels, brakes, moderate gas mileage. So why does an Ariel Atom trade at a price at four times the price of a Neon? Because, for some, the self-image of open-wheeled racing and thrilling performance has a value. And if that value (plus the real value of owning a car itself minus the premium demanded to avoid destitution) exceeds invoice, somebody’s pulling out a checkbook.
Anyway, I was reading Larry O’Brien‘s post, “Map, Everything’s An Object, and Inline”, and I kept thinking about this relationship. The changes in modern hardware, the palpable lean of our tools toward parallelism — these factors are creating a considerable value proposition for pervasive concurrency. Multithreading is suddenly starting to look more “fat free” than “free fat”. Erlang is coming back from the dead. PlayStation 3 consoles are topping the teraflop charts at Folding@Home.
But when a coder introduces threading to solution, are they creating real value or perceived? Is it faster? Is is simpler? Is it better? Is it appropriate?
I love functional languages and their neat mapping into parallel constructs. I love the idea that a program may be paired someday with a virtual machine capable of wise and balanced decisions to parallelize or distribute based on an accurate assessment of real costs and benefits. But I wonder if, like Larry suggests, the intermediate solutions of compiler switches, pragma statements, and metadata attributes might just be nothing but enough rope to hang ourselves with.