I am working with some of the brightest folks here at Intel, our subject matter experts and architects, such as Clay Breshears, Michael Wrinn, Bob Chesebrough and Tim Mattson (amongst others).  I will also be working closely with the indomitable Wolfgang Rosenberg, manager of the Intel Academic Community. 

My job is to reach out to educators and researchers around the world, to connect them with Intel experts and to help foster development of a curriculum to educate the next generation of programmers and engineers on the newest compute platforms.

Hopefully, this blog will go a long way to opening up channels of communication 

We have a number of events and initiatives planned for this year. 

We have already started our monthly Academic Community Curriculum Webinar Series.  During these webinars, we discuss the newest curriculum topics.  It is a great way to speak directly with our course architects.  I moderate the series and I very much look forward to speaking with you there soon.

The next in the series is on May 15 on multi-core design patterns.  Please Register below.

 Register or view past event here.

------------------------------------------

We are creating quite a few short videos supporting our academic efforts.

 I'm in the process now of filming a series on threading topics with an emphasis on game development and visual computing.  So far only the first title on Optimizing for DirectX is posted, but the rest will be available soon.

Is this type of content useful?  Are there better ways to scale out our knowledge and build conversation?  I'd like to hear that from you.

 I've asked around internally as to how folks like to consume information.  As you might imagine, there were a wide-range of responses.  Tim Mattson just rolled his eyes when I started to talk about videos and webinars.  While he is a great presenter, his own preference is to just download the PowerPoint or code and have done with it.

Others, myself included, prefer a richer content set.  For me, nothing beats the immediacy of a live event.  That is one reason we have our monthly webinars.  I am also quite interested in convening smaller conversations, perhaps using something like Communicator or Live Meeting, to discuss specific topics or curriculum ideas.  Let me know by responding to this blog.

 ---------------------------------------------

Finally, I've become very interested in different forms of new media.  I'm often available on Twitter -find me as @psteinb.

I am the owner of the Intel Software Second Life Island. 

IM me on Second Life as Peretz Stine.

Check out our launch video.

Over the last year, we ran an event series on our Second Life island dedicated to engaging engineers and professionals around the world in conversation on this unique environment.  That program, sadly, is ended, but you can still view much of it here:

Are you interested in meeting on Second Life or other virtual worlds?  It can be arranged.

 Well that's enough for now -you have you orders -tell me how best to foster dialogue.  I'll be working as hard as I can, but you are the whole point.  Let's start the conversation.

Mash Maker Overview 

And two brand new ones from IDF Shanghai:

Mash Maker Demo at IDF Shanghai 

Intel Mash Maker: Mashups for the Masses IDF Shanghai Session 

We posted this session in 4 parts, be sure to click on "See Next in series" to see the whole thing.

Thanks to Josh Bancroft for making the trip for us to Shanghai, and bringing back these videos.  Granted is isn't quite like being there...

Mash Maker info is at http://mashmaker.intel.com.   And Robert Ennals is the expert to blog with.

What do you think?  Should we bring more IDF sessions to you?

Amy

It's so cool to have this interest becoming more mainstream - I can actually talk with people who play the games I play and I don't get weird looks like I'm from Mars.  Well, of course sometimes I still do - but that's because I'm a geek and not just because I play PC games.

Gamers are always so interesting to speak with since most of them build their own machines with the best & fastest components to ensure they have the ultimate gaming experience.  I have several rigs that I've built myself - my main one has an Intel® Core™2 Extreme processor (QX6700) and the performance just blows me away (and I'm not just saying that because I work at Intel!).  

Never in my wildest dreams could I have imagined how far this industry would come -- I still remember my first gaming PC (an Atari 800XL) where I played David's Midnight Magic late into the night!

Gamers - and game developers - shouldn't miss some of the cool things that Intel is offering right now for game fanatics!:

