# TurboWish: Dreams of Performance Tooling --- # Problem --- People hear about Rust Such amazing promises They dive in, prototype But ... does not always measure up to expectations --- People ask: What now? --- ## The Past --- At best, Rust Project focused on meeting needs of: 1. existing C/C++ programmers (DWARF, LLVM gcov, PGO, etc), and 1. compiler developers (`-Zself-profile`) --- ## The Present --- ## Polling Informal discussions with Rust users > Is Rust delivering on its promise with respect to performance? Got three classes of answers --- ### Answer A > Rust is great! Once I got it compiling and my unit tests passing, the code works and meets my performance expectations. --- ### Answer B > I got it compiling, but its not actually as fast as I had hoped. What should I do now? --- ### Answer C > I struggle to figure out what design to use. I struggle to get my service compiling. You are asking me what I think about performance, but I’m debugging deadlocks from my async code. --- ## Hypothesis Past tooling attitude: focus on compatibility with status quo (at best). Attitude borne of necessity. Rust has since further branched away from world of C/C++. --- Rust has since further branched away from world of C/C++. ⇒ Should broaden scope to innovate in our development tools as well as our language <!-- .element: class="fragment" data-fragment-index="1" --> Debugging and Profiling are not really disjoint activities. Both are in service of understanding program behavior. <!-- .element: class="fragment" data-fragment-index="2" --> ⇒ Can we make tools that help us with both at once? <!-- .element: class="fragment" data-fragment-index="2" --> --- ## TurboWish A wish. A dream. (Not a top-down directive.) --- ### Digression: Why publicize our dreams? --- From ["Rust is not a company"](https://twitter.com/m_ou_se/status/1405902121585844225) by @m-ou-se : > \[Each\] person comes with their own goals and ideas, adding to an already quite diverse set of potentially conflicting goals > Unlike a company, we don’t get to choose what people spend their time on, and we don’t hire people to assign tasks to. --- Impactful leaders inspire others to action. But great leaders *also* listen. We all have opportunities to demonstrate leadership. We all have preferred broadcast platforms. <!-- we all have a voice --> --- We all should strive to *share* our ideas and to *listen* to those of our peers. After digesting them all, amplify the best ones. * See also: [Vision Doc process](http://smallcultfollowing.com/babysteps/blog/2021/05/01/aic-vision-docs/) * But *unstructured broadcast* has value too! * Tweet threads welcome! --- ## So I publicize dreams to excite others about our shiny future. --- ## Back to the dream --- ## TurboWish I developed a collection of [goals](http://blog.pnkfx.org/blog/2021/04/26/road-to-turbowish-part-1-goals/), [hypothetical user experiences](http://blog.pnkfx.org/blog/2021/04/27/road-to-turbowish-part-2-stories/), and a [software architecture](http://blog.pnkfx.org/blog/2021/05/03/road-to-turbowish-part-3-design/), all spelled out on linked blog posts. --- Those three TurboWish documents were an exercise in [Working Backwards](https://medium.com/the-digital-project-manager/working-backwards-a-new-version-of-amazons-press-release-approach-to-plan-customer-centric-c17991583508). Different experiences and expectations for (e.g.) Rust newcomers versus `rustc` developers versus experienced web service developers --- <!-- Sample from [rustc dev story](http://blog.pnkfx.org/blog/2021/04/27/road-to-turbowish-part-2-stories/#User.Story.3b:.Chris.s.Dream) > \[Asked for the ownership graph for borrow checker\], the TurboWish web front end renders the resulting graph of direct ownership relations. It also includes arcs for any `&`/`&mut` references in the graph, and also domain-specific dotted arcs for indices that are meant to be interpreted as references relative to arrays in a shared context object. --- --> Sample from ["Design Doc"]([http://blog.pnkfx.org/blog/2021/05/03/road-to-turbowish-part-3-design/](http://blog.pnkfx.org/blog/2021/05/03/road-to-turbowish-part-3-design/#TurboWish.Overview)) > The Console shows how tasks are scheduled (to illuminate time is spent in developer’s own code versus waiting to run), identify tasks that are blocked and what resources they are waiting on, and identify tasks responsible for replenishing a scarce resource. --- Sample from [another user experience](http://blog.pnkfx.org/blog/2021/04/27/road-to-turbowish-part-2-stories/#User.Story.1:.Abigail): > \[Debugging a deadlocked Chess program,\] Abigail clicks “dependencies”, and sees a directed graph linking tasks and resources, depicting > 1. what resources a task is waiting on, and > 1. what tasks could free up those resources. --- Continued from [user experience](http://blog.pnkfx.org/blog/2021/04/27/road-to-turbowish-part-2-stories/#User.Story.1:.Abigail): ```mermaid graph LR AI(("game AI&nbsp;&nbsp;")) TUI --> Update --> Validator --> Player --> TUI TUI(("terminal&nbsp;&nbsp;<br>UI")) Update["board update&nbsp;&nbsp;"] Validator(("move<br>validator&nbsp;&nbsp;")) Player["player move&nbsp;&nbsp;"] ``` Cycle. Implies potential deadlock. --- <!-- All the trailing periods in the labels are working around some bug in the slide presentation mode that is cutting off the text prematurely in the nodes of the diagram. --> Sample from [design doc](http://blog.pnkfx.org/blog/2021/05/03/road-to-turbowish-part-3-design/#Diagram.of.Async.Monitor.Architecture) ```mermaid flowchart TD subgraph Client TwCollect --- pause_reqs ---> Tokio pause_reqs([introspection requests,<br/>e.g. 'pause']) TracingEventBus TracingEventBus -.-> TwCollect TwCollect[Async Monitor .] TwCollect --- EventLog EventLog[(EventLog .)] Tokio[Async Executor _<br/>e.g. Tokio] ClientCode[Client App Code .] Rayon[Rayon .] ClientCode -.-> TracingEventBus Tokio -.-> TracingEventBus Rayon -.-> TracingEventBus TracingEventBus[Event Bus .] end subgraph Console [Console Program .] TwTui <--> TwCollect TwTui([Async Console .]) end ``` --- Text sketches and diagrams like that are one way to inspire people --- Another "Working Backwards" way to inspire: Mock-ups --- ![console tui mockup](https://i.imgur.com/F71IQMl.png) (mockup provided by Carl Lerche) --- ## Reality Check Tokio Team has been long concerned about async runtime performance and debugging Champing at bit to help address problems here --- ## tokio-console demo (or maybe at end) --- links (and I'll repeat links at end) https://github.com/tokio-rs/console https://discord.gg/wYC6YheV , `#console` (under UTIL) --- Tokio's `console` is one tool in my dream utility belt another dream tool: ownership heap profiling another dream tool: record-replay tracing --- Can get some tools by improving existing integrations. (⇒ "Easy path" -- but requires specialized knowledge) <!-- .element: class="fragment" data-fragment-index="2" --> Other tools will need entirely new integrations. <!-- .element: class="fragment" data-fragment-index="3" --> Still others, like Tokio's `console`, require entirely new from-scratch products. <!-- .element: class="fragment" data-fragment-index="4" --> (⇒"Hard path" -- but can attract enthusiastic newcomers.) <!-- .element: class="fragment" data-fragment-index="5" --> --- ## Remember Great leaders inspire and also listen. We all have platforms. We all have a voice. Publicize your dreams. Evangelize our shiny future. https://github.com/tokio-rs/console https://discord.gg/wYC6YheV , `#console` (under UTIL) (and you can come find me on Zulip)
{"metaMigratedAt":"2023-06-16T02:42:46.154Z","metaMigratedFrom":"YAML","title":"2: TurboWish: Dreams of Performance Tooling","breaks":true,"contributors":"[{\"id\":\"ebc76d8d-2914-465e-bd23-99641782eac2\",\"add\":10297,\"del\":2388},{\"id\":\"27d8f2ac-a5dc-4ebe-8c31-cc45bcd8447e\",\"add\":3,\"del\":0}]"}
    747 views
   Owned this note