Copilot 不知道，但是 Codeium 有类似的东西：
codeium.com/blog/context-aware-everything-more-advanced-realtime-context-than-github-copilot Context Aware Everything: More Advanced Realtime Context than GitHub Copilot
codeium.com/blog/codeium-context-pinning-launch Context Pinning
codeium.com/blog/personalization-context-awareness-vs-customer-specific-finetuning Personalization: Context Awareness vs Customer-Specific Finetuning
codeium.com/blog/user-personalization-for-llms User Personalization, the Next Frontier in LLMs

感觉主要还是 RAG 变体，结合代码库中的一些固定结构

看到备战黑神话悟空就想起几年前的备战 2077 ... 不过那一波还好，显卡买到手不亏

我觉得上个帖子 #25 说得很有道理，楼主先把光纤埋好，这玩意便宜。

然后要 10G 的话，主工作站和 NAS 先连一下（还得是固态 NAS 才有意义，或者也可以试试超大内存做 HDD 缓存 ...），一对网卡就行，主网络可以暂时保持 2.5G
因为实际上能用到 10G 带宽的设备并不多，WiFi 设备全都用不上，电视也用不上，预算受限就放在最重要的地方
不过我觉得楼主主要是折腾需求，虽然把我觉得上面这一堆折腾完就挺折腾的了 ...

@yunv2
#6 这个可以挖一挖：给两边准备同样的虚拟机 Linux 镜像与相同版本的虚拟机软件跑编译，结果是怎样的，依然是 7840H 比 5700G 慢么？

SD 和 LLM 这两个需求其实是不一样的
LLM 看个人需求，跑得快当然好，有的场景慢一点也无所谓
但是 SD 实际使用中需要迭代调参才能试出相对满意的结果，这种情况下能快速推理生成预览是非常有用的
就像过去 3D 建模调材质，CPU 渲染很慢影响效率，但是后来 CPU 核数上来了，又可以用 GPU 硬件加速光追，效率指数级上升

美国有可能会禁掉中国的 swift ，自己看着办吧

我怎么感觉如果这是 C/C++ 的代码的话，主楼原本的写法就挺好的 ...

Code Interpreter 不知道，但是 Function Calling 的能力的话，一般认为 OpenAI 是对其模型进行了专门训练才能达到如此的效果。开源模型如果没经过类似的训练的话只能在 Prompt 上做手脚，结合限制输出 token 的手段。目前 Llama 系列官方模型都没有 FunctionCalling 的训练。
github.com/MeetKai/functionary MeetKai/functionary: Chat language model that can use tools and interpret the results 这里倒是有个原生支持 Function Calling 的

www.youtube.com/@AppleProgramming AppleProgramming - YouTube
油管上的老哥，教程从 C 出到 ObjC 再过渡到 Swift

8B 的跟 GPT-4 比不太现实吧，至少得 70B 那个，后面还有 400B 的

@moonjourney 我不是说个别包里的个别 hack ，而是 nix 的整个 approach 像个 hack

ARK 上 QSV 是有的 www.intel.com/content/www/us/en/products/sku/80917/intel-xeon-processor-e31226-v3-8m-cache-3-30-ghz/specifications.html Intel® Xeon® Processor E3-1226 v3
可以多试几个软件看看

不同 distro 方向不同不能比较
比如对我更有吸引力的可能是 CachyOS 和 Clear Linux 这种

Nix 的问题我觉得是 UNIX 生态下很多程序是依赖于这套文件系统的，强行变成另一种模式让人觉得这玩意是一个巨大的 hack ，反而不 cool 了，所以我试了两天就不再用了。

@FightPig
说的是这个 world.hey.com/dhh/fonts-don-t-have-to-look-awful-on-windows-564c9d2f Fonts don't have to look awful on Windows 还有这个 twitter.com/dhh/status/1762595923857903860 DHH on X: "That crazy 8K Dell monitor came in, and the text is so fucking crisp, it's hard to convey in words. Substantial step up over the 6K Pro Display. But... there's a caveat. It basically doesn't work in dark mode. The thing is a mirror. Is this good enough to give up on dark mode? " / X ？

