Trip Report: SC'17

This is my first post. I plan to talk about my experiences such as conference trips, papers I read or papers I publish. This time, I will talk about the Supercomputing Conference (SC) 2017 that I attended last week at Denver. It was my first time although I follow SC for a long time. The main reason was the Early Career Workshop, organized by Dorian Arnold. Let me go day-by-day to keep this organized:

Day 0: Denver is a beautiful city and famous for the arts and cultural activities. High altitude also made me sleep easy, which was nice. SC is a big venue with more than 12K attendees and includes exhibits where many companies (and research institutes) get heavily involved. When I was getting the badge they asked me if I want to donate the conference bag to high school students, for which I am perfectly okay! We all have enough bags and this is a great way to outreach high-schools.

Day 1: There were many tutorials on Sunday. It has been a while since the last time I worked on OpenMP, so I chose to go with the OpenMP Common Core: A “Hands-On” ExplorationOpenMP is a simple but tricky way to do shared-memory programming. It is simple since there are only a few things you need to learn, and that is what the organizers actually focused on; Common Core. Tim Mattson did all the presentations and it was so much fun. He is definitely a character and an awesome teacher that made all the things went smooth. One surprising thing he mentioned was the story of the task directive. After the initial release, some company came up and asked for a kind of irregular parallelism where the threads take over works from a shared dynamic queue. In order to incorporate the irregular parallelism (as opposed to the regular loop-based), OpenMP team basically had to design and implement everything from scratch! I also had a chance to meet Barbara Chapman.

Day 2: This was the day for the Early Career Program. Organizers did a great job to introduce each person to others by pairing people where each person first had a brief chat with her partner and then introduce each other to the audience. There were two panels and a luncheon where senior researchers told about many aspects of the research business. One thing that surprised and enlightened me is that Mary Hall from the University of Utah said that she loves writing proposals since she can basically speculate about anything and it helps a lot to organize her thoughts. So, it is not all about the money. In the last session, more than 20 senior researchers did one-to-one meetings with the participants, and we get to know each other for 7-8 mins. It was really great. I had a chance to meet and introduce myself to many people that I enjoy reading their papers, like Mary Hall and Maya Gokhale  (from LLNL).

Day 3: There were a few friends in the Doctoral Showcase Sessions that I wanted to catch up. Those sessions are a great opportunity to present your thesis work to the SC community. There were tough and insistent questions as well, that gives the feeling of a defense. Another important event was the Birds of Feather session on HPC Graph Toolkits and the GraphBLAS Forum. I always wondered what do they mean by 'Birds of Feather' and it turns out to be a panel-like forum to bring people working on certain topics together. Graph BLAS is an effort to define building blocks for graph algorithms in the linear algebra language. It is initiated by the Combinatorial BLAS work of Aydin Buluc and John Gilbert. The session was more on the subject of the graph algorithms for scientific computing applications and the parallelization efforts for faster processing. There were two panels.

In the first one, people basically expressed their hate relations with MPI for the graph processing. Despite not being in this panel, Tim Mattson was the only person rooting for MPI in the room. At the end, all the discussion was converged to the question of if we really need the distributed computation for graph processing. It is actually a longstanding problem in the community that has been discussed a lot in the past. Most graphs fit in memory. Given the easy access to the machines with TBs of memory, it is really hard to motivate distributed computation, which suffers from high communication overhead due to the hard-to-partition structures of graphs. Assuming that a vertex id takes 8 bytes, 1 billion edges take 8GB in the CSR format. There exist 2TB instances in AWS, and the ones with 4 to 16TB are on the way. So, unless you have a graph with tens of trillions of edges, there is no point to think about it. The only counterexamples were the De Bruijn graphs, used in DNA sequencing, and the neural networks that might arise in the future. De Bruijn graphs are artificial networks that are constructed to model the information in short DNA sequences. They are pretty dense, as opposed to what we have in the real-world, and with the third-generation sequencing, it is possible to get much longer reads for which the De Bruijn graphs are useless. One thing that was not mentioned is the case of dynamic graphs. They are stored in a distributed fashion with mostly random hash partitioning, thus the distributed processing is unavoidable. However, the local graph algorithms are getting more popular and the need to compute anything about the entire graph is getting more questionable. So, yes, we need distributed computing when the graph is dynamic, but IMHO there is no use case that needs an analytic about the entire graph with trillions of edges. 

The other panel was about the Graph BLAS. There were some people who think it is not a feasible thing to build a community around it, and there were others who really want to build any graph algorithm in this framework. I believe it is quite important to have high-level operations that can serve as building blocks for any graph algorithm and there were some other attempts in the database community for the same purpose, as well. It will definitely ease the design and development of the fast graph algorithms, i.e., people will basically focus on improving the building blocks. It is so hard to distinguish algorithmic and engineering solutions for any graph algorithm and high-level primitives would help to address this issue. Furthermore, hardware vendors will benefit from such abstractions to tailor their processor architectures (DARPA's Hive program is all about that). However, the main concern is whether the linear algebra is the ultimate approach to get the best abstractions. For me, thinking in a combinatorial way is easier than the spectral way. It might be the other way for others. But, can we say that all graph algorithms will perform best in terms of the spectral solutions (in the language of linear algebra)? I believe any attempt to answer this question on any graph algorithm would be of great interest.

Day 4: I attended an invited talk by Judy Qiu on Wednesday. She talked about the Harp-DAAL project which enables high-performance computing in the Apache Big Data Stack (ABDS). The main idea was to discover the needs for HPC in the big data applications and incorporate the resources the speed up the pipeline. As an artifact of the project, Judy and her team released an open-source software, Harp. It is a plug-in for native Apache Hadoop, which has a convenient science interface, high-performance communication, and can invoke Intel’s Data Analytics Acceleration Library (DAAL).  The nice thing about her research was the convergence of two CS disciplines. Database and HPC communities have many common problems and mostly unaware of each other. Analogous to the inter-disciplinary research that can have a high impact on real-world problems, the convergence of the different subdisciplines in CS becomes more and more important.

Day 5: I just enjoyed the exhibits and the downtown Denver on the last day. I am especially fascinated by the Circle of Animals/Zodiac Heads, just installed last month. It is an artwork by internationally acclaimed Chinese contemporary artist Ai Weiwei and making a world tour. There are twelve animal heads, each weighs 1 ton, and the attention to details are amazing. My favorite was the Rooster.

The only thing I am frustrated in Denver was the airport. It is ridiculously far from the downtown and took more than an hour on my way back. You also have to take the train regardless and I caught my flight in the last second which left me exhausted at the end. A flight attendant comforted me by saying that I am not the first one complaining about this and told me to check the stand-up shows about DIA.