I got to thinking about this the other day and contemplated on whether or not this applied to more than just execution speed performance. Specifially, I was wondering if we're still in the free lunch phase with regards to energy efficient performance or if developers can still coast on their laurels since new hardware continues to become still better at using less and less energy.

I arrived as this existential conundrum as I was looking over an internal presentation for an upcoming processor release from Intel. One prominent feature that was touted was the increase in energy efficiency to be realized by the new chip. Better technology has reduced the energy leakage within processor circuits. I imagine that there is more research and development (or already has been such R&D) that can be and will be done in the near future to get even better energy performance from processors. If that is the case, why should software developers be concerned with programming applications that actively conserve power?

(If you're a laurel coaster, stop here, don't read the rest of this post, and go check out your favorite online comic strip.)

For those of you that are still reading, let me first say, you can be sure that your competitors are taking steps to write software that uses the processing cores more efficiently. In terms of performance, the fastest software will be the one that sells more copies. Energy efficiency has become another dimension for comparing competing software products. In some cases, it might even be the more important dimension for a consumer's choice.

Mobile devices have become nearly ubiquitous (or so they tell me). After some amount of use these devices need to be recharged. If your application runs down the stored battery power faster than an alternative product, users will gravitate to that competing software. Device owners have already spent a pretty penny on their current hardware.  It is highly unlikely they are willing to wait months to upgrade to a model with a better energy conserving processor in order for your software to not drain the battery as quickly. If this is your strategy for energy efficient performance, you've already lost the sale. Even if users would be willing to wait, they'll be using something else and getting familiar with that software. Besides, the better energy efficiency of a new processor will also benefit your competition's software.

Secondly, it's really not all that hard to program for energy efficient performance. Many of the things you would already do for execution optimization and performance (use better algorithms, multiple threads, compiler optimizations, etc.) will directly benefit the power consumption rate of your software. For more techniques and ideas on how to upgrade your applications to be more energy efficient, visit the Intel Power Efficiency Community.

Sitting around and waiting for the next helping of improved energy efficient hardware "free lunch" to make your software better is easy. (Heck, you might even be able to surreptitiously take time off from work to practice your drumming at the beach.) But if you're interested in making your software the best that it can be and the most desired products to consumers, be proactive and start looking at how to improve your application's power considerations today. There will be time for beach drumming after you make that first million dollar$.

To me, the most surprising  job that was mentioned in the article was for psychiatrists. The reasoning for such positions was to ensure robots will "have a mental picture of what people are doing around it". Psychiatrists would observe how humans interact with robots and be able to suggest better behavior or design changes to improve such interaction. (When I read this my first thought was about Dr. Susan Calvin and the Three Laws of Robotics or picturing Robbie the Robot laying out on a couch talking to his therapist.)

There was also a reference made that indirect industries (restaurants and service industries) would also benefit with expanding numbers of jobs. I can understand the need for engineers and programmers to develop working models of robots, but I would have thought that the advent of robots would start taking jobs from workers in many of the service industries. Won't we soon have robot waiters, robot salesmen, and robot butlers?

I don't want to see someone lose their job, but if we have autonomous robots, I think that there will be more jobs lost (to robot replacements) than there will be jobs created. Of course, that will all depend on how well the psychiatrists are doing their job to influence designs and perceptions to be more readily accepted by the public. If we're going to start with more household automation (like all the cleaning robots in the 1947 short "House Hunting Mice"), it might be easier to introduce other service industry robots nito our modern society.

The article, being focused on careers, ends with some helpful advice about how you can get into the robotics industry. There are many different industries that will be touched by robotics and you may need to specialize in something other than engineering or programming. For example, to design and create medical robots, you should have some experience or knowledge about biomedicine.

All in all, if you're interested in robotics, this sounds like a cool opportunity. I have probably watched too many SF movies with robots in them and will likely be disappointed with the current state of the technology myself. I don't think we're getting close to entering the world portrayed in Magnus, Robot Fighter. However, my great grand nieces and nephews could be very close in their lifetimes.

