From baaf2d79224eb34cfc1f88b9eb4789a15ac5cef2 Mon Sep 17 00:00:00 2001 From: Francis Russell Date: Tue, 10 Apr 2012 17:56:11 +0100 Subject: [PATCH 1/1] Initial commit of slides. --- Makefile | 52 ++++++++++ presentation.tex | 259 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 311 insertions(+) create mode 100644 Makefile create mode 100644 presentation.tex diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..c73bd27 --- /dev/null +++ b/Makefile @@ -0,0 +1,52 @@ +IMAGE_FILES=$(wildcard images/*) + +SVG_FOLDER=images-svg +SVG_SOURCES=$(wildcard $(SVG_FOLDER)/*.svg) +SVG_OUTPUTS=${patsubst %.svg,%.pdf,$(SVG_SOURCES)} + +CODE_FOLDER=code +CODE_F90_TEX_FILES=${patsubst %.F90,%.tex,$(wildcard $(CODE_FOLDER)/*.F90)} +CODE_TEX_FILES=$(CODE_F90_TEX_FILES) + + +PDFLATEX_OUTPUT_LOG=pdflatex_output.log + +all: presentation.pdf + +display: presentation.pdf + xpdf presentation.pdf + +display-4up: presentation-4up.pdf + xpdf presentation-4up.pdf + +4up: presentation-4up.pdf + +presentation-4up.pdf: presentation.pdf + pdfnup --nup 2x2 --a4paper --scale 0.95 --frame true presentation.pdf -o presentation-4up.pdf + +presentation.pdf: $(IMAGE_FILES) $(SVG_OUTPUTS) $(CODE_TEX_FILES) $(wildcard *.tex *.sty) + pdflatex -draftmode presentation &&\ + while(pdflatex presentation | tee $(PDFLATEX_OUTPUT_LOG) && grep "Rerun to get cross-references right" $(PDFLATEX_OUTPUT_LOG)); do true; done &&\ + rm -f $(PDFLATEX_OUTPUT_LOG) + +clean: + rm -f *.aux *.log *.out *.pdf *.bbl *.blg *.toc *.lot *.lof *.nav *.snm \ + $(SVG_FOLDER)/*.pdf \ + $(BASIS_FUNCTIONS_FOLDER)/*.pdf \ + $(BASIS_FUNCTIONS_BUILD_STAMP) \ + $(CODE_TEX_FILES) \ + pygments.sty + +upload: presentation.pdf + rsync -C --progress presentation.pdf shell3.doc.ic.ac.uk:~/public_html/psl_onetep_presentation.pdf + +%.pdf: %.svg + inkscape -D -A $@ $< + +pygments.sty: + pygmentize -S bw -f latex > $@ + +%.tex: %.F90 + pygmentize -f latex -l fortran -o $@ $< + +.PHONY: all display clean upload 4up display-4up diff --git a/presentation.tex b/presentation.tex new file mode 100644 index 0000000..a1beb4c --- /dev/null +++ b/presentation.tex @@ -0,0 +1,259 @@ +% vim:tw=80 + +\documentclass{beamer} +\usetheme{Madrid} +\usepackage{graphicx} +\usepackage{verbatim} +\usepackage{ucs} +\usepackage{alltt} +\usepackage[utf8x]{inputenc} + +%\input{pygments.sty} + +\title[ONETEP - DSLs and GPUs]{ONETEP - Code generation from a Quantum Chemistry +DSL / GPU Parallelisation} + +\subtitle{PSL Presentation} +\author[K. Wilkinson \& F. Russell]{Karl Wilkinson \& Francis Russell \\ Joint work with Chris-Kriton Skylaris \& Paul Kelly} +\date{18/04/2012} +\institute[ICL \& Soton]{Imperial College London \& Southampton University} + +\begin{document} + +\frame{\titlepage} + +\frame{ + +\frametitle{Background} + +\begin{itemize} + +\item ONETEP is a parallel, linear scaling Fortran code for performing +quantum chemistry calculations based on density functional theory. + +\item Users of ONETEP for research want to be able to modify it to compute +new quantities with the mimimal time and effort. + +\item Developers of ONETEP want to be able to modify it to make efficient use of +new architecures (in particular GPUs) with reduced time and effort. + +\item Domain specific languages (DSLs) are a mechanism which enable both requirements +to be satisfied. + +\end{itemize} + +} + +\frame{ + +\frametitle{DSLs for Computational Science} + +\itemize{ + +\item A formal, machine-interpretable notation for specifying a problem +using a domain-oriented syntax. + +\item Allow scientists to concentrate on the problems they're solving rather +than the implementation. + +\item Reduce time and effort taken to go from decision to compute some value to +having efficient code that implements it. + +\item Allow computer scientists to work on optimised implementations without +having to understand the subtleties mathematics. + +\item Target code to multiple platforms/architectures/instruction sets via +changes to the code generator rather than the high-level description. + +} + +} + + +\frame { + +\frametitle{A Domain Specific Language for Quantum Chemistry} + +\begin{itemize} + +\item Quantum chemistry papers already describe the calculations they +use with mathematical notation. + +\item Natural candidate for modelling a domain specific language around. + +\item Current work involves construction of a compiler (the ONETEP Form +Compiler) to compile a DSL describing a quantum chemistry computation +(provisionally called the ONETEP Form Language) to a Fortran method that +compiles within the existig ONETEP code base. + +\end{itemize} + +} + +\frame{ + +\frametitle{Example: ONETEP Kinetic Energy Integral} + +To calculate the kinetic energy matrix entry $T^\text{box}_{\alpha\beta}$ at +$(\alpha, \beta)$ (in bra-ket notation): + +\begin{align} +T^\text{box}_{\alpha\beta} &= +\langle\phi_\alpha| +\hat{P}^\dagger(\alpha\beta)\hat{T}\hat{P}(\alpha\beta) +|\phi_\beta\rangle +\end{align} + +where: + +\begin{itemize} + +\item $\hat{T} = -\frac{1}{2}\nabla^2$ is the kinetic energy operator (similar to a +Laplacian). + +\item $\phi_\alpha$ and $\phi_\beta$ are atomic functions. +\item $\hat{P}$ and $\hat{P}^\dagger$ are operators to transform to and from +reciprocal space in a periodic region. + +\end{itemize} +} + +\frame[containsverbatim]{ + +\frametitle{Example: ONETEP Kinetic Energy Integral} + +We propose a syntax for writing: + +\begin{align} +T^\text{box}_{\alpha\beta} &= +\langle\phi_\alpha| +\hat{P}^\dagger(\alpha\beta)\hat{T}\hat{P}(\alpha\beta) +|\phi_\beta\rangle +\end{align} + +similar to this: + +\begin{verbatim} +kinet[alpha, beta] = inner(bra[alpha], + reciprocal(laplacian(reciprocal(fftbox(ket[beta])))*-0.5)) +\end{verbatim} + +} + +\frame[containsverbatim]{ + +\frametitle{Example: ONETEP Kinetic Energy Integral} + +The full syntax includes type declarations: + +\begin{verbatim} +Matrix kinet +FunctionSet bra, ket +Index alpha, beta +\end{verbatim} + +and glue for interfacing with ONETEP + +\begin{verbatim} +target ONETEP +kinet is SPAM3("kinet") +bra is PPDFunctionSet("bra_basis", "bras_on_grid") +ket is PPDFunctionSet("ket_basis", "kets_on_grid") +output is FortranFunction("integrals_kinetic", ["kinet", + "bras_on_grid", "bra_basis", "kets_on_grid", "ket_basis"]) +\end{verbatim} + +} + +\frame{ + +\frametitle{Implementation Challenges: Interfacing with ONETEP} + +We do not have a well-defined abstract interface to interact with ONETEP. We +have to work with existing ONETEP data structures and method definitions. + +\begin{itemize} + +\item The ONETEP data structures have been designed for performance and with +concerns specific to the ONETEP implementation. + +\item Some of the data structures used are sparse and can only be accessed +efficiently in certain ways. + +\item We need to allow for the possibility of data structures changing and/or +new data structures in future. + +\end{itemize} + +} + +\frame{ + +\frametitle{Implementation Challenges: Mapping the DSL to Code} + +The mapping of DSL expressions to code is particularly problematic for ONETEP. + +\begin{itemize} + +\item Typically we would generate a topological sort of an expression DAG, then +generate code for computing operands and evaluating operators corresponding to +that order. + +\item Due to the data structures involved, we cannot be certain we can store +arbitrary intermediate expressions. Even if we could, due to sparsity, this +would be problematic. + +\item The complexity in code generation for ONETEP lies in the fact that the +control flow of the generated code is inherently dependent on both the DSL +expression being evaluated, and the way we can access the data structures +involved. + +\item \emph{We need a compositional model for control flow.} + +\end{itemize} + +} + + +\frame{ + +\frametitle{Solution Strategy: Data-Structure Descriptors} + +We provide the code generator with an abstract description of how to iterate +efficiently over a data structure along with functions that describe how the +abstract indices we work with (spatial positions) are calculated from the data +(loop indices and other data). +\newline\newline +This allows the code generator to use the natural way to iterate over data +structures when possible, but also generate random access operations or +filtering operations when required. +\newline\newline +We adopt the idea of a producer-consumer model of expression evaluation. The +DSL compiler's task is to orchestrate the movement and indexing of data +according to the indexing constraints and granularity requirements. + +} + +\frame{ + +\frametitle{Implementation Challenges: DSL Semantics and Flexibility} + +\begin{itemize} + +\item We need well-defined semantics for every operation we might use in the +DSL. In particular, we need a type system for the expressions that can be +produced that incorporates properties such as function space. + +\item The "side-channel" information of each operand needs to be well-defined. +For example, whether subsets of some larger space possess knowledge of how they +map to the underlying space. + +\item We need a description of what types of indexing operations we need to be +able to perform. Do we want to support direct manipulation of spatial indices, +support reduction operations etc. + +\end{itemize} + +} + +\end{document} -- 2.47.3