Living In It: A Tale of Learning in Second Life

I think I have experienced something that captures a unique advantage of virtual worlds, something that cannot be done in the one-dimensional text streams that lay across web 2.0 pages, and cannot even be done in real life.

It's not in the usual answers to a question I still hear: "What is Second Life [or another virtual world] good for?" I know all the standard answers: create your own new life, socialize, educate, introduce products, become a millionaire virtual land baroness, etc. I don't doubt those. They are real, and many have exploited them. But they don't grab me as something that is a unique advantage of a 3D world simulation.

Recently, however, I had an experience there that did grab me and I believe has significant implications for presentation techniques in virtual worlds. As I find the case with most things dealing with virtual worlds, I think this is best described as a narrative, the way I experienced it. So, here's the tale. 

First, a short aside: What has this got to do with the usual subjects for this blog, like multicore, accelerators, cloud computing… Oh, yes. Gotta have something to use all that stuff. Think killer app. End short aside.

Oops, second short aside: What’s below is based on my experience in a course by the Shapiro Negotiations Institute. While this is the only time I’ve run into the kind of thing I describe below, I’ve no information that their implementation is unique. I hope it is not.

Prolog

A while ago (this post got delayed more than six months by my moving into a new house), I happened on an invitation to take a free course in Second Life on negotiating skills, in exchange for commenting about the technology. Free! And something I always think I can learn more about. So I signed up.

The course was run by Mark Jankowski (avatar "Mark Wisenheim") of Shapiro Negotiations Institute. I'd taken another web-based negotiation course, given by a relocation program, so I had some direct experience to compare the Shapiro SL course against; and I've attended some seminars in SL. So I thought I knew roughly what to expect.

I dropped in at the SLURL (Second Life URL) for Shapiro's campus ahead of time to make sure I wouldn't have some hangup on the day of the course, and also to be nosy and poke around.

See the pictures scattered in this post; I later took Second Life snapshots of what I found.

Arriving, I found the usual collegiate-looking green quad that screams "education!", complete with trees, benches, and Georgian-like architecture buildings. There were also some red teleport boxes. Teleports are SL shortcuts: click, and you're elsewhere. So, I clicked.

I found myself in a baseball stadium skybox, looking out over the diamond. Interesting. OK, how do I get out? There was only one door, at the back, so I walked through and found myself falling down a black hole.

I landed in Christmas holiday scene, with big Christmas trees, a large snowman, gifts, a gingerbread house, and snow on the ground. Well, hmm. What else is there?

Walking through a door in a snow-adorned mountain on one side of the scene, I went through some blackness again, but without falling, and into a symphony concert hall. There was wood paneling, a small raised amphitheater seating area for an audience, and a space outfitted for a midsize orchestra with curved ranks of musicians' stations, each with a chair and a music stand, facing a conductor's lectern.

Curiouser and curiouser.

The exit out the side wall lead through blackness again to what I can only describe as an indoor pig farm, complete with pigs, and some strange signs. A dark wooded glen was appended nearby. I could find no further passage, so I clicked on a teleport pedestal – they were scattered everywhere but in the skybox – and found myself back in the quad.

Well, that was strange enough. Christmas with a symphony and a skybox? And pigs? I decided I really would show up for the course, if for no other reason than to see what that was all about.

The Course

On the day of the course, the group of us who signed up met in the quad with Mark. He explained that this would be a run-through of the first phase of their negotiation class, covering preparation, and ushered us through the teleport to the baseball skybox.

In the skybox, he described a negotiation they had done on behalf of a baseball player who was asking for more money than ever previously paid for a shortstop, his position. Preparation: They checked other infield positions, not just shortstop, found many paid higher, and given that data were able to convince the player's club to agree with his request. The message was not to be too narrow in checking out your own worth. We were then posed with a question, and voted by walking into circles designating our choices, had some discussion about it, and left through the back door.

Down the rabbit hole to Christmas-land we went, where we heard about negotiations between a large store and the Amalgamated Order of Real Bearded Santas. The order had a local monopoly, and was jacking up prices. [See clarification in comments below.] Preparation: Found that the store in the past had its own Santa program. At Shapiro's suggestion, the store said they would pay this year, but next year re-start their own Santa program, and not use AORBS. AORBS caved. Message: Don't limit yourself to the present; look to the past, and also use possible future actions as a lever. Voting dance again, and onwards through the black corridor.

