Intel Software Network Blogs

Intel Threading Challenge 2010: One Down, Three to Go

Clay Breshears (Intel) — Tue, 31 Aug 2010 22:15:58 +0000

By Clay Breshears (Intel) (152 posts) on August 31, 2010 at 2:15 pm

The first problem in Phase 2 of the 2010 Intel Threading Challenge contest has closed. I'm very pleased that we had over 20 entries across the two problem classes from around the world. Right now the judging staff is preparing to begin compiling and running the enter applications against the chosen data sets.

The biggest change for this contest is the use of the Intel(R) Manycore Testing Lab. The shared platforms allow contestants to have access to hardware and software that is the same as that used by the judges when evaluating the entered codes. Contestants are now able to tune their entries to the exact machine specs rather than having to code "in the dark" and hope that their solution will execute well when the judges test it. For the judges, the hope is that entries will compile and run without any modifications. (In the past, working through differences in systems, libraries used, and compiler versions between the diverse set of development platforms used and the platforms used for scoring took many hours.)

As with previous problems, the clever participants were able to think beyond the scope envisioned by the judges as the problem descriptions were written up. This led to some long discussions clarifications of the original problem intentions within the ISN forums devoted to the problems. We expect it all worked out well enough for all participants. The judges have taken these discussions to heart and, hopefully, have been able to anticipate better the loopholes that might be found in the current and upcoming problems.

Best of luck to those that submitted an entry for this first problem of Phase 2. If you missed the deadline for the first problem, it is not too late to get started. The second problem has been posted and will end at noon (PDT) on 20 SEP 2010. Each problem awards prizes to the top three point total entries and the grand prize will be given to the contestant with the highest combined point total from their top three scoring entries. Go to the Threading Challenge 2010 page for details on the problems and how to enter.

Categories: Academic, Intel® Software Network 2.0, Parallel Programming

Comments (0)

Trackbacks (0)

This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read our FAQ page at fivefilters.org/content-only/faq.php
Five Filters featured article: "Peace Envoy" Blair Gets an Easy Ride in the Independent.

A Sea Change in Computer Science Education

Paul Steinberg (Intel) — Mon, 30 Aug 2010 23:39:23 +0000

By Paul Steinberg (Intel) (15 posts) on August 30, 2010 at 3:39 pm

After decades of sturm und drang over whether or not to include parallelism in the undergraduate computer science curriculum, we can announce definitively that battle is over. Parallelism is here, and it already abides.
Fortunately, we are not left staring into the abyss. Academia, Industry and Developers are cooperating to help define what the new landscape (or seascape) should look like. While the details are still coming into focus, certain aspects now dominate the discussion:

We should get beyond thinking about teaching “parallel programming” -- it’s all just programming.
Parallelism must be introduced early into the curriculum - no later than second year, and it must inform all relevant courses.
New focus must be paid to architecture - but not the same architecture we’ve been teaching for years.
Design patterns will take on increasing importance.
Parallel models are no longer in their infancy - some are mature and can be widely adopted.
Hiring managers are looking for general knowledge of parallelism more than specific tool sets.
As educators, we must prepare our students to make the decisions that industry demands - the tools, models, and patterns will lead our way forward.

Agree? Disagree? Good.
We’re going to be having a conversation about this at the IDF education panel “Navigating in a Sea of Cores” on Monday, September 13th. We have representatives from industry and from academia on the panel, and expect to have a lively discussion there continuing through lunch afterwards.

http://idfcommunity.intel.com/planner/SessionCatalog.aspx?track=(ACA).

Free passes are available to educators -Enter the code ACAWEB1 when you register.

For those of you who can’t attend, or for those who want to dry-lab the discussion, we’re also going to have a series of blog posts by some of the contributors. We’ll also be adding links to those further discussions here, so you can just check back to keep up to date!

Categories: Academic, Parallel Programming

Comments (4)

Trackbacks (1)

nulstein v2 plog - back to sequential !

Jérôme Muffat-Méridol (Intel) — Mon, 30 Aug 2010 10:03:46 +0000

By Jérôme Muffat-Méridol (Intel) (10 posts) on August 30, 2010 at 2:03 am

(note: this is slide 5 of the nulstein plog)

