u99127 commented on issue #5060: [uTVM][Runtime] Deprecate uTVM Standalone 
Runtime
URL: https://github.com/apache/incubator-tvm/issues/5060#issuecomment-603408836
 
 
   Thanks for pointing this to me @tmoreau89 and thank you for this work 
@liangfu . Very interesting and good questions to ask.
   
   From a design level point of view for micro-controllers I'd like to take 
this one step further and challenge folks to think about whether this can be 
achieved with static allocation rather than any form of dynamic allocation . 
The hypothesis being that at compile time one would know how much temporary 
space is needed between layers rather than having to face a run time failure.
   
   Dynamic allocation on micro-controllers suffers from fragmentation issues 
and further do we want to have dynamic allocation in the runtime on 
micro-controllers.  Further the model being executed will be part of a larger 
application  - how can we allow our users to specify the amount of heap 
available or being consumed for executing their model ? It would be better to 
try to provide that with diagnostics at link time or compilation time rather 
than at runtime. @mshawcroft  might have more to add.  And yes, in our opinion 
for micro-controllers one of the challenges is the availability and usage of 
temporary storage for working set calculations between layers.
   
   2 further design questions. 
   
   1.   In the micro-controller world, supporting every new device with their 
different memory maps and what not will be painful and beyond one simple 
reference implementation, I don't think we have an efficient route to 
deployment other than integrating with other platforms in the microcontroller 
space. How would this runtime integrate with other platforms like Zephyr, 
mbedOS or FreeRTOS ?
    
   2. I'd be interested in extending CI with qemu or some such for Cortex-M as 
well or indeed on the STM board that you are using @tmoreau89 .
   
   Purely a nit but from a rationale point of view, I would say that uTVM 
runtime not being tested in a CI is technical debt :)
   
   regards
   Ramana

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Reply via email to