In the symphony hall, we heard the tale of a conductor who wanted them to negotiate for him to get a $1 raise. Preparation: Find out what was up with this nut. It turned out that he just wanted the organization to acknowledge that he was special, and getting $1 above union scale would do that. They got him a star on his dressing room door instead. He was delighted, and a potential mess with the union was avoided. Message: Understand what you really want from a negotiation; it may be different from what you are asking for, allowing movement within the negotiation.

Then everybody teleported back to the Quad, went into a conference room, and discussed what we thought. I gave the opinion that the settings probably took a huge amount of effort to construct; on general principles, they probably could have gotten 80% of the effect with 20% of the work. That got a polite nod, like "probably so." I also asked whether they thought Second Life was the best vehicle for this kind of thing. Mark acknowledged that, in particular, they had problems with setup. They actually bought laptops, preconfigured them with SL installed, and shipped them to executive clients for use in the sessions. That also hit me as a major investment. He said they of course got them back, and thought it was worth it when re-used across multiple clients.

That, I then thought, was it.

The Follow-Up

A week or so later, I receive an email request for any follow-up comments. I was ready to provide some unsurprising replies, when I realized something: Everything from that course was still clear in my mind.

In comparison, when I thought back to it, I remembered almost nothing from the earlier webinar I'd attended. Furthermore, the "almost" part was costly: in a salary negation a while back, forgetting one principle from the webinar cost me about a factor of two in consulting fees. Now I'll remember it. Grrr.

Also, my memory of this course was strongly anchored by those settings. I'd think of the orchestra pit, and zang! that conductor sprang to mind, and the point of the session with him. Ditto for the Christmas place and the skybox. Everything I wrote above about the sessions is, in fact, direct from memory. I didn't take any notes during the course. This is unusual for me. I am normally terrible on details, remembering relatively little outside of my notes. So what happened?

Certainly the examples used were memorable, and Mark is an excellent speaker and teacher. But the webinar instructor was good too, and, as far as I recall, which isn't much, her examples were quite good, too. But that isn't what stands to attention in my mind when I think back on this SL course: It's the settings.

Somehow, the experience of walking around inside those places, navigating their geographies, being immersed in it, makes the content easy to bring up from memory.

This seems a bit like a mnemonic trick I've heard of: Imagine a house. Walk around through its rooms, and furnish it with the facts you want to remember. Maybe do something like imagining that the dining room table has Avogadro's number on it, shaped like an avocado. I don't know; I've never managed to use it successfully. But for this course I didn't work at. It just happened.

I think this is related to how easily many people – probably not all; I don't know – can become immersed in a virtual world and identify with their avatars. For example, in real life I have a bit of vertigo. If I unexpectedly find myself near a sharp drop, or drive over a tall bridge, I feel queasy. In a virtual world, when I / my avatar goes near a cliff edge or over a flimsy edge – same thing. My stomach goes into knots. It doesn't matter that the whole thing is a digital construct, not "real." My unconscious processes don't care. As far as they're concerned, I, me, this person, is living in that world, and they react accordingly.

So I didn't attend that presentation, I lived in it. No wonder I remember it.

Compare this with the usual process of hypnotizing chickens with PowerPoint. No, don't bother; there's no comparison. Perhaps there is one useful analogy, though, one that points up a disadvantage to this technique today.

I tend to think of each of the settings used – skybox, Christmas, symphony – as each being analogous to a PowerPoint slide: It's an aid you construct to focus your audience on an aspect of your topic. One big difference that stands out to me is that it's easy to whip up a slide. Building a pocket universe, like those scenes in this course, is just too dang hard for the average presenter, given today's tools. Sorry, Lindens (owners of SL), I know your world is chock full of user-created content, and I've attended all the New Citizens' courses on building, animating, and so on, and I get it. And people obviously do it. But it's just not on a level with slide creation. People hire SL contractors to build stuff for them! Maybe if there were thousands of standard clipart-like objects to use (free! or very cheap, as for slides), and hundreds of template pocket universes to start from (free! or nearly), the situation would be different. Then maybe you could get 80% of the effect with 20% of the work required today.

