This page contains details on LibGeoDecomp's internals. We don't have a terrible lot of documentation online as most of the team work at FAU. However, here are some starting points.
Download
const TYPE& var instead of TYPE const & var.
typedef
typename CELL_TYPE::Topology Topology. (see example
on the right).
#ifndef
LIBGEODECOMP_MISC_GRID_H
for misc/grid.h.
CamelCase for classes, typenames,
functions, variables. All types are capitalized, all functions
and variables start with lower case characters.ALL_CONSTANTS are all caps, delimited by underscores.crptcAbvtns or single letters. No one can
remember
what k2, alpha, xx and
such mean, not even you. Bytes are cheap these days. Why not
use descriptiveNames?
namespace LibGeoDecomp {
template<typename CARGO>
class Container
{
public:
friend class ThatOtherClass;
typedef typename CARGO::Topology Topology;
static const int DIM = Topology::DIM;
inline Container(size_t size, const CARGO& default)
{
myData = new CARGO[size];
for (size_t i = 0; i < size; ++i) {
myData[i] = default;
}
}
~Container()
{
delete myData;
}
inline void setFront(const CARGO& newFront)
{
myData[0] = newFront;
}
/**
* Will exchange
*/
inline void swapFront(CARGO *newFront)
{
std::swap(myData[0], *newFront);
}
inline CARGO *data()
{
return myData;
}
};
}
The C++ stats include libgeodecomp/src only; the
build system includes all CMake files and the
TypemapGenerator. All stats exclude generated files.
How often does the term fixme occur in the code? (Fewer would be better.)
Performance plots typically use seconds (s, the fewer the
better) or Giga Lattice Updates Per Second (GLUPS, the more
the better) as their unit of measure. They contain multiple
curves which compare implementations based on LibGeoDecomp
with
Please mind the different scales in the plots. Some benchmarks were introduced at different times to the various architectures, which is why the horizontal scales differ. And of course the vertical scales differ, too, as the different hardware architectures yield different levels of performance.
This category contains multiple benchmarks which are identical, or at least good representatives of those kernels found in actual simulation codes. They were chosen so that they allow comparison with competing implementations.
The geometry subsystem is responsible for the domain decomposition. (I.e. which parts of the grid are assigned to which node and how can we determine halos and traverse the coordinates?) Their primary purpose is to discover involuntary performance degradations.
Some of our components naturally rely on MPI. This set of benchmarks evaluates how well they perform.
