Project List

This is the project list for Google Summer of Code with Chapel. The list is constantly growing and evolving, but it should remain relatively static during the Google Summer of Code application phase.

Note

If you are interested in applying for Chapel’s Google Summer of Code 2017, please visit the application instructions page:

• Steps to Apply

Student Submitted Projects

The project ideas in this list have been compiled by Chapel developers. Students may submit proposals based on existing ideas here or new ideas altogether.

Libraries and Applications

Your favorite application or library in Chapel

Description:

Build any application in Chapel that might show off its productivity, performance, and/or elegance. This could be anything from a port of an email client library to a standalone molecular dynamics engine. The world is your oyster, and we’re excited to mentor you along the way to building your application in Chapel.

Expected results:  

Expectations will be tuned specifically to the project. In a general sense, the application or library should reach a state that is ready for public use.

Optional knowledge:  

• Chapel

Mentor(s):

Andrea Francesco Iuorio, Ben Albrecht, Engin Kayraklioglu, Michael Ferguson

HDF5 Library

Description:

HDF5 (note: not HDFS) is a common data interchange format for scientific applications. Since Chapel is intended to work well for scientific programming, having HDF5 support is important.

Expected results:  

• a new HDF5 Chapel module that enables high-level access to HDF5 files
• a Chapel application that demonstrates the use of the new module by reading some existing and freely available HDF5 files containing scientific data

Required knowledge:  

Some form of background in scientific computing.

Optional knowledge:  

Knowledge of HDF5 or Chapel would be a plus.

Mentor(s):

Michael Ferguson

Cryptography Library

Description:

Implement a library that provides common cryptographic algorithms and protocols, such as those provided in OpenSSL or libsodium.

Expected results:  

A new cryptography module in Chapel that provides an interface to common algorithms and protocols, such as in OpenSSL or libsodium.

• https://www.openssl.org/
• https://download.libsodium.org/doc/

Required knowledge:  

• Experience or knowledge with cryptography

Optional knowledge:  

• Chapel
• C/C++

Mentor(s):

Andrea Francesco Iuorio

Linear Algebra Library

Description:

Chapel currently supports linear algebra through BLAS/LAPACK-wrappers. This project involves implementing a linear algebra library from the ground up, supporting distributed operations on dense and sparse matrices in native Chapel code.

Expected results:  

A new linear algebra module or extension to the existing linear algebra library, that supports some subset of the operations available in BLAS or LAPACK.

Required knowledge:  

• Strong in one or more programming languages

Optional knowledge:  

• Chapel
• Familiarity with parallelism

Mentor(s):

Engin Kayraklioglu, Ben Albrecht

Distributed Data Structures Library

Description:

Build a library of distributed data structures such as stacks, queues, linked lists, etc., and optimize the performance of their operations.

Expected results:  

A new distributed data structures module.

Required knowledge:  

• Strong in one or more programming languages

Optional knowledge:  

• Chapel
• Familiarity with parallelism

Mentor(s):

Engin Kayraklioglu

Compatibility

Chapel Online

Description:

Build a web service that compiles Chapel code online and returns the output. Alternatively, this could be done as a contribution to an existing website that supports other languages.

Some examples of this are:

• https://ideone.com/
• https://www.remoteinterview.io/online-c-compiler
• http://cpp.sh/

Expected results:  

A web service that compiles and runs Chapel code online.

Required knowledge:  

• Bash
• HTML
• CSS
• Javascript

Optional knowledge:  

• Chapel
• Any libraries or frameworks that you might utilize, e.g. Node.js

Mentor(s):

Ben Albrecht

Jupyter kernel for Chapel

Description:

Currently, the Chapel interpreter is in its early infancy. We fully expect to contribute a Jupyter kernel with our interpreted version. In the meantime, we would like to contribute a Jupyter kernel for the compiled implementation, laying the groundwork for the future interpreted Chapel kernel.

Some information and examples:

• http://bollwyvl.github.io/jupyter.github.io/kernels/
• https://github.com/brendan-rius/jupyter-c-kernel

Expected results:  

A functioning Jupyter kernel for Chapel

Required knowledge:  

• Experience with IPython Notebook / Jupyter
• Python
• Bash

Optional knowledge:  

• ZeroMQ
• Chapel

Mentor(s):

Ben Albrecht

Compiler

Improve LLVM Support

Description:

• Take steps to make the generated LLVM IR follow best practices
• Add loop vectorization hints
• Improve type-based alias analysis metadata
• Annotate load instructions in LLVM to indicate when the load is from constant memory
• Investigate integrating Chapel with the Polly polyhedral optimizer
• Experiment with alternative alias analysis implementations, such as cfl-aa

Expected results:  

Improvements to the LLVM code generation capability of the Chapel compiler. Hopefully this also includes performance improvements for some Chapel programs compiled with --llvm.

Required knowledge:  

• C++
• LLVM

Mentor(s):

Michael Ferguson

Runtime

RCU Runtime Support

Description:

RCU (read-copy update) is a strategy for managing a data structure in a multithreaded environment. RCU has a long history of use in the linux kernel and is applicable to data structures that don’t need strong consistency guarantees. See this article for more information.

This project involves using RCU in the runtime. It can be broken into two components:

1. Closing memory leaks in privatized arrays. The Chapel implementation creates local copies of certain objects in order to optimize communication. These local copies are assigned integer values and stored in an array managed by the C runtime. Due to the potential for data races, this array is never freed, even if it is re-allocated when it needs to be larger.

2. Investigating whether or not RCU can be applied to the cache for remote data runtime component. The cache for remote data is a software cache in the Chapel runtime that caches data stored on remote locales. In some ways it is similar to the page cache in linux, which is implemented with RCU.

Expected results:  Demonstrate how RCU can be applied to the Chapel runtime. Implement improvements to privatized arrays so that they no longer leak memory. Investigate whether or not RCU is a good fit for the cache for remote data, and if it is, begin effort to adjust the implementation. Required knowledge:  Familiarity with multi-threaded programming with RCU, either in the Linux kernel or in user-space, is required. Mentor(s):Michael Ferguson

Infrastructure

Improving Testing Framework

Description:

The Chapel testing system is a key piece of technology for the Chapel developer. We use it as a harness for doing test-driven development, for performing sanity checks on code before committing it, for bug and issue tracking, and for nightly correctness and performance regression testing. This testing system is described in detail here. This project involves implementing a variety of improvements in the testing framework. Some examples include:

• Using a single test configuration file (yaml) instead of one file per configuration field.
• Deprecating util/test/sub_test, merging its functionality into util/start_test.
• Python3 support in the test framework.
• Adding a suite of unit tests for the test framework (yes, writing tests for tests).

Expected results:  

An improvement in the usability, maintenance, and functionality of the Chapel testing framework.

Required knowledge:  

• Python
• Bash

Optional knowledge:  

• Familiarity with other testing frameworks
• Perl

Mentor(s):

Ben Albrecht