User Tools

Site Tools


Sabbatical 2020 Project Narrative

Parallel to this page, I'm making notes on Rust concurrency primitives and crate libraries at concurrency_resources

Advent 2018

My sabbatical proposal for Easter term, 2020 was submitted and (eventually) approved by Dean Papillon. In December 2018 I picked up The Rust Programming Language in Austin, TX and expecting to jump-start learning Rust in preparation for the Sabbatical. As per usual, there wasn't a great deal of time for that, but having the book nearby was a nice reminder to keep the topic in my thoughts. Over the next few months, I collected resources (primarily from the WWW) and some very on-point papers suggested by Adrian Colyer over at The Morning Paper.

Advent 2019

Contacted Dr. Joel Adams at Calvin University about the plan to work up resources for systems programming in Rust. He makes an incredibly cool suggestion: test the PDC portion of these resources on Calvin's parallel computing system borg, a 24-mode Beowulf computing cluster. I had visited the year before and Joel gave me a tour of some of their more interesting computing resources, but I had not known that the Borg cluster was made available to outside researchers as part of the NSF grant that made it possible.

Joel put me in contact with Chris Wieringa, their systems guy, who was very gracious with his time and knowledge. We agreed to get back in touch early January, once everyone was back from Christmas Holidays, for setting up an account on the cluster and get Rust tools up and ready to go.

Joel also made the suggestion to develop a Rust version of the CSinParallel Patternlets module (currently versions exist for C/C++ using the MPI and OpenMP libraries, etc.) that he and others originally developed.

Month of 1/2020

A slow start! We spent the Christmas Holidays with family in Pittsburgh and Indiana, PA. Not two days after returning I was laid out by a Christmas Bug until New Year's Day (thanks a lot, Rocco!), and while I was over the worst by then it did not give up very easily. Three weeks and two doctor's visits later, it was pretty much over. But that delayed the start of my review of Chapter 6 of Dive Into Systems (which I'd agree to do a few months prior), which in turn delayed my own dive into Rust.

Week of 1/06/2020

Contacted Chris Weiringa at Calvin University on the agreed date to start the ball rolling on getting access to the Borg cluster. Chris had me all set up with an account and access instructions within a day; thanks Chris! Took some pointers from Matt Might's blog post SSH tricks to do password-less authentication and succeeded in copying over a few example systems programs (from Sasha Peters' independent study) using SCP. The Rust tools Chris set up for me worked first time! Not all programs compiled, but the tools are working as expected. [UPDATE: in the next week or so I learned enough to fix compilation errors and get these programs running]

Week of 2/03/2020

Dive Into Systems review complete and submitted. Starting a Dive Into Rust: Chapters 1-3 of the Rust Programming Language; running associated code examples; a few related programs from Rust By Example.

Week of 2/10/2020

The big dive this week was twofold: understanding the borrow-checker, the Big Feature of Rust that makes it possible for the compiler to do static checking for memory errors and simplify other kinds of resource managements, cures concurrency-related data race bugs, and just in general makes the language harder to learn (initially) but these awful errors easier to deal with; and getting a first look at various concurrency primitives, such as threads, mutexes, locks, and channels. I need to start a new page to collect concurrency resources.

In the meantime, worked on structs.

Important examples and resources from this week:

Week of 2/17/2020

Trouble: family issues are taking me to Texas this week, so I'll be traveling quite a bit, so there will be fewer updates this week, which is troubling given that the trip to Calvin is week after next.

I should be starting a code base: Link to Repository

Week of 2/24/2020

