vast VS webviz

Most languages target C or LLVM, and C and LLVM have a fundamentally lossy compilation processes.

To get around this, you'd need a hodge podge of pre compiler directives, or take a completely different approach.

I found a cool project that uses a "Tower of IRs" that can restablish source to binary provenance, which, seems to me, to be on the right track:

https://github.com/trailofbits/vast

I'd definitely like to see the compilation processes be more transparent and easy to work with.

At Trail of Bits, we are creating a new compiler front/middle end for Clang called VAST [1]. It consumes Clang ASTs and creates a high-level, information-rich MLIR dialect. Then, we progressively lower it through various other dialects, eventually down to the LLVM dialect in MLIR, which can be translated directly to MLIR.

Our goals with this pipeline are to enable static analyses that can choose the right abstraction level(s) for their goals, and using provenance, cross abstraction levels to relate results back to source code.

Neither Clang ASTs nor LLVM IR alone meet our needs for static analysis. Clang ASTs are too verbose and lack explicit representations for implicit behaviours in C++. LLVM IR isn't really "one IR," it's a two IRs (LLVM proper, and metadata), where LLVM proper is an unspecified family of dialects (-O0, -O1, -O2, -O3, then all the arch-specific stuff). LLVM IR also isn't easy to relate to source, even in the presence of maximal debug information. The Clang codegen process does ABI-specific lowering takes high-level types/values and transforms them to be more amenable to storing in target-cpu locations (e.g. registers). This actively works against relating information across levels; something that we want to solve with intermediate MLIR dialects.

Beyond our static analysis goals, I think an MLIR-based setup will be a key enabler of library-aware compiler optimizations. Right now, library-aware optimizations are challenging because Clang ASTs are hard to mutate, and by the time things are in LLVM IR, the abstraction boundaries provided by libraries are broken down by optimizations (e.g. inlining, specialization, folding), forcing optimization passes to reckon with the mechanics of how libraries are implemented.

We're very excited about MLIR, and we're pushing full steam ahead with VAST. MLIR is a technology that we can use to fix a lot of issues in Clang/LLVM that hinder really good static analysis.

[1] https://github.com/trailofbits/vast

For the web based part, in terms of integration with ROS RobotWebTools (especially with RoslibJS) and rosbridge cover already a lot, so maybe you may want to first check what's available there. Webviz is also a great web based tools with many components for visualisation.

Hey HN, one of the creators here! I made it at Cruise because it was super painful to develop https://webviz.io with manual memory management (lots of ArrayBuffers), WebWorkers, etc. I thought that there must be a better way.

Very curious to hear stories from other folks building intensive stuff in the browser. How are you dealing with performance issues in Javascript? Have you tried using Rust or C++ with WebAssembly for parts of your apps? How did you make 2d/3d rendering faster? Would you want to use something like Zaplib?

Webviz is a great tool. Just drag the .bag file onto the browser window and you can start viewing the data.

Webviz is actually open source for the most part. https://webviz.io

U can try https://webviz.io/ or https://foxglove.dev/

Cruise | Software Engineer | San Francisco, Seattle, or REMOTE | VISA acceptable | https://www.getcruise.com

Cruise is building the world’s most advanced, self-driving vehicles to safely connect people to the places, things, and experiences they care about. We believe self-driving vehicles will help save lives, reshape cities, give back time in transit, and restore freedom of movement for many.

I'm an engineering manager hiring specifically for the Webviz (http://webviz.io/) team. I'm looking for frontend engineers who want to make fast, beautiful browser-based visualizations of the car using WebGL, WASM and Javascript.

Much of the work that we do on this team is open-sourced (check out the code at https://github.com/cruise-automation/webviz). Cruise vehicles produce mountains of data; we have to visualize it in dozens of different ways at a high frame rate. We recently built a Javascript object proxy that wraps all of our input binary data in an object-like interface that only parses data on access, so that we can limit garbage collection pressure and improve our frame rate. If this kind of project sounds interesting, you might enjoy working on Webviz!

Reach out directly to me if you're interested in the above (open to associate/senior/staff levels), or if you have any questions about Cruise.

PS - for those of you who have seen or used Webviz, Foxglove may look familiar. Some of our team previously worked on Webviz at Cruise, and we reused much of their code, although it has been heavily refactored, several new features added, and we have more coming soon.