The main difference between the imperative SAP and the library-centric application design approach followed by the GSSE is the use of several orthogonal modules, as given in Section 7.3.4 for the assembly procedure. The emphasized expressiveness of the source code is not obscured by the overall high performance. To give an approximate measure for the effort resulting from the chosen application design, the necessary code parts of GSSE and SAP are analyzed by the required number of source lines [93], where all components of the GSSE require 7400 lines of source code:
| Application part | GSSE | SAP |
| input/output | 10 | 5481 |
| segment analysis | 558 | 3096 |
| assembly | 13 | 5866 |
| solver | 23 | 4523 |
| total number: | 604 | 18966 |
As can be seen, the development effort is reduced dramatically at an equal run-time performance even in the absence of manually tuned code parts. Instead, the compiler and various high performance libraries are used.
To emphasize not only the high performance library-centric application design proposed here, but also to demonstrate the difference of programming style with respect to extensibility, maintenance, and reusability, a comparison of the finite element algorithms by the GSSE
![\begin{lstlisting}[frame=lines,label=gsse_sap_fe_code_sap]{}
void assemble_stenc...
...= index_list.size();
rhs_add(line, stencil(i, rhs_pos));
}
}
\end{lstlisting}](img894.png)
and the corresponding matrix assembly section from SAP is given. The necessary combination of memory management and program flow, e.g., assemble_reset_mat() can be clearly seen. This part of code also lacks reusability due to the pre-conditions required by the algorithm.
![\begin{lstlisting}[frame=lines,label=gsse_sap_fe_code_sap2]{}
static void assemb...
...f(m->ass_b)
{
m->ass_b(t,&ae);
b_entry(t,S,&ae);
}
}
}
}
\end{lstlisting}](img895.png)