In an Agatha Christie novel, this slide would really go at the end of the talk, everything would finally get revealed only in the end, leaving the reader to play detective, picking up clues as the story unfolds... But that's not what I want, this slide goes here, like in a good old Columbo episode: you get to see what happened straight away, and we'll go over everything again to understand the details and make everything right again.

Having found the functional decomposition too complex for my taste, I went back a few steps, trying to split the work up along a different edge. At the time, I was looking at Google's map-reduce and also at the Larrabee rendererer, and one thing really struck me then: what Abrash describes can be seen as a system that maps triangles to tiles and then reduces these to bitmaps... And to generalize this: it is okay to break a process in sequential steps, as long as each step exhibits good parallelism.

Isn't that great: sequential is okay, after all!

This lead me to break the update in two parts: a read-only part and a write-only part. When all that gets done is reading, there is no need for locks, everybody can do it at once. When all that gets done is changing own state, again there is no contention possible and no arbitration is required. Of course, there are a few more nuts and bolts required to make this work, but here you have it: split that update in two phases, and everything can get updated in parallel much more easily.

Breaking the draw phase down is quite easy too, collect information about what everything wants to draw, sort that and do the actual render in multiple deferred render-contexts (as provided by DirectX 11). Here, it can almost be seen as straight map-reduce: a set of objects is processed to generate set of intermediate key/value pairs, which gets reduced into a set of command lists, ready to render.

The unexpected part for me, when carrying out development, was that I would still have one thread just talking to DX and very busy doing that. That's the part I was trying to kill and, as it turned out, it did survive and stop being a problem.

There are five slides before we really dive into the details of how this works, which should turn into a couple of weeks worth of blogging, so I'd like to invite everyone who is interested to start playing in their mind with the idea of two-stage update (all read and, later, all write). Look for things that don't look like they should work, look for ways to address those problems, try and see what in your game would stop working if it had to be written like that, and try to think if there would be any way to fix it. That's the great thing about making this talk a plog: you get to really think about what I present while I'm presenting it. The unfortunate thing is that our comments system seems to be down at the moment and we can't interact properly. So, if anybody wants to feedback, feel free, you can twitter @jmuffat or email jerome dot muffat dash meridol at intel dot com.

Next time, demo! : to be continued
Spoiler (slides+source code): here

Categories: Parallel Programming, Visual Computing

Comments (0)

Trackbacks (1)

Seismic Duck goes Open Source

Arch Robison (Intel) — Sun, 29 Aug 2010 03:42:29 +0000

By Arch Robison (Intel) (24 posts) on August 28, 2010 at 7:42 pm

Now you can read the source code for my Seismic Duck game on Source Forge. I open-sourced the code for several reasons:

My blogs on parallelizing it with SSE and TBB omit details of interest. The blogs chiefly concern the seismic wave propagation code in Source/Wavefield.cpp .
Games about reflection seismology are not runaway best sellers.
It's limited to Windows. I'd like to find volunteers to port it to other platforms. Mac OS is of particular interest, since it is common in educational settings. The OS-specific parts are about 600 lines of C++.

The code is my own hobby, not Intel's. As such, comments are sparse. I'll expand them as questions arise. If you are interested in porting it to new platforms, please contact me and I'll help as best I can.

Intel Software Network Blogs

Intel Threading Challenge 2010: One Down, Three to Go

By Clay Breshears (Intel) (152 posts) on August 31, 2010 at 2:15 pm

Categories: Academic, Intel® Software Network 2.0, Parallel Programming

Comments (0)

Trackbacks (0)

Leave a comment

A Sea Change in Computer Science Education

By Paul Steinberg (Intel) (15 posts) on August 30, 2010 at 3:39 pm

Categories: Academic, Parallel Programming

Comments (4)

Trackbacks (1)

Leave a comment

nulstein v2 plog - back to sequential !

By Jérôme Muffat-Méridol (Intel) (10 posts) on August 30, 2010 at 2:03 am

Categories: Parallel Programming, Visual Computing

Comments (0)

Trackbacks (1)

Leave a comment

Seismic Duck goes Open Source

By Arch Robison (Intel) (24 posts) on August 28, 2010 at 7:42 pm

Categories: Open Source, Parallel Programming, Threading Building Blocks

Comments (4)

Trackbacks (0)

Leave a comment