|
735 | 735 | infrastructure, or by implementing custom
|
736 | 736 | instrumentation. Reoptimization could be applied to whole functions, or
|
737 | 737 | outlining could be used to enable optimization of portions of
|
738 |
| - functions. Re-entry into the JIT infrastructure from JIT’d code might be |
| 738 | + functions. Re-entry into the JIT infrastructure from JIT'd code might be |
739 | 739 | implemented on top of existing lazy compilation, or via a custom path.
|
740 | 740 | mentors: Vassil Vassilev, Stefan Gränitz, Lang Hames
|
741 | 741 | proposal: /assets/docs/Sunho_Kim_Proposal_2023.pdf
|
|
812 | 812 | RooFit is a toolkit for statistical modeling and fitting used by most
|
813 | 813 | experiments in particle physics. Just as data sets from next-generation
|
814 | 814 | experiments grow, processing requirements for physics analysis become
|
815 |
| - more computationally demanding, necessitating performance optimizagtions |
| 815 | + more computationally demanding, necessitating performance optimizations |
816 | 816 | for RooFit. One possibility to speed-up minimization and add stability
|
817 | 817 | is the use of automatic differentiation (AD). Unlike for numerical
|
818 | 818 | differentiation, the computation cost scales linearly with the number of
|
|
1066 | 1066 | Enzyme, and give the user the option of selecting Enzyme for Automatic
|
1067 | 1067 | Differentiation, based on his/her needs. This will give the user the
|
1068 | 1068 | same User Interface as clad for writing his/her code, but the option of
|
1069 |
| - using Enzyme as the backend with all its optimisations to calculate the |
| 1069 | + using Enzyme as the backend with all its optimizations to calculate the |
1070 | 1070 | Derivative/Gradient of the requested function. My proposal also briefly
|
1071 | 1071 | gives insights into how this can be achieved by tapping into the
|
1072 | 1072 | existing code base of Clad.
|
|
1118 | 1118 | description: |
|
1119 | 1119 | In C++, it's often useful to write wrappers that abstract or extend some
|
1120 | 1120 | underlying type passed as a template argument. But templates are only
|
1121 |
| - instantated taking into account the 'fundamental' types of the |
| 1121 | + instantiated taking into account the 'fundamental' types of the |
1122 | 1122 | arguments, discarding 'type sugar', such as any aliases, attributes or
|
1123 | 1123 | other cosmetic metadata such as how the name of the type was qualified
|
1124 | 1124 | and such. While this ends up in practice being brittle to rely on,
|
|
1129 | 1129 | further engineering to work around this limitation, member accesses on
|
1130 | 1130 | template specializations will only reflect these canonical types, with
|
1131 | 1131 | the simplest example being the loss of any sugar on the argument when
|
1132 |
| - acessing a member alias to the argument itself. For this project, we |
| 1132 | + accessing a member alias to the argument itself. For this project, we |
1133 | 1133 | will improve Clang's type system so that any type sugar on the arguments
|
1134 | 1134 | of a template specialization are pushed into those member accesses.
|
1135 | 1135 | proposal: /assets/docs/Matheus_Izvekov_Proposal_2022.pdf
|
|
0 commit comments