What seemed most disturbing to me was the limit on the number of cores being self-inflicted. Surely we can't have reached the maximum number of cores that are possible to squeeze onto a chip? The whole "right turn" idea to add cores rather than try to cool processors reaching rocket engine temperatures was less than 10 years ago. I'm not sure where the physics starts to overshadow Moore's Law, but I thought I'd  heard that a few more generations of smaller wire sizes in processor dies were still possible. So why not push more and more cores into the same package?

It might be that the average server application (and, perhaps even more so, consumer applications) can't scale well beyond some fixed number of cores. How many cores does it take to type and post a tweet or update your Facebook status or to watch a streaming video? Would any of those tasks be faster or somehow enhanced if there were twice the number of cores available?

If we stop increasing the core counts in the next 5 years, how will new chips keep fulfilling the ever-growing hunger for more performance by consumers? Maybe it won't be about faster and faster application exeuction, but more about less energy consumption while maintaining a level of performance. I guess at some point we'll stop being concerned about Gigahertz or core counts because all processors will be able to do many of the same tasks in about the same amount of time.

I do know that power consumption is going to be a major driving design force as HPC moves closer toward Exascale platforms.  Thus, if the THX-1138 processor draws power twice as fast as the CFM602 processor, I would be more likely to build my system equipped with the former.

The authors look to evaluate which of three possible processor core architectures might be best for parallel execution that minimizes energy consumption. The three model core arrangements are 1) multi-core (several large processing cores on a single chip), 2) manycore (lots and lots of simpler, more power efficient cores), and 3) a combination of a single large core with many simpler cores. The first is like the current dual-, quad-, and hexa-core processors, the second is akin to a GPU, and the third is a hybrid conglomeration of large core sitting on a GPU.

For the purposes of the model formulas, the maximum power consumption of a single large core is normalized to 1 and the power consumption of an idle processor is an added variable, k. For the first architecture, the new variable is used in the traditional Amdahl's Law formula as a multiplier to the serial percentage of time multiplied by the (n-1) idle cores. Some simple algebraic manipulation and the authors generate a formula for estimating the average power consumption, in watts (W), for a parallel application with n cores and the stated percentages of parallel and serial work. A similar derivation is done for the manycore model with the power consumption per simple core being 0.25 of the large core. With the hybrid model, the assumption used to derive a corresponding formula is for the large single core to handle the serial execution and the simpler cores do the parallel work.

Since a measure of the watts consumed is provided by the model, the authors then compute performance per watt (Perf/W) by computing the original Amdahl's formula divided by the formula to compute W. In order to compare the three model to each other, a power budget is imposed, which sets the number of cores available for each model.

The conclusions drawn from comparing the model with various numbers of cores and fractions of parallel execution of the overall execution time are probably the most interesting part of the article. For example, the first result reported is that to achieve the highest Perf/W value in the multi-core model, the parallelization must scale linearly. If the application doesn't scale linearly,the processor (model) must dissipate more energy than the serial version since the idle power of the extra cores scales linearly.

The ultimate result of the paper was that the hybrid model, one large core and many small cores, was the most power scalable. The manycore option does well with high amounts of parallelism and lower power budgets (fewer total cores), but as that budget increases, the number of simple cores increases and the effective serial execution performance does not. The hybrid model, with the single large core in place of several simpler cores, can more efficiently handle the serial portions of the execution (than one simple core out of the dozens sitting idle).

As I was reading the paper I could identify which was the model of current standard multi-core processors available in abundance today. The manycore model could easily be a GPU or MIC accelerator by itself. The hybrid model suggested the combination of a manycore accelerator and a dual-core processor (in the absence of  heterogeneous core chips). I wondered where vector hardware fits into the three models. Considering just the vector registers alone might suggest it would be an instance of the manycore model. However, these registers are part of a larger core, which makes me think of the hybrid model. Maybe they are a second level of parallel execution that isn't accounted for in the three models.

It's a good paper. But I have a couple of quibbles. First, the only way that parallel execution on the multi-core model underachieves the serial equivalent execution is if the sequential code is run on a single core system. A later comment in the paper makes me think that this is the assumption, but it's not too clear. This assumption is not valid in the real-world. For a true apples-apples comparison, the serial code needs to be run on a multi-core processor, too. If that were the case, I contend that the parallel execution consumes less energy.

