made minor changes to system architecture

studouglas · Apr 23, 2016 · e684bbd · e684bbd
1 parent ede3d85
commit e684bbd
Show file tree

Hide file tree

Showing 2 changed files with 2 additions and 1 deletion.
diff --git a/Documentation/DesignDoc/SystemArchitecture.pdf b/Documentation/DesignDoc/SystemArchitecture.pdf
diff --git a/Documentation/DesignDoc/SystemArchitecture.tex b/Documentation/DesignDoc/SystemArchitecture.tex
@@ -218,7 +218,8 @@ \subsection{GPU Integration Approach}\label{Sec_IntegrationApproach}
 
 In all options except 1 and 2, a function call to one of the functions of a ported class will be received by the existing C++ class, which will then either execute the existing code if that function has not been ported or if GPU computation is disabled, or will call the corresponding function from the CUDA file.
 
-Option 5 was chosen due to its ability to divide work easily, its compatibility with the current codebase, and the memory advantages over option 4.
+Option 5 was chosen due to its ability to divide work easily, its compatibility with the current codebase, and the memory advantages over option 4. 
+Option 3 was also implemented after performance testing showed that option 5 did not provide any significant speed ups.
 
 \subsection{G4ParticleVector}\label{subsec_G4ParticleVector} % rob
 As was explained in the preceding subsection, the problem has been decomposed to that of only integrating specific functions from given modules with the CUDA technology. With that said, a decision needed to be made as for which class and which functions within that class to integrate.