最近开始在摸索vibe coding工具 gemini cli 我是google gemini的pro订阅户 用google帐号登入方式认证 好像条件会比免付户好些 据说是cp值最高的 比启用api key的方式 使用起来 我切到3的模型 好像模型会动态换来换去 随着token用量 主机负担 或是问题性质 等等我不太清楚因素切换使用模组 所以品质好像也是跳来跳去 缺点是真的会写出bug 还信誓旦旦说修好了 结果还是坏掉 但优点是目前多数它最後都能搞定 有时候看不下去帮忙它debug一下 通常要帮忙开浏览器debug模式 抓一些讯息 或是靠自己的经验跟它说哪边有问题 给它提示 它修得比较快 但也遇过简单的html css排版问题搞到烂掉修不好 我对css之类没那麽熟 最後就给它上移动 恢复 简单来说 我觉得cp值高 反正pro订阅户 好像很难超额 问题是好没我觉得乾净俐落 甚至我自己还要帮忙它处理问题 还有vibe coding 好不好用真的跟专案性质很有关系 主要是训练样本 之前处理winui 3专案 常常跟wpf的xaml搞混 像是一般web相关技术 啥html css .net java php sql之类的技术 海量训练样本 效果就好很多 我猜手机app的开发也是很不错 Claude Code 今天开始用 也是付费pro用户 结果token一下就用完了 大概就是我想对以前的专案做效能优化测试 https://github.com/erspicu/LanczosWasmDemo 专案下载下来 结果我自己环境跟以前有差不能编译 先请它了解专案帮我修正 接着开始技术堆叠开aot simd 跟我说啥simd好棒棒 然後我请它帮我加上simd优化一下 结果慢到整个网页当掉 比原始版本还慢 又请它修正 原本它是把一个pixel (r,g,b,0) 封装到 vector 一堆 pack unpack动作 搞到根本不能用 它修正後 说 应该是一次处理4颗pixel才对 结果还是慢 算了好像无解 接着往Parallel.For 多核方式平行处理的方向优化 反正搞了半天也是gg 就是.net 8不支援 换成.net 9 支援了,但还是很多问题 有一些ai回覆 复制贴上一些 分享一些过程 给想往这些方向钻的.NET人一些心理准备 觉得无聊 下面可以快速略过 看最後重点 其实原始的 Lanczos.cs 里就有被注解掉的 Parallel.For： ● Searched for 1 pattern (ctrl+o to expand) ● 原作者已经试过，只是注解掉了。 WASM 的限制 不过在 WASM 环境下，多执行绪有额外条件： 1. 需要 SharedArrayBuffer — 浏览器要求设定特定 HTTP headers： Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp 2. .NET 8 WASM threading 是实验性功能 — 需要在 csproj 加： <WasmEnableThreads>true</WasmEnableThreads> 3. AOT + Threading + SIMD 三者同时启用在 .NET 8 可能有相容性问题 结论 演算法本身是 embarrassingly parallel（完美平行），但要不要在这个专案启用取决 於你想处理 WASM threading 的额外复杂度。如果是跑在桌面 .NET 而非 WASM，直接把 Parallel.For 打开就能用了。 有一点要注意：WASM threading 需要浏览器支援 SharedArrayBuffer，你的 Web Server 必须回传这两个 HTTP headers： Cross-Origin-Opener-Policy: same-origin Cross-Origin-Embedder-Policy: require-corp 如果没有这些 headers，Parallel.For 会退化成单执行绪（和 Original 一样的速度 ），不会报错但也不会加速。 ● 这是 .NET 8 WASM threading 的已知问题 — 启用 WasmEnableThreads 後， runtime 需要 worker JS 档案，但非 Blazor 的专案架构没有自动处理这个。 最务实的做法：移除 WasmEnableThreads。Parallel.For 仍然可以编译和执行，只是 在 WASM 单执行绪环境下会退化成循序执行 — 这本身也是一个有意义的比较数据（可以看出 Parallel.For 的排程开销）。 ● 最直接的路：升到 .NET 9，你已经有 SDK 9.0.310。.NET 9 对 WASM threading 的 支援比 8 成熟很多，那个 jsModuleWorker 的问题在 9 已经修正。 ● 问题在第 67 行的 Greet 呼叫。启用 threading 後，所有 [JSExport] 同步方法都 不能从 JS 主执行绪呼叫 — await 没用，因为错误在 binding 层就丢出了，根本还没回传 Promise。 修法：C# 方法要回传 Task<T> 让它原生就是非同步的。 ● Read 1 file (ctrl+o to expand) ● 所有方法都要改成回传 Task<T>，用 Task.Run 包起来： ● Task<byte[]> 不被 JSExport 的 marshaler 支援。这是 .NET 9 WASM 的限制 — Task<T> 只支援简单型别（string, int, double 等），不支援 byte[]。 这让 threading + JSExport + byte[] 三者无法同时达成。最务实的做法是移除 WasmEnableThreads，Parallel.For 仍然能编译和执行（在 WASM 单执行绪下退化成循序），这样三种演算法的比较还是有意义的： - Original: 基准（double, scalar） - SIMD: SoA + Vector128 加速 - Parallel: 展示 Parallel.For 在 WASM 的排程开销 ● 建置成功。总结一下现在的状态： 已还原的部分： - C# 方法全部改回同步 byte[] 回传 - JS 呼叫改回同步（移除 async/await） - 移除 WasmEnableThreads 保留的升级： - .NET 9（两个 csproj） - WasmEnableSIMD - COOP/COEP headers（Program.cs） 为什麽 WASM threading 行不通： [JSExport] 的 source generator 不支援 Task<byte[]> 的 marshaling，而启用 threading 後又禁止同步呼叫，形成死结。这是 .NET 9 WASM 的已知限制。 Parallel.For 在没有 threading 的 WASM 环境下会退化成单执行绪循序执行，所以 Parallel 按钮跑出来的时间会 等於或略慢於 Original（因为有 Parallel.For 的排程开销）。这本身也是一个有价值的比较结果。 ﴠ.net 10 有解决这问题吗? ● Web Search(".NET 10 WASM threading JSExport Task byte array SYSLIB1072 2026") ﴠid 1 search in 25s ● Fetch(https://github.com/dotnet/runtime/issues/77157) ﴠ衅eceived 331.5KB (200 OK) ● 没有解决。 这是 .NET runtime 的已知限制，官方标记为 Not Planned（不打算修） 。 问题根源 https://github.com/dotnet/runtime/issues/77157：Task<byte[]>、 Task<ArraySegment<byte>> 等复杂型别在 [JSExport] 的 source-generated marshaller 中不被支援，官方关闭为 Not Planned。 .NET 10 的 WASM threading 现状 根据 https://github.com/dotnet/runtime/issues/68162 和 https://learn.microsoft.com/en-us/aspnet/core/client-side/dotnet-on-webworkers?view=aspnetcore-10.0 ： - [JSExport]/[JSImport] 的 interop 仍然限制在主执行绪 - WasmEnableThreads + WasmBuildNative 在 .NET 10 甚至还有 https://github.com/dotnet/runtime/issues/112926 - WASM 多执行绪仍标记为 experimental 如果真的想在 WASM 跑 Parallel 官方建议的 workaround 是分两次呼叫 — 先取得 Promise，再另外 marshal 资料。 但对我们这种回传大 byte array 的场景不实用。 结论：目前 .NET WASM 要同时做到 threading + JSExport + byte[] 是死路。现阶段 最有价值的比较还是 Original vs SIMD，这两个在单执行绪 WASM 下都能正常跑，而且 SIMD 的 SoA + Vector128 才是真正能带来加速的方向。 ========================================== 使用gpu加速呢? You've hit your limit · resets 5am (Asia/Taipei) 简单来说 一事无成 TOKEN直接被烧光光了.... 然後它觉得好棒棒的SIMD法比原始方式慢了将近10倍 我不怪Claude Code 这种东西本来就跟训练样本有关 我只是没想到TOKEN烧这麽快.... 其实WASM加速的ISSUE跟GPU遇到的障碍有一部分很像 主要是 记忆体搬迁交换 PACK UNPACK的成本高 然後WASM 的 SIMD Parallel WebGpu 加速技术好像还充满很多不确定性 AOT目前 .NET 8後应该算成熟了 具体快多少 我是不太清楚 至少编译过没问题 跑没问题 然後SIMD优化问题 真的只能自己设计 想钻研的 可以参考 https://github.com/erspicu/LanczosWasmDemo 照这种烧token的速度 我可能宁可退回gemini cli --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 182.233.248.16 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1771094133.A.246.html