For example, assume that we have an execution time of 10 time units (let's call them moops) . On a quad core processor running the serial code we would have one core running full speed for 10 moops and the other three cores generate an aggregate 30 moops of idle consumption. If the algorithm is 50% parallel, we would have 5 moops of  full power consumption in serial, 5 moops of full consumption in parallel across four cores, and 15 moops total of idle consumption. Even if the code is 10% parallel there would only be 27 moops of total idle consumption. Any level of (perfect) parallelism is going to prove to consume less energy than the serial equivalent on the same system. Am I missing something?

Note that I included '(perfect)' at the end of the previous paragraph. There will always be overhead in parallel computations and this will expand the execution time of the parallel portions and, consequently, the full consumption time of the execution (e.g., the 50% parallel portion above might require 5.4 moops of full consumption).

Second, Amdahl's Law is an estimate of speedup. Speedup is a dimensionless number. That is, I divide the execution time of the serial code with the time of the parallel execution to get a simple  number since the moops of the two quantities cancel each other out in that calculation. If I need 10 moops of serial time versus 6.35 moops of parallel time, I get a 1.57X speedup. 1.57 whats? ('X' is not a unit.) Speedup is a metric of relative performance, but it's not what I really think of when I think of performance.

To me "performance" is more absolute. Typically this is some countable quantity like number of transactions, floating-point operations, or feet traveled. It can be associated within a time unit measure, too, like transactions per moop, floating-point operations per second, or furlongs per fortnight. Thus, the metrics of transactions per watt or flops per watt or feet per watt make sense to me. Improvements that raise the performance value or lower the watt value show a trend in the right direction for achieving better energy efficient performance.

I'm still not able to quite wrap my head around the efficacy of speedup per watt (or even speedup per joule, which is also used in the Woo and Lee paper) as an absolute measure of energy efficient performance. It may be that I'm reading too much into this and the metrics are simply used to compare the three architectural models described (within the assumptions given). Perhaps it is simpy just a model after all.

There are all kinds of ideas to be found on the Power Efficiency Community site on how to accomplish this assignment. What I'd like to know is how you prove to your boss that you have accomplished the task. Or, if you've already optimized the you-know-what out of the application, what do you measure to label your software is energy efficient?

With serial applications, the metric of better performance is easy: less time is better.  Parallel applications have similar metrics: either run the same workload in less time than an equivalent serial version or run more workloads than the serial code can process in the same time.

I've found that energy efficiency is a little more nebulous. Talking with engineers that deal with this question around Intel, I've gotten three potential answers.

Total Energy Consumed

This is simply the amount of energy used during the run of your application or an average of energy used per time unit (since the needs of the application might fluctuate based on the processing done). Certainly the less total energy used, the more efficient your application will be. On laptops and Ultrabooks and other mobile devices, applications that use less energy will preserve battery life.

But, how much energy does the application NOT have to use to be considered efficient? Is there a minimum achievable level of energy consumption for a given computation? When do you know that there is no more efficiency that can be squeezed from your tuning efforts? With parallel computation we have Amdahl's Law and other theoretical models that can be used to compute an upper bound on the amount of parallelism we might be able to eke out of an application. Is there a similar model for energy efficient performance limits?

Performance per Watt

This measures how much work is done per watt of power. Clearly, if your optimizations result in more work done with the same amount of energy used or the same computation with less energy expended, your application is more efficient than it was before. Most applications will have some easy metric of performance. Things like FLOP/s or pixels rendered or transactions processed or frames per second are all common measures of the work being done in applications.

Again, a relative measure of before and after is easy to keep track of during the tuning process. If your application starts with 10 FAUXtoe-ops per watt and eventually reaches 20 FAUXtoe-ops per watt, your tuning efforts are headed in the right direction. As with the previous measure, I wonder if there is an absolute (theoretical?) value that can be held up as the goal of your optimization efforts? Dependent on what work unit your application uses, of course. And would such an energy efficiency measure need to take into account the target hardware configuration (battery, power supply, processor, chipset, GPU, etc.)?

Application Idle Behavior

One idea that I find repeated over and over is that the processor should be kept idle as much as possible. That is, it should reside in the lowest C-state as much as possible. For an application, this rule of thumb can be summarized with the acronym HUGI (Hurry Up and Get Idle). Do whatever is needed to complete any processing as quickly as possible and then have the application sit idle (and do that as energy efficiently as possible). Thus, the measure is to determine how well an application spends time waiting for user input or some other interrupt.

Judging how efficiently an application executes during its idle time will be as simple as measuring the percentage of low C-states (C3, C6) residency. This metric can be an absolute percentage of execution time or measured relative to the idle state of the system without any other application running, i.e., the quiescent state of the OS. Sounds good for user-interactive applications that can run faster than the user can type or click, but what about heavily compute-intensive executions? When I ran a version of my Akari application, less than 3% of the time was spent in C3 while achieving a 22.56X speedup on 80 threads. With all the parallel tasks that get spawned to inhabit all the threads/cores available, should that application be considered energy efficient?

What do you think?

So, when you read the first two paragraphs, did you think of any of the metrics I outlined here? Maybe it was some variation on a theme or did you have a completely different idea?

Performance was, is, and always will be the driver of the need for software tuning and optimization. Would there ever be a trade-off of lower performance (longer execution time) in order to conserve energy consumed? Perhaps a question for a future blog. For now, though, assuming a preservation or improvement of application performance is a requirement, how do you demonstrate that your application is also efficient in the energy used during execution?

Upon receiving the corks, Tom would demonstrate his "cork trick" and mystify everyone that had not seen it before. After going through it three or four times he would hand the corks back to our server and have them try to do it. They would go away, sometimes showing others, as they struggled to figure out the trick. If they actually tried to recreate the solution as Tom had been able to do, they always came back before we had paid the check and triumphantly demonstrated their dexterity.

At SC11, the Educational Alliance for a Parallel Future (EAPF) commissioned some corks with the organization's logo. Tom wandered around part of the conference urging attendees to try his cork trick. The tagline he used was that "Parallel Programming is easier than the cork trick." You can see a short video of his efforts to bring a little magic to the SC11 proceedings here.

If you meet Tom with some corks in his pocket and he brings them out to show you the cork trick, be aware that he will never show you the solution. (He says he really likes me, but I had to figure it out for myself.) Like most problems you encounter in life, very few are impossible to solve; it is just that you don't have a solution, yet.

Parallel programming is the same. It may seem difficult and impossible to figure out, but that only means you haven't discovered the key that will allow you to wrap your brain around the concepts.

When I first saw commercials for the Apple iPhone S and Siri, I thought it must have been a recreation of the technology to get market buzz. When I figured out the scenes were portraits of reality, I took notice and marvelled at such a cool feature.

Today, I read some speculative articles and rumors about Google getting ready to release their competitive product, Majel. This is named after Majel Barrett-Rodenberry who provided the voice of the computer in Star Trek and Star Trek: The Next Generation. Beyond the appropriate name, I was thinking "Ho hum, another voice activated search tool."

Then I read some of the "details" published on the androidandme.com site. The most interesting point for me is in the second-to-last paragraph attributed to "anonymous Googler" touting the reasons for higher expected performance of Majel over normal speech recognition: "...mostly because of the use of high quality microphones and lip-reading assistance." [Emphasis is mine]

Regardless of whether or not this turns out to be true, it's one of those cool Star Trek technology ideas! Being able to read lips with a handheld device would  have so many benefits and uses.

Being able to understand spoken commands more reliably by the device is good and functional. Why couldn't you turn the camera outward to act as an aid to the hearing-impaired? This seems like it would be a great help for older citizens that have lost their hearing or when encountering people that do not know how to sign.  I hold my device so that it can see the speaker's face when they talk and a transcript of their words appears on the screen facing me. Maybe even translating from their language to mine?

And I haven't even had time to think about all the James Bond uses for such portable technology. All football coaches will need a clipboard to cover their mouths when calling in plays to keep fans or spies from the other team being able to discern what they say.

What's next?

• Facial recognition? If I'm at a party and I want to be sure to meet someone that I've not met, I could put in some pictures, have my device stuck in my pocket scanning people as I walk around the party and give me a signal when I am close to the object of my search.
• Finding separated members of your party in a crowd? If we arrange to meet at Splash Molehill at 1pm, but I can't tell if anyone else is close, I hold my device over my head and rotate slowly to scan the crowd. If anyone is recognized, I get a signal and an indication of where they are.
• Or assessing the identity and potential value of objects in a previously locked room? (My wife and I have become fans of Storage Wars.) It would be cool if a device can scan a room, postulate the identity of items that can be seen and render a value of those objects from Interwebs search.

I may not be getting a smartphone anytime soon (or ever), but I'm still fascinated by what technology is being built into handheld devices that even 5 year ago seemed to require much more computational power than  you could hold in the palm of your hand.

I want to thank Kathy Farrel for all her hard work in organizing and taking the lead on the last 40 shows. She had some fresh ideas during our collaboration and I enjoyed working with her. Kathy was taking on the role of Parallel Programming Community Manager and it seemed like she was asking me at least one question every day about the subject.  She started out a bit camera shy and tongue-tied. But she made steady improvement, started to explore parallel programming topics on her own, and soon got comfortable with the hosting duties. I am impressed with her drive and tenacity. She will do more great things in her new role.

Aaron Tersteeg deserves a big "Thank You" for developing Parallel Programming Talk back in 2008, first on blogtalkradio and then as an Intel Software Network web video show. When he first approached me about participating, he described it as "Car Talk" but focused around parallel programming topics. We tried to keep things both informal and informative. I was relegated to Aaron's monitor when we started the video shows (as he is in Oregon and I am in Illinois), which led to some light-hearted moments, some accidents, and some experimentation as we played with this restriction.

(My favorite anecdote from the early video days was when Aaron ran into a fan of the show at a Portland Trailblazers game. The fan knew he looked familiar and then asked if he was Clay Breshears.)

The production crew will always have my undying respect and appreciation. Jerry Makare and Josh Bancroft ushered the video era into existence and have always driven the technology and production values to deliver a higher quality product. They were always up for a challenge and conquered many of them during the show's run. I also appreciate all the work that the video production interns--Chris Davis and Anthony Lopez--did for the show. They worked tirelessly behind the scenes moving, setting up, and tearing down equipment, they did some of the editing chores, and they were always great fun during those rare times I was in town for a live shoot.

And finally, I want to thank the fans and casual viewers of the show. Thank you for all your support, questions, and comments. Without you we would have shut down soon after we started. During my tenure as co-host of Parallel Programming Talk, I got to meet some of the superstars of the field, got to hear more about cool parallel languages and approaches to parallel programming, and got to see some cool tools that are useful in making parallel programming, debugging and tuning much easier. I hope that you enjoyed hearing from the experts and finding out about new technology at least half as much as I did.

Keep writing parallel code and be good to each other.

But what really caught my imagination was the first section of Chapter 7, "Programming Languages," that briefly described the Quantum Random Access Machine (QRAM) model of quantum computation. In addition to the few paragraphs that were devoted to this model, there was a picture that showed the relationship of a classic computer to a quantum computing device. Each part was simply a box with data/instructions passed from the classic to the quantum and data (results) passed from quantum to the classic side.

This setup looked familiar and it came to me during my cool down: this is how a system equipped with MIC would work. That is, your Intel Core processor does some initial computation to set up data, the data is passed over to the MIC (along with the computation instructions to be executed), and the results from the MIC can be returned to the Core side for use.

I know that MIC processors (and other GPU-like devices) don't have the same computational power as a quantum processor could have. However, the data-parallel and SIMD execution modes are similar to how a quantum device could take a superposition of all potential input data and execute a single computation step to arrive at a measurable result. This similarity got me thinking that MIC devices could be the first steps taken by the industry to better understand, prepare for and program effective quantum computations.

I don't know if we will ever see commodity quantum computation devices. I doubt they'll be developed within my lifetime, at least. Even so, I am nothing short of astounded when I look back at how far computer technology has come since I wrote my first COBOL program on an IBM mainframe. 

Knowing I should "never say never," how about on the day after I get my qPad(TM) quantum tablet device, I come back and comment on this blog post to say I was mistaken about how quickly quantum computation entered our lives? If it's anywhere in the cloud-o-sphere (and you know once these bits get pushed out, they never go away), I'll find it with the qSearch app, which will be based on the algorithm outlined in section 6.4 of Yanofsky's and Mannucci's book.

No, it was the fact that Gordon is the world's first supercomputer that uses flash memory instead of disk drives. This is the world’s largest thumb drive (300 Terabytes across 1024 Intel 710 series drives), as Allan Snavely, SDSC Associate Director, noted. There are quite a few advantages for using flash memory drives in place of spinning disks including lower power consumption, lower latency to access data, and fewer moving parts that can have mechanical failure. This just seems so logical that I'm surprised it hadn't happened sooner.

On a coincidental note, I saw a report earlier today that stated Intel was lowering Q4 revenue projections due to a drop in microprocessor demand from PC manufacturers. This is a direct result of not having enough disk drives available, which was caused by flooding in Thailand earlier this year.

I would think that the expected hard drive shortage will open the doors for wider adoption of SSD drives in the PC market and provide a hefty revenue stream for companies that can supply those drives. Big-scale projects like SCSD's Gordon computer just reinforce the efficacy of SSDs in desktops and laptops and even smaller form factors.

The author with a printed edition of the Intel Guide For Developing Multithreaded Applications

Okay, so it's not something that I would promote as "New & Improved"  with big splashy TV commercials, like some laundry detergent or kids' sugary drink. I would be more likely to skip the trumpets and play a fanfare on a kazoo instead. Even so, I'm excited to announce that the Intel Guide for Developing Multithreaded Applications has been updated.

Many of the articles featured in the Guide remain as relevant to parallel programmers today as they did when the Guide was first put together. Good parallel progarmming practice will always be good parallel programming practice. Even so, technology  tools are changing at a steady pace, and we know that the Guide needs to keep up with those changes. To that end we've added three new articles and revised two others.

The revised articles illustrate some new features of Intel software tools. The article "Getting Code Ready for Parallel Execution with Intel® Parallel Composer" has added explanations of new features and new programming libraries supported by the Intel® Parallel Composer compiler. "Using Intel® Inspector XE 2011 to Find Data Races in Multithreaded Code" updates how to use the latest version of the thread debugging tool.

One of the new articles also deals with Intel software tools. "Optimize Data Structures and Memory Access Patterns to Improve Data Locality" poses a tricky parallel performance issue. Intel® VTune™ Amplifier XE is used to not only detect the problem, but the tool gives users some low-level analysis option to diagnose the root-cause of the problem. The article illustrates a methodology to delve deeper into parallel code to identify and correct bottlenecks to scalability and performance.

Vector computation has been a staple of parallelism for many decades. The second new article, "Using AVX Without Writing AVX Code" shows how programmers can take advantage of the new vector hardware units and AVX instructions without needing to go down to the assembly language level of coding. For viewers of Parallel Programming Talk this might sound familiar. Our guest for show #114was Richard Hubbard who talked about this exact topic. We felt it was something parallel programmers would want to know about, so Richard and Eric Palmer (Intel) wrote it up for the Guide.

The topic of the third new article, "Optimizing Applications for NUMA " was also featured on Parallel Programming Talk. David Ott appeared in show #113 to tell us about NUMA architecture and how best to program for NUMA. If you have never heard of NUMA or if you have, but have been unsure about what you need to be doing to get the best performance from your applications, then David's article is an excellent place to start.

Even if you've read articles from the Guide before this, you might find something you can apply to your own work in the new articles. This isn't the last revision we'll make to the Guide, of course. I've got some ideas for topics that I'm sure will find their way into the collection. Future articles may be inserted without much hoopla, so check back periodically to see if we've added something new.

If you have a topic that you think should be featured in the Guide, let me know. We are always interested in delivering what readers and parallel programming practitioners want to know more about.

I was in Portland, OR, for an internal Intel conference. Before the meeting got started, I arrived early and decided to browse Powell's Books. The technical store's location has changed and the name seems to now be Powell's #2, so I wanted to see what that was like.

Imagine my delight to find two copies of The Art of Concurrency on the shelf. As I pulled one off the shelf, I glanced at the back and got very sad. The copy I held in my hand was used. Someone had bought the book and then gave it up. The other copy was also a used version.

My wife tried to cheer me up when I told her about it. Powell's Books must still see some value in selling my book. She pointed out that I didn't find these copies in the FREE box.

Yet.

Maybe it's time to start writing a new book.

The brainchild of (US programmer) Jesse Anderson, a few million virtual monkeys are randomly spitting out nine-character strings. These strings are then compared to Shakespeare's work for matches. If the string appears anywhere within the Bard's catalog (punctuation and spaces are ignored for ease of comparison), then the string is a success.

Initially started on the Amazon EC2 cloud, the project has been moved to a home PC. (At almost $20 per day in computation time expenses, I'd want a more economical option, too.) I hope Mr. Anderson has a multi-core processor since, according to the report, there are "5.5 trillion different combinations of any nine characters from the English alphabet."

Of course, for me the big flaw is that there is no order to the random scribblings of the simulated simians. A set of consecutive strings something like...

rvxtobeor nottobeth atisthequ estionalp

 ...would be so much more impressive. I guess, even processing in parallel, that restriction might take a bit longer.

It's an interesting project, nonetheless. Not the kind of thing that you might give as a homework assignment, but something of an intriguing search problem with several parallel approaches (just off the top of my head).

One of the questions raised in the book was the nature of memory vs. looking up information, and whether the memorization of facts, figures, and other trivia, which is a paramount skill for Jeopardy! contestants, might soon become a lost art. Columbia University researcher Betsy Sparrow’s recent paper in Science is titled, “Google Effects on Memory: Cognitive Consequences of Having Information at Our Fingertips.” It found that humans tend to not remember facts if they know that they will be able to look them up when needed.

Yesterday morning, while eating my breakfast, I saw a commercial on the Game Show Network for their new audience participation game entitled "A Google a Day." Participants are practically berated to look up the answer to a trivia question rather than knowing the answer. This is just sad.

I grew up watching Jeopardy! with host Art Fleming. I like trivia-based question-and-answer game shows. You can play along to test your own knowledge before the answer is revealed. Will the next breed of game shows have three contestants, each armed with their own smart-phone, vying to see who can look up the answer to a question before the others? How do I play along at home with that? Should I just record the show and pause it after the question is posed to give my slower Internet connection time to bring me back possible solutions?

The slide into total reliance on technology for recall of facts may not be stoppable. The Columbia study points to changes in how we now relate to our collected bodies of knowledge. Watson is a technical marvel that will redefine how we navigate a myriad of information and data in search of solutions to questions beyond the simple regurgitation of facts. Charles Stross postulates a near future where we record everything we see and experience into personal data storage units (Accelerando, Halting State) and we really don't need to actively remember anything (except how to access our external memory units).

The need for new and bigger memory packages and the processing power to run, populate, index, and search them will be good for companies like Intel. Personally, I'm going to miss demonstrating that I know the first US president born in a hospital, Doc Savage's assistants and their specialties, and the more common name for a dactylogram, in lieu of having faster fingers to query an electronic repository.

A bonus portion of the lab was the opportunity to run the Intel® PBB lab code on the Intel® Many Integrated Core Architecture (Intel® MIC). After testing one of the programming models, a select few went the extra mile and learned how easy it was (little or no code changes required) to port specified computations over to an Intel® MIC-enabled platform.

The other big part of the lab was a contest to win an Internet TV for putting together a video or written statement about how the programming model tested would benefit the participant in their daily work. A panel of judges looked over the entries that came in and awarded a prize to one contestant from each of the four lab choices. The winners are:

Intel® Array Building Blocks: Dick Brown

Intel® Cilk Plus: Tom Ratcliffe

Intel® Threading Building Blocks: Emmanuel Lopez

Intel® Many Integrated Core Architecture: Joe Dougherty

Congratulations to all of the winners! And a big "Thank You" for all the other lab/contest participants. I hope you got something out of your chance to test some of the PBB programming models (even if it wasn't a big prize).