This train of thought makes slide presentations done in virtual worlds seem perverse. It is, I guess, but they're all over the place. From the ones I've attended in SL, I find them a good halfway point between a webinar and actual physical presence. I do know that while attending them in-world, I'm far less likely to do email or chat with others; not so with webinars, which seem a fertile field for multitasking. Oh, and that's it's not just because my avatar will slump over, asleep, if I don't operate it. (At least it doesn't snore. (I know, it could.)) Slides in SL also do provide a way to transition from traditional web-based education to something in a virtual world. All your presentations can now be done in a corporate boardroom, or in a spaceship, or in a Tiki Hut on the edge of the sea, at sunset, with a virtual Mojito in the hand of every avatar. (I've never understood the point of virtual libations, except as decoration.)

But something much better is possible, something that appears to harnesses our hindbrains directly: Living in a presentation. It cannot be done in two dimensions. You cannot even do it in real life. It's something virtual worlds are, uniquely, good for.

(By the way, no, I never did found out what the pig farm is about.)

Parallel PowerPoint: Why the Power Law is Important

The notion of "parallel PowerPoint" is a poster child for the uselessness of multicore on client computers. Rendering a slide two, four, eight times faster is a joke. Nobody needs it.

Running PowerPoint 4, 16, 64 times longer on my laptop battery, though, that's useful. I am purely sick of carrying around a 3 lb. power supply with my expensively light, carbide case, 3 lb. laptop.

This is why the Parallel Power Law – if the hardware is designed right, the processor power can drop with the square of the number of processors – is important. I'd like to suggest that it is a, possibly the, killer app for parallelism.

There are two keys here, the source of both I discussed in the previous post, the Parallel Power Law. One key is reduced power, of course: Double the processors and halve the clock rate, with associated reduced voltage, and the power drops by 4X (see that post). That decrease doesn't happen, though, unless the other key is present: You don't increase performance, as parallel mavens have been attempting for eons; instead, you keep it constant. Many systems, particularly laptops and graphics units, now reduce clock speed under heat or power constraints; but they don't maintain performance.

The issue is this: All the important everyday programs out there run with perfectly adequate performance today, and have done so for nigh unto a decade. Email, browsers, spreadsheets, word processors, and yes, PowerPoint, all those simply don't have a performance issue; they're fast enough now. Multicore in those systems is a pure waste: It's not needed, and they don't use it. Yes, multiple cores get exercised by the multitasking transparently provided by operating systems, but it really doesn't do anything useful; with a few exceptions, primarily games, programs are nearly always performance-gated by disk or network or other functions than by processing speed. One can point to exceptions – spreadsheets in financial circles where you press F5 (recalculate) and go get coffee, or lunch, or a night's sleep – but they scarcely are used in volume.

And volume is what defines a killer app: It must be something used widely enough to soak up the output of fabs. Client applications are the only ones with that characteristic.

What I'm trying to point to here appears to be a new paradigm for the use of parallelism: Use it not to achieve more performance, but to drastically lower power consumption without reducing performance. It applies to both traditional clients, and to the entire new class of mobile apps running on smart phones / iPads / iGoggles that is now the fastest-expanding frontier.

For sure, the pure quadratic gains (or more; see the comments on that post) won't be realized, because there are many other uses of power this does not affect, like displays, memory, disks, etc. But a substantial fraction of the power used is still in the processor, so dropping its contribution by a lot will certainly help.

Can this become a new killer-app bandwagon? It's physically possible. But I doubt it, because the people with the expertise to do it, the parallel establishment, is too heavily invested in the paradigm of parallel for higher performance, busily working out how to get to exascale computation, with conjoined petascale department systems, etc.

Some areas definitely need that level of computation; weather and climate simulation, for example. But cases like that, while useful and even laudable, are increasingly remote from the volumes needed to keep the industry running as it has in the past. Parallelism for lower power is the only case I've seen that truly addresses that necessarily broad market.

Oh, for the Good Old Days to Come

I recently had a glorious flashback to 2004.

Remember how, back then, when you got a new computer you would be just slightly grinning for a few weeks because all your programs were suddenly so crisp and responsive? You hadn't realized your old machine had a rubbery-feeling delay responding to your clicks and key-presses until zip! You booted the new machine for the first time, and wow. It just felt good.

