computationalradiationphysics / dodo Goto Github PK

Currently, each Vertex/Edge has a Property that holds N pointers (for N possible attributes).

Since not each Vertex has all the Properties (some vertices don't have properties at all), but still the type, it would be nice to save some memory

Probably possible by using a List instead of the vector (or dynamically allocating the vector as needed).

• This requires some changes in the getters/setters and probably others, as currently the index of the vector is sometimes used to determine the type. Should depend only on the mapID that is stored in the handle.

There might be a conflict with #1

Hi, this is probably a minor issue, but the DOI for the Diploma Thesis does not work.

While the consists-of graph has some kind of graphical display functionality, there is need for a graphical representation of the interconnect graph. This will also help to verify the behavior of functions like mergeStarTopology()

Alternatives:

• boost::variant
• use the correct type right away (tuple of std::vectors)
  • might require sth like boost::hana to get nice and shiny?

Simple example for a cache (or a caching hierarchy?) to be used for more complex things

using #14 and others, there should be at least 1 example graph that represents a full Node

Assuming structure where a new graph is created through a root node that consists of N homogeneous substructures, it would be very convenient to have a function that automates this process.

• Also think about interconnects!

example interface:

Graph substructure;
// ... definition of substructure

Graph g = consistsOf(substructure, N);

//Alternatively:
Interconnector intcn; // functor determines how the N substructures will be interconnected
                      // could be fully-connected, hypercube, etc.
Graph g = consistsOf(substructure, N, intcn);

currently, all have a pointer to AttributeMapStore. Could this be more encapsulated?

• This is interesting, since Handles might not actually NEED the type of the graph. Should actually not have ANY type, IMHO.
• Properties will have the type by design (BGL demands it)
• Attributes would probably be OK just to have their own type
  • currently need the whole AttributeMapStore because of their destructor-mechanism

A graph that represents a real CPU, including caches #15 and cores #16

The preferred way is slicing of graphs, but merging should definitely be possible and well supported.

• a first step (internally?) would be to convert both graphs to the same type. Then the mapping is all about finding the correct subgraph isomorphism.
• a first simplification for the subgraph isomorphism should be, that one graph is structurally a strict subgraph of the other.
• combining 2 graphs that don't have a strict subgraph relation:
  • merge vertices/edges where an appropriate mapping exists. otherwise, copy elements directly and simply add them.
  • this might not be possible with the existing boost::graph_copy functionality, but might require iterating over the vertices of a graph and do a lookup in the mapping
  • would be easier if the mapping was done as a boost::bimap....

Complementary to #4, there needs to be a system to create a subgraph based on structural properties (as stated in #3, this might need tagging information or rely solely on regular attributes)

There needs to be an agreed-upon mechanism for storing the structural meta-information.

• This allows to filter the graph for certain interesting things ("all CPUs and their communication")
• Alternatively, do the filtering strictly by regular attribute meta-information

Using #17, there should be an example that consists of multiple queues, each having different nodes

given graphs g1 and g2, find a way to combine them into a new graph.

Example, see stackoverflow question about the topic: http://stackoverflow.com/questions/33874305/how-to-combine-merge-multiple-graphs-using-lemon-or-bgl

All data hast type "string" in the graphml file. This is due to the type of the maps in "getMaps()", see
vector<pair<string, map<Key, string>>> maps(tuple_size<T_Labels>::value); (here)

To fix this, the maps need to be a tuple instead of a vector. This tuple has to be generated at compile time with the types that are returned by the toString() methods of the attributes.
The type that is returned can be obtained through decltype(((T_Property*)nullptr)->toString())

In addition to the fitering options ( #4 + #8 ), there could be an interface that supports more elaborate queries to the graph:

• How many GPUs?
• What is the minimum bandwidth between CPUs?
• What is the minimum amount of memory on a node?

This solves multiple problems:

• merge function #9
• polymorphic nature of Attributes #2

The interface needs a pure virtual function and is intended to be publicly inherited (for now).

think about the caching (#15) and how it interacts best with the core design

Since Attributes might need merging in several situations (merging graphs, iterating to get summed value), there needs to be at least one function that is used to combine multiple instances of an attribute.

This merging function should be

• commutative: a +b = b + a
• associative: (a + b) + c = a + (b + c)

METIS needs communication represented as fully-connected graph with weighted edges. It would be good to give an interface for transforming an Attribute-Graph (or a filtered representation thereof) into the correct representation

• currently there is a barebones mechanism to convert a graph to a different graph using type-conversion.
• There should be a way to get a subgraph-view using boost::filtered_graph that contains only the relevant attributes

This software lacks a short introduction / description paragraph at the top of its README.md :)

Should the interface of Data-Tasks and Compute-Tasks be fundamentally different?

• Probably at least 1 of the interfaces will be shared
• Information to think about
  • "depends on" -> input data to be a useful task
  • Dataflow (direction of data flow) -> could this be just a more verbose form of "depends on"?
  • I/O relation -> how many input-chunks (from which input sources) are needed to form an output chunk?
  • how can the user specify compute speed?
  • allow to specify hardware constraints
    • required memory
    • required CPU
    • required GPU
    • exclusive use of Node
  • Interconnect constraints?
    • must guarantee minimal throughput
    • exclusive usage of interconnect