• For starters we have our "$1,000,000 Intel Make Something Unreal" contest where you can submit your mods for Unreal Tournament 3 (UT3).  I am a total noob to UT3, but one of these weekends I will try my hand at some example mods and post here in my blog for everyone to laugh at. 
• Along the same lines, we also have an Intel Crysis Mapping contest with some cool PC component prizes (Intel® processors & motherboards) and a chance to win a trip to the Crytek headquarters.
• For aspiring game developers, check out our Intel Game Demo Contest -- your game could be the next big hit that I stay up waaay too late playing!
• Just need a fix on the latest gaming news?  Make sure you check out our new Intel Game On portal.
• And finally, our in-person gaming events in the second half of this year will be loads of fun.  I hope you'll make plans to join us at SIGGRAPH and GDC Austin to say hello!

I asked Dr Dennis (Prf Emeritus CS at MIT) his thoughts on what should be taught to undergrads to prepare them for a many core future. This was a lunchtable conversation and not a true curriculum planning session - but none the less - Dr Denis did not hesitate to mention functional languages as one of the first things that should be taught. I don't think he was implying that a functional language is the magic bullet or one size fits all solution to bringing new developers to the discipline.

The reasons he articulted for teaching a functional language are that:
1) it is a model for parallel prgramming that avoids the sunchroonization hazards associated with threading - data races etc.
2) version of parallel languages are already being taught in many schools already so there s a low barrier to entry
3) Examples of functional languages can already be found in industry

I would argue that there will still be a need to teach students about threading (but not with as high a priority). If you teach them about threading, you have to teach them about the associated hazards. This does not contradict that we should also teach them a functional language.

On other fronts here at IPDPS I talked to Keshav Pingali from the University of Texas, and Vivek Sarkar from Rice University who were panelists here Wednesday night. These panelists discussed how the current parallel computation community could pass their learnings on to a new generation of develpoers just starting out in multicore. After the panel discussion, Michael Wrinn & I were able to get their take on essentially the same question I asked of Dr Dennis. They indicated that there still is some value in teaching functional programming to the new crop of developers. Keshav in particular indicated that his early exposure to functional languages has influenced his coding style in positive ways - years later. They acknowledged that some implentations of functional languages have been poor performers on sequential machines in the past and so they have not really caught on in industry (Erlang is the excetion to this statement) and also they cited some difficulties with cache locality & dealing with multidmensional arrays from a developers perspective. However, they also indicated that several groups have been adding extensions to these lanuages, I think Haskell was mentioned, to allow for improved handling of arrays and to address locaility issues.

So here are my musings after havng these discussions. Warning controvesial road ahead - use caution when entering - Here's a controversial perspective on appropriateness of functional languages as we move into many core land. Maybe the locaility issues that caused functional languages to be discounted wont be so significant in a time when we are utilizing hundreds of cores. Why? In sequential programming days and in early days of multicore - 2 cores could possibily give you a 2X speedup. But the tax we pay for poor cache locality might be hypothetically ~10X - the number thrown around here in our conversations with these disinguished professors from Texas. So any language that could gain you 2X by parallelism - but lose you 10X thru poor locality probably would die a natural death. BUT - improve cache locality fo these languages and apply to many more cores. Suppose in future we have 100 cores and that compilers for the functional languages get a second look and get needed optimizations so that we reduce cache locality issues to be a 50% penalty rather than 10X (50% penalty means we run at 1.5X speedup). Now assume that we approach 100X due to parallelism but pay 1.5X tax. Thats a net gain ~66X speedup. Compiler writers might be persuaded to optimize a functional language if there was a decent pay off. 66X might do it. If the industry had frozen in a past instant of time at only 2 cores and if compiler writers at that time thought that they might be able to reduce locality penalty to 50% would it have been a worthwhile endeavor? 2X gain/1.5X loss 1.3X net - that a 30% gain in performance - not so clear that compiler writers would be enthusiastic to do all the work required because the potential pay off would not be that large. But maybe for 66X gain thay may consider it.

