Lina got the happy ending. She moved on to apply her talent to bigger and better projects - the real tragedy is how many years of volunteer effort were wasted by Apple's opaque documentation.
Maybe some folks more familiar with iOS can comment on how reliable this is on the software side. For example, what's stopping me from feeding a video stream as camera input?
I want one for HiFi headphones / IEMs! I feel really bad to order two or three models that I want and have to return all but one, because I can't really tell the difference just by looking at the specs sheet. My ears should be the ultimate judgement.
As always, honorable mention to Typst [0] as a good balance between the readability & simplicity of Markdown with the flexibility & composability of LaTeX. I think and hoping that Typst will be the future, but for now I'm happy with Markdown.
One concern I have is that this async/await approach is not "AOT"-enough like the Triton approach, in the sense that you know how to most efficiently schedule the computations on which warps since you know exactly what operations you'll be performing at compile time.
Here with the async/await approach, it seems like there needs to be manual book-keeping at runtime to know what has finished, what has not, and _then_ consider which warp should we put this new computation in. Do you anticipate that there will be measurable performance difference?
Doing things at compile time / AOT is almost always better for perf. We believe async/await and futures enables more complex programs and doing things you couldn't easily do on the GPU before. Less about performance and more about capability (though we believe async/await perf will be better in some cases, time will tell).
If you can tell deterministically whether an 'async' computation is going to be finished, you can most likely use a type-system-like static analysis to ensure that programs are scheduled correctly and avoid any reference to values that are yet to be computed. But this is not possible in many cases, where dynamic scheduling will be preferable.
reply