After working through the sections on concurrency (and seeing that boy howdy there's a lot of paths through there!) I'm starting on Rust versions of the CSinParallel Patternlets module using the standard threads library provided in std::thread. Here's an example of spawning a threading based on code from Rust by Example:

thread::spawn(move || -> u32 {
            // Calculate the intermediate sum of this segment:
            let result = data_segment
                        // iterate over the characters of our segment..
                        // .. convert text-characters to their number value..
                        .map(|c| c.to_digit(10).expect("should be a digit"))
                        // .. and sum the resulting iterator of numbers

The last time I taught the Data Structures course, we used a module from CSinParallel that uses concurrent data strctures in Java to implement a webcrawler. Found this Rust version recently, will look into adapting it for this work (but note, the example shown uses async modules). There's also a video.

Also, spending time watching the weather, hoping the winter weather advisory in Michigan blows through before our drive up there so that…

Week of 3/2/2020

We are in Grand Rapids, MI to visit Joel Adams and Chris Weiringa for in-depth work on Rust Patternlets and the best ways to make use of the Borg Computer Cluster in this work! Prep work involves writing modules that effectively use message-passing threads to take advantage of the many multicore processors in the cluster.

Making enough progress (and failures) that we'll be going daily for awhile…


Starting out by finding the right Patternlets for Rust. Begin at the beginning: looking at the spmd.c examples from MPI and pThreads.

And here's where the FUD regarding the borrow-checker comes into play…once you've left the realm of simple examples illustrating how ownership/borrowing work, the compiler starts harshing on the code pretty severely. Just a port of spmd.c from the MPI or pThreads section requires some radical rethinking, just to try and grab the hostname from the command line and capture it in the thread closure. So lots of reading and re-reading are in my future!

Example: I want to print out the hostname in a thread so I tried this:

    let myHostName = args[2].clone(); // make a copy of second cmd-line arg
    let numProcesses: u32 = args[1].trim().parse() // parse first cmd-line arg to an int
        .expect("Please enter a number!");
    for i in 0..numProcesses {        // spawn requested number of threads
        let handle =  thread::spawn(move || {
           println!("Greetings from thread #{} of {} on {}", 
                    i, numProcesses, myHostName); // FAILS TO COMPILE due to move of myHostName

The fact that spawn is capturing myHostName for each thread created in the loop is the problem here. When the thread completes its work, myHostName will be dropped, and that affects each other thread. Can't do it! The usual trick is to get a reference to it instead: &myHostName, but that creates a new compiler error. Huh.

Other things that don't work, and for good reason: myHostName = &args[2].clone(); either with or without a reference to myHostName. It doesn't allow a move out of the vector. Note that the String datatype does not have the Copy trait, or so the compiler tells me, so I can't just give the threads their own copy of the hostname. A little delving into the docs tells of the existence of a thread-local storage, maybe that will work.


Started out my day worrying about the extent of the Nashville tornado. Looks very bad.

Fixed all those problems from yesterday by simply not passing too much data to the thread closures, and having each thread calculate its own hostname. A little heavy, but if they get distributed onto different nodes, it makes more sense anyway.

I now have a small set of simple thread-based examples that pretty much all do the same thing. Time to diversify!

When moving examples to, I found an issue when trying to build projects that depend on the nix library - rather important to me! Tracking down similar errors, I find that either the solutions are bogus when tried here, or depend on my having a new version of Rust installed. I'll check with Chris tomorrow to see what might be done there.


Yesterday Chris solved all the Rust problems by installing version 1.41. Everything built for me just fine, and I was able to run simple thread-based executables on multiple nodes (though it isn't clear that threads are farmed out across multiple cores on each node…need to research that).

Research threadPool and the ScopePool from crossbeam a bit. Built and tested fork_join, fork_join2, spmd and spmd2. Today I improved spmd and built/tested spmd2, while setting up most of the barrier example.

Move these to the concurrency_resources page: threadPool, num_cpus::get, Threads section in Rust Cookbook.


Last day at Calvin! Let's see how many examples we can get running on borg today…

…aaaaand we now have 6 examples running on, the Patternlets 00.forkJoin, 01.forJoin2, 02.spmd, 03.spmd2, 04.barriers AND the MapReduce example from RustByExample.

Not that they take advantage of it particularly, but we can currently do the following:

  • run multithreaded programs on the head node
  • push threaded programs out to multiple compute nodes, and
  • use scripts properly with sbatch to modify now many compute nodes are used

Week of 3/9/2020

TODO: research ways to partition the work to do among the compute nodes

On this front, I've looked into 1) a comparison of rayon and OpenMP, 2) an Actor model implementation for Rust, and 3) MPI bindings through the C compiler to Rust.

TODO: find out about visualization - how can we see how the compute nodes are utilized?

TODO: make use of the num_cpus crate to determine the number of cores per node (does it give us cores? or nodes?)

TODO: check out more Rust Cookbook examples and run them using threadpool and other crates

Week of 3/16/2020

This is the first full week of Sewanee Spring Break, and as with many other institutions, the University is extending the break another week in response to the issues surrounding the COVID-19 pandemic, and preparing to teach all courses online. Faculty in particular are undergoing a number of dislocations, and even though I'm on sabbatical I am in the community and am following along as various restrictions come down, particularly on using resources on campus and access to facilities.

Psychologically, it is interesting to reflect on how all this affects my work. Basically, I've taken the week off along with the students, both to follow news events and obsessively view updates on the spread of COVID-19, and to decompress by reading fiction or viewing films. It's hard to say how long this will last. Working through Rust issues is still very much on my mind; though I've written no new code, I did look at some papers. But not too much!

Joel sent a link to a post A half-hour to learn Rust which I found interesting. At first my expectation was “I've seen all this, but it would be a good way to get a student up to speed on the basics” and then realized I wasn't even half way through and was seeing stuff new to me. The only critique so far is that several examples only make sense if you already understand the concept of ownership and the borrow-checker, but that can be supplemented.

Week of 3/23/2020

Today, it was determined the university library must close to the public. They came up with a method to continue to allow folks to check out various media, but just the idea of closing the library sets me adrift (no Raulston Listening Room, no Center for Teaching) - even though I am Very Online and have other ways to obtain materials that I MUST HAVE to weather this thing. And yet and yet and yet…it is all very psychologically curious how this depresses my work instinct.

The ACM Digital Library has a video from Applicative '16 by Steve Klobnik discussing the “History of Rust.” At first that seemed funny (Rust hit version 1.0 in 2014) but development really started around 2006. This was a good find given I've been interested in learning about the motivations for Rust for some time.

Assumed the project was started at Mozilla Research which is…not quite true. It was an open-source pet project of Grayson Hoare (who worked at Mozilla) for 4.5 years before Mozilla officially picked it up. Or so I gather from Steve's talk. The overarching goals were pretty much same then as now: memory safety, performance, concurrency protections. Originally it did have GC, but once the type system people at Mozilla got on it the GC went away and the memory safety came from the compiler.

The biggest takeaway came from the Concurrency section; here, Klobnik showed two methods of updating vector elements using threads, first using Thread primitives (thread::spawn, Arc, Mutex) and then using the crossbeam crate. My examples all use the primitives, but the crossbeam crate does some magic that enables the type system to figure out when atomic reference counts (Arcs) and mutexes are needed, and when they aren't, greatly simplifying our code. So new TODO: learn crossbeam.


The South Central regional conference of the CCSC was to be held this month, but it was cancelled. It was not the case that any work was submitted to this conference, but I had considered attending and possibly gauge interest in the topic of Rust in systems programming.


This month the Regional Board of my own conference, CCSC:SE, met and determined that the conference could not be held in November due to the host institution banning on-site meetings with off-site personnel. It was decided to push back the submission deadline (would have been this month) to July and postpone the meeting to January in the hope that the host institution would reopen by then. If not, we will hold a virtual conference.

I am still intending to propose a Rust tutorial for this conference.


Not directly related to this work, but I had intended to spend some time working with machine learning in Art/Music this summer by taking an on-line course and attending a workshop at the Eyeo Festival in Minneapolis. The Festival was canceled in late March or April, and given the events last week (and ongoing) in Minneapolis, it is a good thing the festival did not take place as planned. I expect the organizers will be turning their attention to the tasks of speaking out against the police violence in their community, clean-up, and the difficult task of healing this month.

rust/narrative.txt · Last modified: 2020/06/08 16:10 by scarl