Caveat - I know I am assuming no overhead here and we likley wont scale perfectly or anywhere near it at 100 cores etc. But if there are no synchronization hazards - and we reduce the locality penalties maybe these things will scale better than we imagine - does anyone have a quantitaive way to address this? Quick - can someone whip out an equation from Hannesy & Patterson?

My point is that perhaps we should keep an open mind ot the possiblity of functional languages and hope that the "economy scale" and clever compiler writers might be able to bring a solution. The payoff ultimately would be fundamentally easier approaches to parallelism.

Who knows?

bobc

Share your experiences and feedback with us. Blog and tell us what you think.

Be it your opinion on the need for threading applications, or the benefits of parallel programming or your feedback on Intel® AVX (Intel® Advanced Vector Extensions) or the contests on Intel® Software Network… Are you ready for the Threading Challenge? Or is the Game Demo Contest your calling?

Blog and tell us all about it now!

I had the privilege of discussing the future of parallel programming with a number of distinguished luminaries in parallel computing! The topics discussed in side hall discussions and informal lunch table chats were varied and dynamic. Given that this is the first day of the conference for the broader set of technical sessions (the NSF track actually started on Sunday) I have no doubt that there will be more intersting discussions throughout the rest of the week. Let me start my recap of the conference with one lunchtime discussion I had on day one.

Today I had the privilege of talking to Jack Dennis, Professor Emeritus of Computer Science and Engineering at MIT. Over cold cut sandwiches and iced-tea, we had two very interesting discussions. The first regards Professor Dennis’ Fresh Breeze Project at MIT and the second regards his view of how to prepare undergraduate students for the many core world we are now entering.

Fresh Breeze is multi-core chip design which supports composable parallel programming. Composable means that parallel programs should be able to be used as components in still larger parallel programs without a lot of fuss and without a detailed knowledge of the implementation details of the smaller parallel program. Composable in this context implies that resources, such as processor allocation & memory, should be flexible and able to be reassigned according to the current needs of computations. This project adheres to six important principles for supporting modular software construction with a view towards composability of parallel programs:

1. Information Hiding Principle: The user of a module must not need to know anything about the internal mechanism of the module to make effective use of it.
2. Invariant Behavior Principle: The functional behavior of a module must be independent of the site or context from which it is invoked.
3. Data Generality Principle: The interface to a module must be capable of passing any data object an application may require.
4. Secure Arguments Principle: The interface to a module must not allow side-effects on arguments supplied to the interface.
5. Recursive Construction Principle: A program constructed from modules must be usable as a component in building larger programs or modules.
6. System Resource Management Principle: Resource management for program modules must be performed by the computer system and not by individual program modules.

Professor Dennis holds that his new multi-core design would be key to building modular parallel programs. For more details – see Prof Dennis’ website - http://csg.csail.mit.edu/Users/dennis/.

The second topic we bantered around the table was how academia could prepare undergraduate CS students for the burgeoning parallel computational world that has been thrust upon them (and us). On this topic – I asked Professor Dennis this question – "If there were a handful of changes that academia could make to prepare undergraduates for this many core transition – what would they be"? This was his response:

1. Teach undergraduates a functional language – yes functional as in LISP – which avoids synchronization hazards. MIT’s been teaching LISP for years. Another choice might be Erlang as it side steps synchronization hazards, is a simple language to learn and has been designed for high performance use in the communications industry
2. Teach undergraduates MPI as in Message passing Interface. This paradigm has been used successfully in large scale parallel programs already.
3. Give them a blended HW/SW computer architecture course, including multicore arhcitecture – expose them to cache architecture so they understand performance
4. Expose them to hazards like synchronization hazards and data races so they can avoid these hazards when they implement parallel designs
5. Revisit object oriented programming methodology, which is great for sequential programs, but is not well suited for structured parallel programming. A program can easily be written which follows OOP but can still exhibit a data race.
6. Teach students the concepts of atomicity, determinacy, and the difference between them. Atomicity is the concept that all or none of a transaction must be completed. Determinacy deals with achieving a correct result regardless of the order in which threads execute. Atomicity does not imply determinacy.