I hadn't realized how much I'd missed that. My last couple of upgrades have been OK. I've gotten a brighter screen, better graphics, lighter weight, and so on. They were worth it, intellectually at least. But the new system zip, the new system crispness of response – it just wasn't there.

I have to say I hadn't consciously noticed that lack because, basically, I mostly didn't need it. How much faster do you want a word processor to be, anyway? So I muddled along like everyone else, all our lives just a tad more drab than they used to be.

Of course, the culprit denying us this small pleasure has been the flattening of single-thread performance wrought by the half-death of Moore's Law. Used to be, after a couple of years delay you would naturally get a system that ran 150% or 200% faster, so everything just went faster. All your programs were rejuvenated, and you noticed, instantly. A few weeks or so later you were of course used to it. But for a while, life was just a little bit better.

That hasn't happened for nigh unto five years now. Sure, we have more cores. I personally didn't get much use out of them. All my regular programs don't perk up. But as I said, I really didn't notice, consciously.

So what happened to make me realize how deprived I – and everybody else – has been? The Second Life client.

I'd always been less than totally satisfied with how well SL ran on my system. It was usable. But it was rubbery. Click to walk or turn and it took just a little … time before responding. It wasn't enough to make things truly unpleasant (except when lots of folks were together, but that's another issue). But it was enough to be noticeably less than great. I just told myself, what the heck, it's not Quake but who cares, that's not what SL is about.

Then for reasons I'll explain in another post, I was motivated to reanimate my SL avatar. It hadn't seen any use for at least six months, so I was not at all surprised to find a new SL client required when I connected. I downloaded, installed, and cranked it up.

Ho. Ly. Crap.

The rubber was gone.

There were immediate, direct responses to everything I told it to do. I proceeded to spend much more time in SL than I originally intended, wandering around and visiting old haunts just because it was so pleasant. It was a major difference, on the order of the difference I used to encounter when using a brand-new system. It was like those good old days of CPU clock-cranking madness. The grin was back.

So was this "just" a new, better, software release? Well, of course it was that. But I wouldn't have bothered writing this post if I hadn't noticed two other things:

First, my CPU utilization meter was often pegged. Pegged, as in 100% utilization, where flooring only one of my two CPUs only reads 50%. When I looked a little deeper, I saw the one, single SL process was regularly over 50%. I've not looked at any of the SL documentation on this, but from that data I can pretty confidently say that this release of the SL client can make effective use of both cores simultaneously. It's the only program I've got with that property.

Second, my thighs started burning. Not literally. But that heat tells me when my discrete GPU gets cranking. So, this client was also exercising the GPU, to good effect.

Apparently, this SL client actually does exploit the theoretical performance improvements from graphics units and multiple cores that had been laying around unused in my system. I was, in effect, pole-vaulted about two system generations down the road – that's how long it's been since there was a discernible difference. The SL client is my first post-Moore client program.

All of this resonates for me with the recent SC09 (Supercomputing Conference 2009) keynote of Intel's Justin Rattner. Unfortunately it wasn't recorded by conference rules (boo!), but reports are that he told the crowd they were in a stagnant, let us not say decaying, business unless they got their butts behind pushing the 3D web. (UPDATE: Intel has posted video of Rattner's talk.)

Say What? No. For me, particularly following the SL experience above, this is not a "Say What?" moment. It makes perfect sense. Without a killer application, the chip volumes won't be there to keep down the costs of the higher-end chips used in non-boutique supercomputers. Asking that audience for a killer app, though, is like asking an industrial assembly-line designer for next year's toy fashion trends. Killer apps have to be client-side and used by the masses, or the volumes aren't there.

Hence, the 3D Web. This would take the kind of processing in the SL client, which can take advantage of multicore and great graphics processing, and put it in something that everybody uses every day: the browser. Get a new system, crank up the browser, and bang! you feel the difference immediately.

Only problem: Why does anybody need the web to be 3D? This is the same basic problem with virtual worlds: OK, here's a virtual world. You can run around and bump into people. What, exactly, do you do there? Chat? Bogus. That's more easily done, with more easily achieved breadth of interaction, on regular (2D) social networking sites. (Hence Google's virtual world failure.)

There are things that virtual worlds and a "3D web" can, potentially, excel at; but that's a topic for a later post.

In the meantime, I'll note that in a great crawl-first development, there are real plans to use graphics accelerators to speed up the regular old 2D web, by speeding up page rendering. Both Microsoft and Mozilla (IE & Firefox) are saying they'll bring accelerator-based speedups to browsers (see CNET and Bas Schouten's Mozilla blog) using Direct2D and DirectWrite to exploit specialized graphics hardware.

One could ask what good it is to render a Twitter page twice as fast. (That really was one of the quoted results.) What's the point? Asking that, however, would only prove that One doesn't Get It. You boot your new system, crank up the browser and bam! Everything you do there, and you do more and more there, has more zip. The web itself – the plain, old 2D web – feels more directly connected to your inputs, to your wishes; it feels more alive. Result?

The grin will be back. That's the point.

Getting Back to Comments

It’s more than time to respond to some of the comments that have been posted. I’ve copied the shorter ones here, and summarized the longer ones. If your comment isn’t here, it’s because no response seemed needed, or I already responded with a comment of my own.

Steve, on IT Departments Should NOT Fear Multicore: I think you're spot on concerning why IT shouldn't fear multicore. Where they fear it, it's because they've had innovation beaten out of them.

I agree, Steve. Another possibility is that they are so very conservative they fear changing anything – which may be saying the same thing. It’s possible Claunch was trying to wake up the change-fearing crowd, but why he didn’t virtualize (or why Dignan didn’t repeat it) I just don’t understand, except in the most cynical possible way (“Oooh, it’s scary! Hire us to tell you what to do!”).

Several folks commented on Vive la (Killer App) Revolution!

Stu: isn't the killer app 'information retrieval' ? i.e. google search, or commoditized parallel data warehousing and mining?

Stu, sure those use multicore, but they’re server apps; see IT Departments Should NOT Fear Multicore for more about how server apps soak up multicore quite well. That article was looking for, and arguing that we need, client apps.

Steve: Embedded systems could soak up a lot of low power multiprocessor chips. At least a couple of start-ups are working on them. Intellasys has a very low power 40 core chip and XMOS has a 4 core chip with 8 hardware threads per core.

They surely can soak up some, Steve, but I don’t think enough. The high end, in things like MRI scanners, has really miniscule volumes. The low end, in things like dishwasher controllers, has enormous volume but only requires trivial capabilities; it doesn’t take much brains to run a dishwasher. The only high-volume fairly high-price case is PC clients, where new CPUs go for $100s – and possibly game systems. I don’t know the relative volumes of PCs and game systems. I suspect the game systems are pretty big, but not in the PC range, since they’re not on every desk in every business.

Philip Machanick: What is really needed is a killer app that addresses some real mass-market need. The history of computing tells us that technology packaged for low cost eventually overtakes technology packaged for speed, first on price:performance and eventually on performance. More at my blog.

Philip, I share much of your astonishment and unbelieving about multicore, but I think what you’re referring to with “low cost eventually overtakes” is the Disruptive Technology process of Clayton Christensen’s "The Innovator's Dilemma." I don’t think that’s what’s happening here, or can happen here. I think multicore is more like the process in which cars eventually just got fast enough for everybody, so to keep selling them manufacturers invented tail fins. I’m not sure that has a name other than “marketing.”

TerryMcIntyre: [My summary of his long comment: He thinks killer apps include crosses between games and tutors, managing your photo collection including face recognition and recognition-driven auto-tagging, optimizing use of applications, and smart implementations of Go (and the like).]

Those are all possibilities, Terry. One requirement I’d put on things, however, is that somebody know how to do it, meaning a practical algorithm is known. I think that rules out things like auto-tagging everything looking like the Grand Canyon from some examples. I’m not sure about Go.

Robert on Clarifying the Black Hole: Greg, With this sentence: "Unfortunately, servers alone don't produce the semiconductor volumes that keep an important fraction of this industry moving forward – a fraction, not all of the industry, but certainly the part that's arguably key, to say nothing of the loudest, and will make the biggest ruckus as it increasingly runs into trouble." you tap dance around this "important fraction of the industry" without actually saying who they are. Who, precisely, are these people who can't easily parallelize, and really need continuing performance gains, and constitute a significant fraction of the computing market? Before we can find new solutions for them we need to know who they are and what they are trying to accomplish.

Ok, Robert, a spade a spade: I believe that the technological trend of multicore hurts the traditional business models of Intel and Microsoft, and their derivative PC hardware and software vendors: HP, Dell, and company. That’s not to say they’ll have financial problems; finances are affected by a lot more than technology.

John on 101 Parallel Languages (Part 3, the last): [My summary of his long comment: My conclusion shouldn’t be so negative; we need to find new modes of expression expressing parallelism.]

John, all I can say is that’s not the evidence I see. Some language extensions can help; but I’m thinking here of relatively low-level support like, say, truly low-weight thread spawning in Java. But I think the attempts to provide parallelism in ordinary, programming-for-the-rest-of-us things are fundamentally misguided.

dvadell on Background: Me and This Blog: I'm very happy I found your blog. I can finally say: Thank you for "In search of clusters"! I couldn't get it here in Argentina so a friend of mine sent it to me from USA. I enjoyed (and laughed) a lot.

Well, thanks, dvadell. I’m glad you found it enjoyable. I hope I manage to get another out there for you in the foreseeable future.

Vive la (Killer App) Révolution!

I've pointed to finding applications that are embarrassingly parallel (EP), meaning it is essentially trivial for them to use parallel hardware, as a key way to avoid problems. Why should be the case?

Actually, what I’m trying to find are not just EP applications, but rather killer apps for mass-market parallel systems: Mass-market applications which force many people to buy a “manycore” system, because it’s the only thing that runs them well. In fact, I’m thinking now that EP is probably a misstatement, because that’s really not the point. If a killer app’s parallelism is so convoluted that only three people on the planet understand it, who cares? The main requirement is that the other 6.6 Billion minus 3 of us can’t live without it (or at least a sufficiently large fraction of that 6.6B-3). Those three might get obscenely rich. That’s OK, just so long as the rest of us don’t go down the tubes.

I’m thinking here by analogy to two prior computer industry revolutions: The introduction of the personal computer, and the cluster takeover. The latter is slightly less well-known, but it was there.

The introduction of the PC was clearly a revolution. It created the first mass market for microprocessors and related gear, as well as the first mass market for software. Prior to that, both were boutique products – a substantial boutique, but still a boutique. Certainly the adoption of the PC by IBM spurred this; it meant software developers could rely on there being a product that would last long enough, and be widespread enough, for them to afford to invest in product development. But none of that would have mattered if at the time this revolution began, microprocessors hadn’t gotten just (barely) fast enough to run a killer application – the spreadsheet. Later, with a bit more horsepower, desktop processing became a second level (and boosted Macs substantially) but the first big bump was the spreadsheet. It was the reason for the purchase of PCs in large numbers by businesses, which kicked everything into gear: The fortuitous combination of a particular form and level of computing power and an application using that form and power.

Note that nobody really lost in the PC revolution. A few people, Intel and Microsoft in particular, really won. But the revenue for other microprocessors didn’t decline, they just didn’t have the enormous increases of those two.

The takeover of servers by clusters was another revolution, ignited by another conjunction of fast-enough microprocessors and a killer app. This time, the killer app was the Internet. Microprocessors got just fast enough that they could provide adequate turnaround time for a straightforward “read this page” web request, and once that happened you just didn’t need single big computers any more to serve up your website, no matter how many requests came in: Just spray the request across a pile of very cheap servers. This revolution definitely had losers. It was a big part of what in IBM was referred to as “our near-death experience”; it’s hard to fight a difference in cost of about 300X (which is what I heard it estimated within IBM development for mainframe vs. commodity clusters, for cases where the clusters were adequate – big sore point there). Later Sun succumbed to this, too, even though they started out being one of the spears in IBM’s flanks. Once again, capability plus application produced revolution.

We have another revolution going on now in the turn to explicit parallelism. But so far, it’s not the same kind of revolution because while the sea-change in computer power is there, the killer app, so far, is not – or at least it’s not yet been widely recognized.

We need that killer app. Not a simpler means of parallel programming. What are you going to do with that programming? Parallel Powerpoint? The mind reels.

(By the way, this is perfect – it’s exactly what I hoped to have happen when I started this blog. Trying to respond to a question, I rethought a position and ended with a stronger story as a result. Thanks to David Chess for his comment!)