Accuracy for table-based plugin not updating
vkb27 opened this issue · 3 comments
In timeloop-accelergy/accelergy-timeloop-infrastructure/src/accelergy-table-based-plug-ins/set_of_table_templates/test.table.yaml
I have changed the accuracy to 80 so these values get precedence but even after running pip install .
in accelergy-table-based-plug-ins directory (tried running pip install . in accelergy directory too) the value in accelergy log is not changing.
Am i missing a step here?
2023-11-17 00:49:38 DEBUG Why plug-ins did not estimate:
2023-11-17 00:49:38 DEBUG | Aladdin_table with accuracy 70% estimating accuracy: No messages found.
2023-11-17 00:49:38 DEBUG | dummy_table with accuracy 1% estimating accuracy: No messages found.
2023-11-17 00:49:38 DEBUG | table-based-plug-ins with accuracy 0% estimating accuracy: Accuracy is 0%. Not supported.
2023-11-17 00:49:38 DEBUG | CACTI with accuracy 0% estimating accuracy: Class name wire not supported. Supported classes: ['SRAM', 'cache', 'DRAM']
This appears to be an Accelergy-specific issue. Could you please raise this issue at the Accelergy project page: https://github.com/Accelergy-Project/accelergy?
Hi, I just had a small question, I'm running the timeloop through resnet layers on eyeriss-256 arch which is given in configs/mapper/ and I'm trying to analyse the effect of quantization by reducing the word-bit of the MAC unit. But even if i change the word-width of all the units the last level accesses and number of cycles remain the same. In theory the effective bandwidth increases so shouldnt the DRAM access reduce for the same bandwidth? And hence the communication latency should reduce? Any insight would be helpful. Thanks!
Bandwidth is specified in the YAML in terms of words/cycle. If you want to keep bandwidth (in bytes/cycle) unchanged while changing word-bits then you'll have to commensurately change the bandwidth spec as well.
I acknowledge that it may be convenient to have an alternative to specify bandwidth in terms of bytes/cycle instead of words/cycle, e.g., using new YAML keys read_bandwidth_bytes
, write_bandwidth_bytes
, etc. The code in buffer.cpp
has all the data to trivially transform one to the other, it should be 10-20 lines of code. It may worth your time to add these keys instead of manually scaling the YAML values using the existing interface. All the code will be restricted to buffer.hpp
(to expose the new keys) and buffer.cpp
to parse them and translate them to the existing spec in the BufferLevel::ParseSpecs()
method. Once you do the translation, the rest of the code will work as-is.