ml-compiler-opt VS connectedhomeip

I did a bit of work on this last summer on (much) smaller models [1] and it was briefly discussed towards the end of last year's MLGO panel [2]. For heuristic replacements specifically, you might be able to glean some things (or just use interpretable models like decision trees), but something like a neural network works fundamentally differently than the existing heuristics, so you probably wouldn't see most of the performance gains. For just tuning heuristics, the usual practice is to make most of the parameters configurable and then use something like bayesian optimization to try and find an optimal set, and this is sometimes done as a baseline in pieces of ML-in-compiler research.

1. https://github.com/google/ml-compiler-opt/pull/109

If you're using Clang/LLVM you can also enable ML inlining[1] (assuming you build from source) which can save up to around 7% if all goes well.

There are also talks of work on just brute forcing the inlining for size problem for embedded releases for smallish applications. It's definitely feasible if the problem is important enough to you to throw some compute at it [2].

1. https://github.com/google/ml-compiler-opt

2. https://doi.org/10.1145/3503222.3507744

LLVM's inlining-for-size and register-allocation-for-performance optimizations are both implemented using machine learning models trained by Google.

Continue reading | Checkout the paper, github, demo and ref article.

Looks like they do have a pretrained model:

https://github.com/google/ml-compiler-opt/releases/download/...

The code will by default auto-download it during the build process. It's about 800 kbytes, which seems very reasonable for something that will reduce the generated code size by gigabytes for a large codebase.

Clone the Matter repository: git clone https://github.com/project-chip/connectedhomeip.git Navigate to the repository directory: cd connectedhomeip Update the submodules: git submodule update --init

https://github.com/project-chip/connectedhomeip/blob/master/...

2. Only native apps are supported. There's no protocol to say open a webpage & control that.

3. No support for multi-party sessions. Only one user can interact at a time.

4. No support for the Web's Presentation API. Since it's not based around urls & web pages, it would require lots of additional work to make it support the standard web pages have to spawn a remote display.

By compare, Open Screen Protocol lets any target device open any web page, which is very similar to how Chromecast development works today. Whether the target device is Android, Apple, WebOS, Windows, Tizen, or other, the expectation that I could Open Screen Protocol cast to it remains the same. Where-as Matter Cast requires a native app on the device & the app has to be installed & potentially even greenlit by the target device platform itself.

OpenScreenProtocol really looks to have it all, & the model is so much more universal. Really wish we saw some device makers pushing for it these days.

They do have example Matter projects for the ESP32-C3/S3. I assume it's over WiFi and not thread.

https://github.com/project-chip/connectedhomeip/tree/master/...

IoT is a big space right now if you look at the companies who commit to https://github.com/project-chip/connectedhomeip. They come together at the CSA Member Meeting.

I followed this doc: https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/esp32/setup_idf_chip.md

"Securing name resolution in the IoT: DNS over CoAP" https://news.ycombinator.com/item?id=32186286

From https://github.com/project-chip/connectedhomeip#architecture... :

> Matter aims to build a universal IPv6-based communication protocol for smart home devices. The protocol defines the application layer that will be deployed on devices and the different link layers to help maintain interoperability. The following diagram illustrates the normal operational mode of the stack:

> [...] It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports.

> Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.

> [...] The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.

Is there already a good (security) comparison of e.g. http basic auth, x10, ZigBee, mqtt, matter?

Bloaty is a nice tool.

When I worked on Matter a couple years ago, we had the problem that its backend http://www.capstone-engine.org/ did not support Xtensa, and produced some Python tools that could take output from bloaty or similar data from readelf or elftools, and produce several kinds of report.

https://github.com/project-chip/connectedhomeip/blob/master/...

My two cents from someone who has dealt with product name changes. Most recently I worked on the Chip repo which is now known as Matter. There are numerous references in the repo to chip despite the name change. See https://github.com/project-chip/connectedhomeip

Not sure if I'm asking in the right place so I apologise ahead. I'm trying to get one of the example projects from Matter onto my esp32 (ESP-WROOM-32) using espresiff. I am doing this on my raspberry pi btw. The problem I'm having now is that it get's stuck when I'm building (idf.py build command). It's always around 800/1135 and it doesn't go past it. The one where it is currently stuck is: [804/1135] Building C object esp-idf/bt/CMakeFiles/__idf_bt.dir/host/nimble/nimble/nimble/host/src/ble_gatts_lcl.c.obj.