Rusky

47 ms·

451.
by Rusky 7y ago
Here are some common alternatives I've seen and used: 1) Don't allocate or free resources during gameplay. Push it to load time instead. This works for things like assets that don't change much. 2) Use an arena that you reset
452.
by Rusky 7y ago
They mean the entire C++ standard library. There's plenty of non-header code in there.
453.
by Rusky 7y ago
This is a separate layer from the CRT source, which is why you didn't find it there. It's maintained separately, versioned separately, and deployed separately. This also doesn't actually appear to have any commits correspon
454.
by Rusky 7y ago
Misleading if the point were that the API got smaller or easier, maybe. But the point is instead that the amount of work done in the main render loop is smaller. Those 15 lines do go away in that sense- they only happen once on startup un
455.
by Rusky 7y ago
That is part of a real convention in active use, influenced by the medium of text on phones and computers. People replace full stops with newlines/message breaks, and over time they start to repurpose the now-unused punctuation for emp
456.
by Rusky 7y ago
That's really not true. We've been drawing faces and other emoticon-like symbols next to our words long before the internet. (Think informal writing like postcards or notes.) People have illustrated their writing for even longer.
457.
by Rusky 7y ago
I don't have a good overview but the last time I saw wasm-generated assembly it (e.g. firefox's compiler) was very very bad at actually using x86 addressing modes and other peephole-like "optimization" leading to high in
458.
by Rusky 7y ago
C++/CLI is already full of incompatibilities with C++17 (and C++14, and C++11), and there are plans to cut off C++/CLI support with newer standards. Existing support is mostly by accident. Meanwhile "must distribute a runtime
459.
by Rusky 7y ago
What I'm saying is, the feature/mechanism that lets WebAssembly call WebGL or WebGPU is exactly the same one that lets it call DOM APIs. The same implementation work supports both.
460.
by Rusky 7y ago
LLVM bitcode is far worse than WASM bytecode as a standard binary interchange format. It is intentionally non-portable and unstable by its designers. Google tried using it for this purpose with PNaCl and it wasn't great. Apple makes it
461.
by Rusky 7y ago
WebGL bindings are on the same footing as DOM bindings- they're not an alternative in this sense, because insofar as we have one we already have the other.
462.
by Rusky 7y ago
Again, you keep bringing these up, by they are not the same thing as WASM. Graal does not have a standard binary interchange format for compiled C/Rust/etc.-style programs; it requires per-language support for them and works in
463.
by Rusky 7y ago
You keep saying this, but WASM has some very specific technical differences from these previous VMs that make a huge difference.
464.
by Rusky 7y ago
The only way for `git checkout .` to blow away an entire month of work is if you didn't add or commit anything for an entire month.
465.
by Rusky 7y ago
Aside from the high-level similarity of the "function -> state machine" transformation, Rust's is quite a bit different (and IMO both simpler and more flexible). A C++ coroutine chooses a particular promise type as part of
466.
by Rusky 7y ago
...but a large part of the reason to ditch M:N was the overhead it added to 1:1-style IO in a language quickly moving toward the C++ space. They didn't decide to move off of M:N when it was exclusively M:N.
467.
by Rusky 7y ago
A clarification: Rust async/await stacks do not move or change size. They are fixed to the size of a static call graph and are pinned in place. (Going beyond that can be done with explicit heap allocation, but it's extremely rar
468.
by Rusky 7y ago
> Make a function async and your entire call graph has to be made async, unless they handle the future manually without await. You can "handle the future manually without await" very easily, it's just one function call. Th
469.
by Rusky 7y ago
Why would this be the case? Normal stack layout and register allocation already discards things that are not live across function calls. (With some potential wiggle room because that's not the primary goal, I suppose?)
470.
by Rusky 7y ago
You are correct, the overhead is linear with the stack depth. I suggested a more longjmp-esque approach [here]( https://internals.rust-lang.org/t/pre-rfc-cps-transform-for-... ) early on, but it didn't seem to be wo
471.
by Rusky 7y ago
But it doesn't pollute the signatures of the consumers, that's the whole point of this subthread. If you don't want/need to expose your async-ness, you just synchronously block on your async callees instead of awaiting
472.
by Rusky 7y ago
Yeah, exactly. I believe you're correct that you just need to know what the stack looks like, not really change it much if at all. Any tweaks you may need to make are probably already available for things like split stacks or green thr
473.
by Rusky 7y ago
Reusing the stack frame layout for a continuation state block is a really neat approach! Internal pointers into the stack aren't really the reason Rust can't take this approach either, though, unfortunately. Async frames are &quot
474.
by Rusky 7y ago
This is all just down to a poor choice of words, and maybe syntax. The choice of `async`-vs-not is not the one you describe. What we label with `async` is a particular compilation style that makes the function interruptible in userspace,
475.
by Rusky 7y ago
Presumably you execute it with an instance that does serialization instead of interpretation.
476.
by Rusky 7y ago
No, that's when it's least interesting to ask what the hardware does. A program with UB will not reliably compile to any particular hardware behavior, so changing unrelated parts of the program or upgrading your compiler can cha
477.
by Rusky 7y ago
> However, if the author is arguing "Don't let the behavior of a naive enforcement of a Rust safety construct dictate how the optimized version should work" this seems like a more interesting position; but it's not cl
478.
by Rusky 7y ago
Point 2 is only a limitation of the current standard library, not of the language-level model. It has even been relaxed recently, so you can go from a &Cell<[T]> to a &[Cell<T>]: https://github.com/rust-l
479.
by Rusky 7y ago
There is a lot of unexplored wiggle room in the design of borrow checking that might get closer to what you want. For example, Rust puts &T and &mut T at the forefront, which leads to a slightly alien way of handling aliasing- it&#x
480.
by Rusky 7y ago
You could equally just pick one of the above commentor's list and use it for 20 years (minus a few for the relatively new ones). They all still work, whereas when Apple transitions they remove the old option.

More ›