Report outline

This page is meant as a kind of top-down report specification/disposition. It should list each of the parts/chapters/sections to be present in the report, and how they should support or illuminate the argument of the report. From this document you should be able to get an overview of the report structure.

Preface

• [Done] What does the report contain
• [Done] Who have contributed

Introduction (udskyddes til resten er lavet)

• [Done] Argue that this is a relevant field of study
• [Done] Explain our project on a high level
• [Done] Argue that this is a relevant project
• [Not done] Explain our approach
• [Done] Summarise our contributions
• [Done] Outline report structure

GPU

• [Done] GPU hardware
• [Done] GPU programming and optimizations

Cases (mangler finpudsning + diskussion af portfolio pricing)

• [Done] Introduce option pricing
• [Done] Argue that optimizing the way option pricing is performed is a relevant problem
• [Done] Introduce binomial option pricing
• [Done] Simple parallel algorithm
• [Done] CUDA algorithm for binomial pricing of portfolios
• [Done] Argue that binomial option pricing is a practically relevant case
• [Done] Introduce Longstaff & Schwartz option pricing
• [Done] Argue that Sobol sequence generation is a practically relevant case
• [Done] GPU Gems Sobol
• [Done] Sobol sequence generation
• [Done] Note on Uniform -> Normal distribution
• [Done] Least Squares
• [Not done] Portfolio pricing (Binomial)
• [Not done] Portfolio pricing Longstaff & Schwartz

Survey

Survey setup (mangler finpudsning)

• [Done] Argue for the selection of Nikola, Accelerate, Repa
• [Done] Argue for the deselection of Obsidian, Feldspar, etc.
• [Done] Argue for our chosen parameters of comparison

Evaluation of project health (mangler finpudsning og konklusion)

• [Done] Tabulation of collected metrics
• [Almost done] Discussion of collected metrics

Evaluation of performance

• [Done] Hardware description
• [Done] Presentation of implemented experiments
• [Not done] Presentation of performance data. Graphs.
• [Not done] Discussion of performance data. Give plausible explanations.
• [Not done] (Conclusion)

Evaluation of expressivity

• [Done] Discussion

  • [Done] Argue that existing Nikola & Accelerate are hampered by lack of nesting. Display it using our cases that how the programmer must work around the restriction (eg. by rewriting nested maps to use replicate and multidimensional maps in accelerate).

  • [Done] Argue for our choice of Nikola as our subject for further extensions. (eg. by deeming the Acc/Exp structure of accelerate too limiting.)

• **[Done]**Display other problems we have found:

  • [Done] Nikola: Runtime compilation errors
  • [Done] Nikola, Accelerate: Very complex types in embeddings.

• [Not done] (Maybe conclusion)

Survey conclusion

• [Done] Summarise our findings in the survey
• [Not done] List noteworthy bugs encountered in survey
• [Done] Argue that Nikola is interesting to contribute to

Nikola Extensions

Nikola Introduction

• [Done] Frontend architecture. (would be improved by explaining continuation passing monads)
• [Done] Backend architecture. (would be improved by explaining Compilable)
• [Done] Module reference

Extensions : fold, unfold, mapNest

• [Not done] Motivate the presence of fold, unfold and nested maps.
• [Not done] Describe implementation. Remark that it is still yet to be tested.
• [Not done] Evaluate by examples.

Extensions : Sequential

• [Almost done, needs pre-polishing] Present sequential. Here we should describe the sequential operator, and how it changes the execution model, and how it alleviates the problem of nested operations.
• [Not done] Discussion of implementation approaches (typed/untyped?) (This is probably going to be very short)
• [Not done] Evaluation
  • [Not done] Evaluate expressivity (and versatility) by giving examples, eg. portfolio pricer? multi-dimensional sobol.
  • (not a point in itself, but rather a predicate for the entire chapter) Remark that it still needs to be tested in practice in order to see if it actually works.

Conclusion (udskyddes)

• [Not done] Summarise contributions
• [Not done] Remark what we think should have been included/investigated/demonstrated for arriving at a more complete contribution
• [Not done] Identify future work