# 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 "))
TUI --> Update --> Validator --> Player --> TUI
TUI(("terminal <br>UI"))
Update["board update "]
Validator(("move<br>validator "))
Player["player move "]
```
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
---

(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}]"}