他的意思应该是 Retina 级别就可以了，他是先用的 Pro Display XDR ，然后觉得很不错，换了 8k 之后更好了由奢入俭难了。这个和楼主的看法是相反的，DHH 认为硬件到了一个 baseline 之后下两边是没啥差距的。对于桌面系统这个 baseline 就是苹果惯用的 218 dpi 左右（即 27 寸 5K ，32 寸 6K ），不难发现现在 PC 主流的 HiDPI 硬件比这个低了至少一个等级，但是还没到 8k 那么夸张。

不过这个说法也就仅供参考，毕竟他还说：
> I just spent last week using a PC on a 27" 4K monitor (163 PPI) where I accidentally committed the other common cardinal sin that make fonts look like shit on any system: Fractional scaling. I had the screen set to 150%. No wonder it looked offensively bad compared to the Mac! You can't split a pixel, so the system has to do all sorts of typographically nasty tricks when doing non-integer scaling, and the end result is awful font rendering.

我是看不出 fractional scaling 和字体渲染之间有啥必然联系，正确实现的 fractional scaling 不需要在字体渲染级别 split a pixel 。结合他给出的引用，他很有可能搞混了 fractional scaling 和 subpixel rendering 。

每个 ISA 都有自己的坑，不好说哪个编译起来更复杂。同一个编译器，不同后端下的功夫也不一样，你可以只做最基本的指令选择寄存器分配，不做优化，就说我编译没编译吧。就不说不同编译器版本和编译选项的坑了。这个还可以套娃：就是你编译器本身是怎么编译的？就不说拿 -O0 的编译器来跑这种老六行为，就现有主流编译器，过一遍 LTO+PGO 或者 post-link optimization 就能有两位数百分点的提升。

最好还是统一编译到同一架构来比较。
而这个图压根没有给出任何相关信息，作为性能比较是不合格的。


@agagega #6
> 编译时间绝对大头肯定是优化，这部分和目标平台没啥关系。
感觉真不一定，几个重量级：C++，Rust ，Haskell ，Scala

@james122333 他说的是不用折腾。
这也是 macOS 和 Windows 的问题——没有给出选择。HiDPI 下还不太明显，老设备下就各有各的问题了。

之前 OS X 的 System Preferences 里面有个 “Use LCD font smoothing when available”的选项，应该是影响是否使用 subpixel rendering ，打开之后会显著增强视觉字重，对就很类似 #23 那种胖了一圈的感觉。根据网上说法，macOS 后来不知道在什么版本里面，把 subpixel rendering 整个砍了，这个选项也没了，但是 defaults 里面还在，效果变成了让字体自动加粗一圈，但是这是两年前的说法，新版可能又不一样了，反正我复现不出来。
但是 anyway ，两个系统的 hinting 都是不给调的。

你给的这个配置 hinting 看上去直接满了，应该是更偏向 Windows 那种的。虽然我记得 KDE 好像默认就是这个风格，不过本贴里大部分人估计不怎么喜欢。不过问题就是，你不让用户配置就有一半用户不喜欢，你让用户配置用户就嫌麻烦。
而且我这 Qt 和 GTK3/4 程序的字体渲染好像有明显的不一致，这个倒是更加严重的问题 ...

@zhwguest 不是说"goto 导致反编译失败"，所有 control flow 到字节码里面都是 goto ，只是反编译器能不能从 goto 里面还原出原来的 control flow 来。

淘宝的生态位是多样性，鱼上甚至有卖光刻机零件的，真不真不知道，但是作为这一特色的极端体现，看个乐子还不错

大牌和爆款，确实京东和拼多多好，问题是这个世界不是只有大牌和爆款的
我估摸着淘宝自己也没搞清楚自己的核心竞争力在哪，体验也没见变好，他要硬跟其他两家拼我不觉得有胜算，以阿里的效率，光靠利基市场能不能养活自己也难说

逻辑可能是 locality ，你频繁使用的服务器能记住图标，不频繁使用的去找一下问题也不大，节省了 screen real estate
不过我本来用得就不多，我觉得 Discord 除了 Server-Channel 这个二级 hierarchy 的设计之外其他都挺烂的

改改 CSS 可能能部分解决