Professor Dennis – thanks for lending me your sage advice on how to steer our curriculum efforts!

So now I ask YOU!

If there were three (or five) changes that academia could make to prepare undergraduates for this many core transition – what would they be? What is YOUR response?

Bob C

There are only about 20 MIDs in the world today, all prototypes, and they were pretty much all at IDF. As you can imagine, access to them is jealously guarded, and they were pretty busy being shown off, participating in photo shoots, etc. My access to them got postponed, rescheduled, and moved around a lot, until one afternoon, we got the call. "You can come play with the MIDs if you can be here by 5:30pm." It was 5:00pm, and Welles and I jumped in a taxi right away, headed for the Intel Software group's Mobility Enabling Lab. I didn't have time to go back and get my "big boy" professional video gear, so these videos were shot on my pocket Aiptek Go-HD camera, secured by a GorillaPod. I think they turned out pretty well.

Big disclaimer: the Linux-based software for both the Lenovo and Aigo devices I used is NOT final - there are some features that aren't implemented, and performance optimizations that haven't occurred. This is NOT how they're going to be when they're released commercially. There are crashes, slowness, and missing features in these videos. Think of this as a preview of the foundations of the software - what it's capable of in general. Then squint your eyes a little and imagine the final version, a little more polished, sitting happily in your pocket.

First up, here's a 13 minute video of the Lenovo Ideapad U8 Mobile Internet Device (MID). It's one of the more unique hardware designs, with it's flared end, special limited edition Beijing 2008 Olympic color scheme, and hardware number pad, for T9 text entry. In the video, I take a detailed look at the hardware (Intel Atom processor, two cameras - the rear one is 2.0 megapixels, SD slot, GPS, USB ports, etc.), and spend some time poking around with the software/user interface:

Generally speaking, I think this is a great move for attendees as the conference will be able to deliver more focused material to attendees given their area of interest. That said however, sponsors such as Intel Corporation must determine if they will have a presence at one or both of the events, and if they determine they'll be there for both then it obviously will be more expensive for them.

The developers conference this year will feature 16 tracks and the session catalog currently includes 635 sessions.

Whether you'll be attending or not, you might consider visiting Virtual TechEd 2008 which will add content as the conference draws near and also during the conference itself.

If you are a developer using Microsoft technologies then this is without a doubt a conference you should attend, and once you've attended you'll want to go again and again.

I’m putting together a talk this week that I will be delivering at CommunityOne in San Francisco on May 5 on some of the work we’re doing to support Intel-based kit with OpenSolaris. It’s great to talk about the accomplishments of many people, and how developers can take advantage of them.

For example, I’m sharing some photos I just took in our lab showing the test jig we use to determine how well OpenSolaris manages power across the breadth of components in the platform. We’re able to determine a number of data points for power use, not just CPU. It should be interesting to share the data. (By the way, I'm indebted to the hard work of engineers here in our Open Source Technology Center for the great job they are doing to set this up and maintain it!)

Perhaps more interesting though is to frame up the challenges as I see them in the future for OpenSolaris. As a matter of fact, I think a lot of my job rests on the simple challenge of identifying and solving problems. I actually love it when folks bring me a problem and they need my help to resolve! (Of course, it wouldn't be good if I solved all of the ones they could solve themselves.)

And as a community project, the OpenSolaris project now has a lot of eyes open to the successes as well as the issues. So I’m hoping we can move as a community to take the challenges head on. And I’m happy to be a part of the solution.

By the way, if you are planning to come to CommunityOne, I hope you will stop by my talk and introduce yourself.