1. Introducing Every CS Major to Parallel Programming: Baby Steps at Ohio State Gagan Agrawal Feng Qin P. Sadayappan

2. Context Ohio State Moving to Semester System in 2012 o A very significant exercise in converting all degree programs o CS undergrad programs developed almost from scratch o All CSE and CIS undergrads will do exercises in parallelism and locality

3. This Talk o Not About o Extensive coverage of parallelism for UGs o New pedagogy of teaching parallelism o Is About o Challenges of designing a CS Curricula o (Different) view-points of colleagues o Not everyone thinks the way systems faculty does o Some other challenges in preparing students for parallelism

4. Curriculum Design Process o 10 faculty, lectures, students, advising staff o Met for 1 hour per week for about 15 weeks o Various subcommittees formed o Divide core into software, foundations, and systems o Challenging/Contentious discussions

5. Outcome o ~50 credits of CS divided into o 6 required courses o Software I and II o Systems I and II o Foundations I and II o A junior project course o A senior capstone course o 4 pick A or B pairs o 4 other elective slots

6. Primary Drivers o Larger core considered undesirable o Students should be able to take several graphics or networking courses.. o Project and Capstone considered very important o Dividing core into Software, Foundations, and Systems helped divide responsibilities o SE faculty responsible for software, systems faculty responsible for systems

7. More Details o Software I and II o Java based o Strong component-based flavor o Strong SE bent (best practices in Java etc.) o What is Missing o Any C/C++ o Pointers and memory discussion o Any performance considerations

8. Systems I and II o Systems faculty in charge of it o Input: students with no C/pointer/memory background o Desired Coverage o C programming o Micro-architecture, organization, assembly programming o Operating System Topics o Multi-core hardware and software o Processor architecture and networking …

9. Tried to Negotiate o Asked for more systems credits o Prepared a strong argument o Multi-core hardware and software very important for everyone.. o Got no traction from others o Argument that action has shifted to applications o No option but to work within 6-7 credits

10. Final Outcome (Systems Courses) o Systems I o C programming (pointers) o Computer Organization and Assembly Programming o Systems II o 10 weeks of operating systems topics o Parallel programming and locality management at software level

11. Operating Systems at Ohio State o A required quarter long course (3 quarter credits) o Covers traditional “theory” topics o Processes, Memory, Devices o Labs for o Programming with System Calls o Multi-threaded Programming o Producer Consumer Etc. o No Kernel Programming o Elective Operating Systems Lab Course o Linux Kernel Programming

12. Systems II in Semesters o Keep 10 week contents as they are o Add Multi-Core application development o Build on Pthreads and Synchronization o Focus on extracting performance from simple applications o Add application level locality management o Exposure to Caches at Application Level o Relate to VM treatment in a standard OS Course o Use Bryant and O’Hallaron for new material o Computer Systems: An Application Developer’s Perspective o Also our Text for Last 8 weeks of Systems I

13. Was It All Natural? o Many found combination of topics strange!! o But o Met our priority of material to cover o Better than Just adding more OS Topics o Locality coverage important because architecture is now an elective o The only opportunity to introduce parallelism we had

14. Other Observations from the Process o Performance low in priority outside systems o SE Practices, Testing more important o Many forces against preparing students for parallelism o No pointers/memory at early stages o Encapsulation/Components emphasized o Architecture coverage very limited o Choice with Networking

15. Other Questions o Does it make sense to teach parallelism with Java or C#? o If sequential performance is so limited, why bother with parallelism? o Should we first teach parallelism with more abstractions? o Is Pthreads too low level? o Can you really get performance just thinking of simple iterators/ map-reduce etc.?