Click here to Skip to main content
15,885,278 members
Articles / Programming Languages / Javascript
Technical Blog

River Trail – A Commentary

Rate me:
Please Sign up or sign in to vote.
0.00/5 (No votes)
30 Oct 2012CPOL4 min read 5.2K   2  
This entry is my own commentary on Teaching Parallelism with River Trail.

This entry is my own commentary on: Teaching Parallelism with River Trail, Intel Labs, Copyright © 2012 ACM
Found here: http://www4.ncsu.edu/~efg/dcp_2012/sreeram.pdf

River Trail is billed by authors as “a gentle introduction to parallelism in JavaScript”, “the mother tongue of the web”.

Intel-RiverTrail-IDF-slide

The authors seem to believe that very there is very little effort expended by those in the web development industry to learn anything that takes more than a few minutes to comprehend.  That appears to be the reason why the authors of the paper want to help people avoid having to learn difficult threading concepts.  It is almost comical as they complain that classical parallel programming includes “hard to teach concepts such as threads, locks, memory models, data races, deadlock, and so forth.”  The paper continues with, “web developers - the audience that is mostly unfamiliar with parallel programming … often … lacks formal computer science education.”  The problem with programming, so it seems, is that developers have to learn difficult concepts.

Allow me to reflect on what I experienced this weekend at Givecamp - an event where professionals develop websites for nonprofits (for free) on one weekend.  I overheard sentiments like,

  • “I am a Wordpress expert, having developed over 20 websites with it.”
  • “The best thing I ever did was quit college so I could start learning Wordpress.”
  • “I could never learn Photoshop... that is too complicated.”

Returning then to the paper, section 3 promises to help the students write code that performs image processing functions, “such as brightening, desaturation, sepia toning, color adjustment, edge detection, sharpening” etc.  The student is then supposed to implement serial and parallel versions of these algorithms and observe the performance differences.

The above three paragraphs now need to be connected.  If web developers are unable to learn hard-to-teach concepts, unable to focus long enough for a formal education, unable to use Photoshop to perform image processing functions, then why would we think that they would be able to write code to perform image processing functions, parallel or otherwise?  In response, the authors might want to lower their expectations for this group of developers.

We can come to the same conclusion using completely different quotes from the same paper.  Consider these two:

  • “To take advantage of this new hardware we need to bring up a new generation of programmers who are fully proficient in parallel programming.” and,
  • “Classical parallel programming models enable software developers to extract maximum performance from the underlying hardware.”

If these two sentences are really true, then it follows that a fully proficient programmer should be able to extract maximum performance from the underlying hardware.  Unfortunately, this requires learning the (hard-to-teach) classical programming models.  So again, the authors need to lower their expectations of JavaScript web developers.

Onward.

Intel is a very big company and can afford to explore many technology paths in parallel (pun highlighted).  The authors will no doubt learn more than most about parallel programming as a result of creating this new product, writing their paper, and writing the tutorial.  I would hire them in an instant as developers - but never as marketers.  Therefore, I cannot criticize their effort because their goal appears unrealistic.

Technically, the explanations in sections 2 and 3 are perhaps more technical than the authors realize.  A beginner may easily get lost with sentences like, “With map, one cannot inspect neighboring values, as commonly required for convolution style codes.”  In addition, the developer may become easily confused with the Map (where the parameter are values) and Combine (where parameters are indexes).  Also confusing is the double use of the term “filter” as both 1) a method that selectively copies elements from the source to the output, and 2) an image processing term where the output is a function of the input convolved with a kernel.

Technically, I was hoping the authors might include support for the GPU, but it seems that while the GPU was mentioned in the introduction, it seems to have gotten deadlocked.  From a broader perspective, it should be clear that River Trail provides a solution to only a subset of the world of parallel programming.  There are other branches of concurrent programming that do not involve matrix manipulations:

  • One such area focuses on maintaining a responsive user interface by using separate worker threads for tasks such as data transfers and calculations.
  • Another such area involves patterns that are appropriate to writing server code that services multiple clients simultaneously.
  • Finally there are applications spanning multiple computers requiring concurrent programming techniques to solve problems in a coordinated fashion.  One recent example of this involves swarming robotics.

Despite all of this, I truly hope that River Trail encourages students to explore parallel algorithms, and maybe decide to immerse themselves into a very broad and rewarding area of study.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


Written By
Software Developer (Senior) LECO Corporation
United States United States
John Hauck has been developing software professionally since 1981, and focused on Windows-based development since 1988. For the past 17 years John has been working at LECO, a scientific laboratory instrument company, where he manages software development. John also served as the manager of software development at Zenith Data Systems, as the Vice President of software development at TechSmith, as the lead medical records developer at Instrument Makar, as the MSU student who developed the time and attendance system for Dart container, and as the high school kid who wrote the manufacturing control system at Wohlert. John loves the Lord, his wife, their three kids, and sailing on Lake Michigan.

Comments and Discussions

 
-- There are no messages in this forum --