It would be great if the expected schedule from Spider is exported as the real schedule is exported.
Comparison between Real and Espected is very useful for debugging

• Add support for delays in hierarchical graphs
• Add support for delays connected to data interfaces

Currently results of papify are stored regarding the PEId integer value and not the actual name.
It should be changed to match the one of PREESM.

Spider version 1.4.1. When using Broadcast Actor, if a value is generated x times, the Actor copies it x times instead of reusing the same value. If x or if the data size are big, it can take a lot of memory.

It seems that a comma is printed in the "pi_top.cpp", even if no static parameter is present in the ".pi".
In the general case, I obtain a code like this:

/* Top graph definition */
top(topVertex, );

Of course, this fact leads to a compilation error. Deleting the comma, compilation can finish successfully.
I noticed that, if there is at least one static parameter, the generated code is well printed, and no comma is added after the name of this parameter (the last argument).

Currently repetition vector is computed either through topology matrix or LCM using long (or long long).
To avoid any problem of overflow (if any) reproducibility, those types should be set to standard uint64_t type.

Spider version 1.4.1. Generated codegen does not add setters and getters to delays. Instead, adds edges to the delays.

Code example:
test_auto_layout_error.zip
File pi_test_delay.cpp generated by codegen has 3 edges objects when it should have only one. The first edge containing the delay does not define setter and getter as it should.

When compiling current develop version of Spider (00b1059) with code generated with develop version of preesm (39c6eedcfdaca76252), there is an undefined reference to variable stopThreads.

There are some hard coded constants like
MAX_IO_EDGES and MAX_MSG_SIZE
that should be set from the generated main.cpp the same way the
size of the shared memory is.
This would avoid "painfull" search of why spider crashes on some applications.

Spider Pthread platform does not support architecture definition with multiple PE types: the CPP code forces the value to 1. See: https://github.com/preesm/spider/blob/master/master/libspider/platforms/platform_pthread/platformPThread.cpp#L243

• Spider runtime should allow to set this value;
• Codegen in Preesm should generate code for setting appropriate values;

preesm.insa-rennes.fr/website/index.php?id=building-spider

The branch pthread_platform doesn't exist anymore and, maybe, the tutorial should be updated

In the application that can be downloaded from [1], after a while, using SpiderCodege.workflow with the 4CorePapify.scenario (Papify is completely disabled in both the workflow and the scenario) the application freezes after running for a while.

The timing in which the application is running varies but it comes faster when reducing the parallelism using the arrows.

[1] https://drive.upm.es/index.php/s/LSCUJ6dwh6lYHHt

After analyzing applications whit and without PAPIFY configurations and enabling/disabling the monitoring, we have discovered a performance issue associated to the use of papify within SPiDER. The behaviour is the following one:

• No monitoring configuration and papify flag in main.cpp 'false' --> 11.8 FPS
• No monitoring configuration and papify flag in main.cpp 'true' --> 10.4 FPS
• Monitoring configuration and papify flag main.cpp 'false' --> 11.8 FPS
• Monitoring configuration and papify flag main.cpp 'true' --> 11.4 FPS

With these values, it seems that when SPiDER tries to use PAPIFY without any configuration it spends extra time looking for it unsuccessfully. The (logic) workaround of disabling PAPIFY if it is not used works, but maybe some improvements can be done internally to avoid this behaviour, because it is slowing down SPiDER applications.

During code generation, Spider fails at looking up the timings for actors with identical name within different hierarchy level. For instance (using actor path notation), actors topgraph/Display and topgraph/subgraph/Display can coexist, but Spider will fail to generate the code that sets the timings for the actor topgraph/Display.