Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
3 changes: 3 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -37,5 +37,8 @@
# Build Outputs
**/build/*

# Book Build
book

# Misc.
*:Zone.Identifier
87 changes: 87 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,87 @@
# Contributing

Thank you for taking the time to contribute.
Any and all contributions are always very much appreciated. However, to make sure the process of accepting patches goes for everyone (especially for the maintainer), you should try to follow these few simple guidelines when you contribute:

## Prerequisites

1. [rustup](https://www.rust-lang.org/tools/install) - for the Rust compiler and Cargo
2. [mdBook](https://rust-lang.github.io/mdBook/) - Book generation tool

## Steps to Contribute

1. Fork the repository.
2. Create a new branch based on the `dev` branch (`git checkout -b <your_branch> dev`).
If your contribution is a bug fix, you should name your branch `bugfix/xxx`;
for a feature, it should be `feature/xxx` etc. Otherwise, just use your good
judgment. Consistent naming of branches is appreciated since it makes the
output of `git branch` easier to understand with a single glance.
3. Do your modifications on that branch.
4. Make sure your modifications did not break anything by building and verifying the output using:

```sh
mdbook serve --open
```

5. Commit your changes. Your commit message should start with a one line
short description of the modifications, with the details and explanations
of your modifications following in subsequent paragraphs or bullet points. If you address an issue, create a subtitle with the issues number and title followed by the changes involved in resolving the issue.
Please limit your lines to about 78 characters in commit messages, since
it makes the output easier to read in `git log`. Also, starting your commit
message with a tag describing the nature of the commit is nice, since it
makes the commit history easier to skim through. For commits that do not
change any functionality (e.g. refactoring or fixing typos), the `[NFC]`
tag (No Functionality Change) can be used. Here's an example of an
acceptable commit message:

```txt
[TAG] Refactor the interface

- Rename elem to contains
- Rename subset to is_subset, and make is_subset applicable in infix notation

Issue (#12) - Add an at `at_key` method:
- Added the `at_key` method
- operator[] is now bound to at_key instead of find
```

When applicable, please squash adjacent _wip_ commits into a single _logical_ commit.
If your contribution has several logical commits, it's fine.
6. Push the changes to your fork (`git push origin <your_branch>`).
7. Open a pull request against the package's `dev` branch (not against `main`).

I will do my best to respond in a timely manner. I might discuss your patch and suggest some modifications, or I might amend your patch myself and ask you for feedback.
You will always be given proper credit.

## Style guide

Markdown uses the CommonMark style guide for the most part however, certain exceptions are allowed for customizing the style. It is a guide for a reason.

- Any code example should have a corresponding example link that is either a full file/project or a link to an external compiler (eg. Godbolt).
- Any free standing or example links that are related should be put in a bullet-list and separate unrelated links by a empty line.
- Reserve the use of quote blocks (lines beginning with `>` in Markdown) for side notes relating to content or examples

For C++ content such as examples:

- Indent using 4 spaces.
- Do not leave trailing white spaces at the end of lines, and no more than a
single newline at the end of a source file.
- A definition blocks' initial brace should start on a newline, not trail off the declaration.
- Prefer direct initialisation (`{}` over `=`) over assignment initialisation, especially for primitive types.
- Prefer brace-based initialisation for invoking a types constructor.
- Use spaces on either side of constructor arguments when using braces (eg. `int{ _ }`).
- Use `auto` as variable introducer and declare type explicitly in the brace initialiser or on right-hand-side of the assignment.
- Prefer trailing return types on functions over prefixed notation.
- Prefer to separate functions declarations (eg. `constexpr auto`), signature, constant and reference qualifiers (classes), `noexcept` specification and return type on separate lines if function declaration gets too long. Indent the constant and references qualifiers, `noexcept` specification and return type if they are on a newline.

```cxx
constexpr auto
really_long_function_signature(that_takes lots_of_arguments, with_really long_names, for_types and_arguments)
noexcept( noexcept(long_noexcept_specification) && noexcept(with_multiple_conditions) )
-> a_really_long_return_type<with_lots<of_nested>, template_type<parameters, and_metaprogramming>>
{}
```

- Indent `requires` clauses and `requires` expressions.
- `#include` should be sorted in alphabetical order.
- Mostly use your own judgment and stick to the style of the existing and surrounding code.
48 changes: 18 additions & 30 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,45 +1,33 @@
# High Performance Programming

Resources and challenges for the Monash DeepNeuron High Performance Programming Team.
This repository contains the source code for "High Performance Programming" Book. All examples, slides and content are also found in this repository. This book is available online or can be built locally and served in your browser.

## Welcome
## Building

Welcome and congratulations on joining the MDN HPP Team! We are excited to have you as a part of this team and look forward to teaching some cool technologies and ideas to you. My name is Tyler Swann and I'll be the lead educator for this workshop series. During this series you will be learning the C++ programming language along with techniques for, computer memory, algorithm intuition and parallel computing techniques.
To build this book you need [mdBook](https://rust-lang.github.io/mdBook/index.html) a tool for creating books with Markdown. mdBook can be installed using Cargo - Rust's package manager.

## About this Repository
```sh
$ cargo install mdbook
```

This repository contains the information, resources and links to help guide you through this series. Each directory will have a corresponding `README.md` file which is displayed when viewing that directory on GitHub. These files will give a synopsis of everything to do with that directory. The weekly content can be found in the `content/` directory, which has been broken down by week.
You can build this book you must clone this repository using Git. You can then build it and even serve it to localhost to view in your browser. The serve command will produce a localhost you can view.

Each week has directories for the tasks, examples and meetup slides for that week. Any other helpful information brought during meetups will be added to the `README.md` of each week. Read the information carefully and follow each step as listed. If you need help, don't hesitate to read out.
```sh
$ git clone https://github.com/MonashDeepNeuron/HPP.git
$ cd HPP

The links below can help direct you to the relevant pages.
# Build ...
$ mdbook build

## Weekly Meetups

Each week, the team will meet at Monash Clayton Campus (location, day, time etc. are TBD) were we will go through the content, tackle any issues and misunderstandings, experiment, discuss ideas and showcase things people have built.

It is expected that all team members show up for the meetups in person unless previously discussed with the management team. There will be online access and we have plans to record it for future reference but again, ideally everyone is present for the meetups.

Each week I will make an announcement containing any information regarding the weekly meetup. Meetup times and locations are expected to remain relatively consistent throughout the series. Any clashes will be dealt with in the meetup the week before and announced to all members.

## Links and External Resources

- [Content](/content/README.md)
- [Series Timeline](https://oraqlle.notion.site/4421929e24944bcfa4f3a771fb322a2b?v=d844b80fad784a7a9dcc273442b222a1)
- [cppreference](https://en.cppreference.com/w/Main_Page)
- [Compiler Explorer](https://www.godbolt.org/)
- [bpt docs](https://bpt.pizza/docs/latest/index.html)
- [Godbolt Links](/GODBOLT.md)

## Current Educators, Demonstrators and Managers

- Tyler Swann
- Nikhil Kannachel
# ... or serve build and serve locally
$ mdbook serve --open
```

## Contributors

- Tyler Swann
- Nikhil Kannachel

## Concerns
## Code of Conduct, License & Contributing

Refer to the [Code of Conduct](/CODE_OF_CONDUCT.md) and the [License](/LICENSE) for this repository for the expected behavior of contributors and users of the repository. If you have any concerns reach out to me (Tyler Swann) on Teams or follow standard MDN procedures for issues you are having within the team, branch or MDN.
Refer to the [Code of Conduct](/CODE_OF_CONDUCT.md) and the [License](/LICENSE) for this repository for the expected behavior of contributors and users of the repository. If you have any concerns reach out to me (Tyler Swann) on Teams or follow standard M procedures for issues you are having within the team, branch or MDN. If you wish to contribute, follow the [contributing guide](/CONTRIBUTING.md).
12 changes: 12 additions & 0 deletions book.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,12 @@
[book]
authors = ["Tyler Swann"]
title = "High Performance Programming"
description = "Monash DeepNeuron's High Performance Programming Curriculum"

language = "en"
multilingual = false

src = "src"

[output.html]
mathjax-support = true
19 changes: 0 additions & 19 deletions content/README.md

This file was deleted.

33 changes: 0 additions & 33 deletions content/part1/README.md

This file was deleted.

4 changes: 0 additions & 4 deletions content/part1/examples/README.md

This file was deleted.

24 changes: 0 additions & 24 deletions content/part1/slides/README.md

This file was deleted.

36 changes: 0 additions & 36 deletions content/part1/tasks/bpt.md

This file was deleted.

37 changes: 0 additions & 37 deletions content/part1/tasks/github.md

This file was deleted.

37 changes: 0 additions & 37 deletions content/part1/tasks/godbolt.md

This file was deleted.

Loading