Timeloop-mapper + Plug-In Table

[jgomez6]

Hi,

Thank you for offering this tool. I am writing to you because I get a problem when I use Plug-In tables and Timeloop-mapper. I can define my memory read/write values, and accelergy correctly generates the ERT table, however, then when I use timeloop-mapper, it only takes the write energy to calculate the energy (per-scalar-access). This is weird because it is the energy that it uses for Scalar Reads, Scalar Updates, and Scalar fills, which implies reading and writing. I can see this in the file: timeloop-mapper.stats in which for the Global Buffer (the memory that I am modifying) only considers the write energy in the "Vector access energy : 1.20 pJ".

I could just use the counting and my energy values to get the total energy, but I will not be sure that the dataflow is optimal for my memory parameters, given that only one energy value was used for the optimization.

Please find attached a zipped file with the complete setup of the experiment. It can be run by running the code: timeloop-mapper arch/system.yaml arch/components/*.yaml mapper/mapper.yaml constraints/*.yaml example_layer.yaml

The Plug-in table is in the folder EM_tables, and in the generated ERT file (timeloop-mapper.ERT_summary), you will see that the read and write energy are correctly defined.

Please consider that to run the example you will have to add the EM_tables to your config file (accelergy_config) that is located at: \Docker\workspace\.config\accelergy

I would want to know if there is a way to include the read and write energy in the optimization process of Timeloop-mapper.

Thanks,

Jorge

Test_Read_Write.zip

[angshuman-parashar]

Thank you for your interest, and thank you for the bug report. We are fixing this problem as part of a larger upcoming update that improves Timeloop's understanding of Accelergy's action types. In the meantime, can you work around the issue, e.g., by using an average of the actual read/write energy during the search, and then applying the correct energies in post-processing as you suggested? Your observation is correct that the energy difference may incorrectly change the optimality of a mapping, but unless there is a dramatic difference between the read-vs-write energy the perturbation should be minimal.

[jgomez6]

Thank you for your answer and the suggestions for the workaround. I will implement them.

Also, thanks for the development of this tool, it is very helpful!