触发 mgc; 好吧, 贴图, hard 看, hard 看

--
FROM 114.246.100.*

con
cxx一时爽，爽至修罗场…
rust严归严，写完平着躺
【 在 zylthinking2 的大作中提到: 】
: 触发 mgc; 好吧, 贴图, hard 看, hard 看[upload=1][/upload]
--
FROM 124.64.22.*

Tokio 的mutex 性能低
我有点抵触
虽然其实屁影响没有

我其实自己也写过一个异步mutex， 不至于不理解这玩意


【 在 tsa300 的大作中提到: 】
: 最佳实践是异步环境用异步锁，你的问题是axum异步框架下用了同步锁 std:sync:MutexGuard
: 除非明确的单线程环境，比如tokio::task::spawn_local（不要求Send，但会带来阻塞），否则跨 await 持有同步锁会被编译器阻止。编译器通过要求 send 阻止你这么做的原因是标准库的同步锁是按 posix标准用OS线程原语实现的，必须确保同线程操作锁，而跨await无法保证这一点。异步锁就没这问题，可以安全跨await持有
--
FROM 114.246.100.*

我知道我的理由不合理
前面都说了, 只是心理有点抵触, 让自己心里舒服点而已, 其实知道屁影响都没有

其实一个更荒谬的是, 其实这个锁是完全没必要的;因为我后来干脆使用了 current_thread 调度器, 如果保持 mutex guard 不跨越 await 点, 那其实等于这个 mutex 就根本不会有竞争, 用这个 Mutex 完全是因为rust 非要线程安全方式访问 static 变量而已.  

这里换成 UnsafeCell 完全没任何问题, 但又要写一堆代码, 琢磨了一下就这么凑合得了 --  好歹这样换成多线程调度器也不会出问题

【 在 tsa300 的大作中提到: 】
:
: 异步框架下都已经牺牲代码的安全性和一致性去追求锁性能了，还使用 std::sync::MutexGuard 就完全没法儿理解了，显然 parking_lot性能好得多，内存占用更少(1byte vs 40bytes)，而且对同步原语的实现更完整（超时、公平锁、可再入锁、可选的死锁检测等等）
: 在真实世界的后端中，比同步锁vs异步锁开销对性能影响大得多的环节到处都是，使用同步锁给系统带来的问题比那点性能收益大远去了，这就是前文回复中为什么说异步编程用异步锁是最佳实践的原因。
--
修改:zylthinking2 FROM 114.246.100.*
FROM 65.49.223.*

是的，根基牢固，厚积薄发，基于逻辑学和初等数学证明的所有权底层模型势不可挡。

但是也真陡峭，尤其wgpu怎么优化。最近几天试着借助AI，以期构建一个Slint + WGPU的实时渲染demo，今天自闭了，好不容易能跑，但性能非常糟糕，不想折腾了。


【 在 wanllow 的大作中提到: 】
: 不可阻挡的趋势了
--
FROM 123.127.159.*