你用到了 sin 、cos 、sqrt 等库函数，这些函数 Python 应该是调 C 库对应的函数。C 库是平台相关的。

维基那张图上不仅有差半个小时的时区，还有差四分之三个小时的 ...

现在一般都喜欢看这个 https://www.backblaze.com/b2/hard-drive-test-data.html

主题说放到 UI 里面，我不是很清楚具体是怎么一个用法
比如你做图标的话就直接调好参数渲出来就行了，我头像就是个 3D 模型渲染图。
理论上你还可以转成 SVG ，不过没试过。

直接在现有的 UI 里面渲染 3D 模型，除了 DCC 和游戏之外我能想到的就只有用于作为“主展示区”一种用途，比如电商预览商品，或者苹果之前搞得什么 Memoji （当然还有更冷门的 3D UI 和 AR 之类的，那是另一个话题）。

首先你要了解实时渲染一个模型，并且渲染得好看，不是那么容易的事情。Cycles 渲染出来可以比较精致，但是那需要大量的计算量堆起来，游戏可以做得看上去真实，但是需要使用各种乱七八糟的算法+稍微少一点的算力，不用现成的渲染引擎的话，灯光、阴影、反射、全局照明、表面凹凸、动画之类的都需要逐个实现（而现成的渲染引擎一般不小）。
所以如果可以的话用 2D 图（或者 2D 图序列）要比实时渲染 3D 好做，而且处理 2D 图更方便，更灵活。你在电影和游戏里面看到的许多东西其实不是模型渲染出来的，是后期合成加上去的。简单裸写实时渲染能写到什么程度，你可以以“opengl beginner demo”为关键字搜索。

然后是把模型导出成一个文件，一般每个 DCC 有自己的文件格式，比如 Blender 是 .blend ，Maya 是 .ma 和 .mb 。这种文件一般没法直接用，因为他是根据 DCC 的需求来设计的。业界有若干种比较通用的格式用来 interoperate：Wavefront OBJ ，非常古老又非常简单的一种格式，因为完全是文本，很简单就能写个 parser 。3DS ，老 3D Studio 的格式，也很老（从这货单个 mesh 限制 65536 面你就大概能民白发生了什么 ...）。FBX ，后来自动麻将桌重新弄来的一个格式，所有自动麻将桌产品都支持，实际上非自动麻将桌软件也支持。COLLADA 和 glTF ，俩 Khronos 的开放标准，我没咋用过，具体好不好用要看软件支持情况。Alembic ，VFX 现在的业界标准。
不过这些主要是作为转换的中间格式，渲染引擎可能会直接支持这种中间格式，也可能有自己的专有格式。这里的问题其实主要还是 DCC 和渲染引擎支持的功能可能是完全不同的，两边的语义并不对应，而中间格式作为一个类似 LSP 一样的角色更没办法完美耦合这两者。

最后是渲染引擎。现在主要实用中是使用 GPU 渲染（ CPU 渲染并不是没有用，据说 ZBrush 就是 CPU 渲染）。GPU 渲染依赖于使用特定的 API 调用 GPU 中的相关专用硬件（当然理论上你也可以使用 GPGPU 来模拟这一过程，不过这依然是非主流做法，能写 CPU 渲染器或者 GPGPU 渲染器的大概不会问这个问题）。目前图形 API 发展大致可以分成三个阶段，第一个阶段是完全固定的原始阶段，只能按照硬件设定好的方式去渲染，程序员只能调几个参数；第二阶段是从 D3D8 ，GL1.4 开始引入 shader 之后的可编程阶段，程序员可以对 GPU 编程来自定义渲染过程，大大增强了灵活性，并且派生出很多意想不到的应用（包括最原始的 GPGPU ）；第三阶段是从 Mantle 开始，以 D3D12 ，Vulkan 和 Metal 为代表的将更多 GPU 底层细节开放给开发者，并全面支持多线程的低开销阶段，但是写起来就跟汇编一样，太麻烦。

从目前情况来看，第一阶段的已经彻底淘汰，第二阶段的总体支持较好，第三阶段一些老硬件和老软件不支持，并且由于比较底层，需要折腾的东西比较多。所以现在入门的话推荐从第二阶段开始，需要注意的是如果不考虑性能和具体实现的坑的话，理论上第二阶段和第三阶段 API 的渲染能力，以及不同厂商 API 的能力是一样的，只是调的接口不太一样，因为算法是你自己写的，所以出来的结果只取决于你程序怎么写。

楼主问这三个平台有没有通用的技术，首先仨平台的开发语言就不一样，Android 和 iOS 好歹还都能用 C/C++，Web 直接锁死了 JavaScript 。API 支持方面，Android 可以支持 GLES 和 Vulkan ，但是鉴于 Android 大区优秀的设备和驱动支持情况，Vulkan 貌似现在总体还不是很稳定，iOS 也支持 GLES ，不过是 deprecate 状态，现在推荐 Metal ，Web 是基于 GLES2 的 WebGL ，这个属于第二代 API 中比较老的一种了，还有比较新的基于 GLES3 的 WebGL2 ，这个其实依然比较老 ... 但是最近两年才得到全面支持，对应第三代 API 的 WebGPU 现在貌似有安全问题难产，现在 Web 连做 GPGPU 都得用十多年前的老 trick ...
所以 API 层面大概能统一到 GLES2 或者 GLES3 这个层面，语言还是得自己想办法。由于很多程序需要支持很多硬件和软件，而不同的 API 能力是差不多的，为了解决 API 支持问题，一般会做一个通用的接口将他们抽象掉，应用不依赖于底层 API 。比如 bgfx 就声称支持各种平台和各种 API （在 Web 使用 Emscripten 解决）。另外个别情况下还会涉及到的一种做法是不同 API 之间互相转换，比如 Apple 强推 Metal 不做 Vulkan 支持，有个 MoltenVK 项目是用 Metal 实现 Vulkan API 。这个 Linux 和开放社区玩得最欢，有用 D3D/Vulkan/Metal 实现 GLES 的 ANGLE ，用 Vulkan 实现 GL 的 Zink ，Vulkan 实现 D3D 的 DXVK 和 vkd3d 。微软还给 WSL 搞了个 D3D12 实现。
当然，这些 API ，无论是哪个阶段，都属于用户所能直接接触的最底层 API （注意 Console 不包含在内，Console 是单独的一个故事），总是非常底层的，也就是不存在调一个函数就帮你把模型渲染出来这种事情。所以再上层还会做一个抽象，实现类似“调一个函数把模型渲染出来”的效果（实际依然没那么简单，渲染一个模型需要考虑投影、灯光、材质、半透明等各种问题，只是这些问题直接用底层 API 来处理只会更麻烦），这才有 Ogre ，OpenSceneGraph ，Three.js 等。
Unity 之类的游戏引擎是比较高层的抽象，因为一般“游戏”是一种各方面都比较特殊的应用，就连 iOS App Store 对游戏也有不同的审核要求。特别是公开可用的游戏引擎，大多会有广泛的平台支持需求，以及 Console 支持的需求（不过相关的东西应该要 NDA ）。in-house 的则是各有各的需求。一般游戏引擎会做成“框架”式的东西，也就是他会直接接管你的整个程序，想要把一个游戏引擎和另外的应用集成起来可能成本会比较高。我认为可能的 sweet spot 还是在上一层，也就是渲染引擎上。

@villivateur Code Review 这个过程本身和 VCS 工具，或者任何的外部工具没有必然关系啊 ... 就是你把一个 patch （或一组 patch ） share 给一组人，然后一起讨论改进的过程（也可以有机器跑一些自动化的流程），工具只是帮助 streamline 这个过程

要说工具的话，https://en.wikipedia.org/wiki/List_of_tools_for_code_review 这里面不是有不少工具声称支持 SVN 。我知道的里面 Phabricator 前段时间停止开发了，然而一些知名开源项目例如 Blender 和 LLVM 之类的目前还是在用，当然这俩现在都用 Git ，但是比如 LLVM 也是最近才完全用 Git ，之前好像有段时间是 Git 和 SVN 并用，再之前应该是 SVN 。这个上古 patch https://reviews.llvm.org/rL237708 现在打开 URL 会被 301 到一个 Git 的 Commit ID ，但是 commit message 还保留着 SVN 的 revision number 。Review Board 现在还在开发，应该也比较靠谱。然后我也是刚发现这页面里面甚至还有 GvR 的一个副业 Rietveld ，我没用过这东西，但是我用过它的 fork Gerrit （只支持 Git ），AOSP 和其他的一票 Google 项目好像也在用。

人家 Linux Kernel 和 GCC 用 mailing list 都好好的 ...

Windows 不也有这问题，也没折腾什么容器之类的，都有“绿色软件”之类的，搞一个猴版不就行了。我也用 RHEL ，不过没 root 不好折腾，解决方案：依赖一个一个下下来，一个一个编译，手动打一份“包”，哪台机器要用就解压到哪。
无非就是 Windows 东西都给你编译好了，Linux 需要你自己去编译。

大部分软件还好，依赖就这么多。个别巨型项目如浏览器内核和游戏引擎会涉及巨量依赖，不过还好我不搞这个（浏览器内核一般做得都很现代很炫酷很时髦，依赖需要你自己解决。游戏引擎大多不属于开源生态圈，比较实在，人家都直接把依赖的 binary 放 repo 里面的 ...）。

说起这个，我有个老机器，用老 Chrome ，开 steamcommunity.com 很卡。看了下发现只要我一动页面，整个网页都会重绘，CSS 把背景图关了就好了

简单，不就是摆 pose 么，把墙挖个洞，放个人进去摆就行了。

代码检视是什么奇葩翻译，还是说你想说的其实是 Code Review ？
没用过 SVN ，SVN 不能做 review 么？

另外 ZFS 在性能方面的 story 我一直不是很清楚，特别是在 NVMe 设备上的表现。可能可以做到比较好的性能，但是需要专门去调整。我没这本事，所以如果对性能有要求的话我不会用 ZFS 。

RAID 是为了提高可用性，备份是为了数据安全。

而且 Mac 逐渐 Apple Silicon 化之后，长期 x86 的 macOS 怕不是会变成比 GNUstep 还拉跨的东西
我现在就等着哪个秀儿把 Houdini 用在 macOS 上

Arch Linux 用户，个人项目需要，现在后台就开着一个 OSX-KVM 的 Bug Sur （其实还有一个 Win10 ，直接占掉我一半内存）

如果是偶尔用用或者是只用 CLI 跑测试那还凑合，因为 GPU 是软件模拟的，GUI 使用体验并不好。最明显的是最小化或恢复窗口的时候的特效根本渲染不出来，本来这个我也无所谓的，问题是他直接会把 GUI 卡住五秒，鼠标指针都不能动，而且还不知道如何禁用。这个大概是根本没有测试过这种情况，除此之外应该说老 OS X 底子还在，GUI 大多数的表现其实都是好于预期的，Launchpad ，Mission Control 之类的都没有明显问题，当然不管什么地方的帧率肯定都是比较怀旧的（和你分辨率也有关系，分辨率高了照样卡得不能用）。

大概半年前试过给一个 USB port 连 iOS 设备，未成功，可能是要单独 passthrough 一个 USB Controller 才可以。

喷气脑子敢另起炉灶，必须说勇气可嘉。要是 runtime 能比 Electron 小的话还是有点兴趣，能好一点就行。
毕竟看官网，这东西也是要对标“IDE”的，VSCode 可没这种 claim 。同时还要做得“light”，所以如果真的能以 VSCode+Electron runtime 的体量，做出比 VSCode 完善的功能，技术上依然是严格的提升，收费也无所谓，毕竟没那家底。
不过插件生态可能是个问题，虽然我也用不着几个插件。

另外至少 LLVM ，在个别情况下会借用 RBX 做一个特殊的 base pointer ，还没研究透 ...

这是 alignment 要求不大于 16 bytes 的情况，有时会要求大于 16 bytes 的 alignment ，通常是有 local 有相关的要求。

这时由于编译器只能保证 stack 最开始 align 到 16 ，就会插一个 and 来实现。

最近正好在搞 stack frame 相关的东西，有点上头

你这个应该是因为你这个函数不是 leaf function ，还会 call 别的函数，AMD64 SysV ABI 要求 call 函数时 stack 必须 16-byte align 。

现在你知道调用 call P 时是 16-byte align 的，call 会 push 一个 RIP 进去，就变成了 8-byte align ，prologue 又 push 了俩 64-bit GPR ，还是 8-byte align ，L7 还要个 call ，想要 16-byte align 就得再 pad 8-byte 。

感觉这种注释太花，也就文件头 license 声明有点用，其他地方用处不大。

单行最大长度限制之类的倒是很常见，还见过有的要求在没行注释之前加 * 之类的符号的（常见于 C99 之前的 C 项目 ...），这种一个 formatter 基本搞定

对于 macOS 而言，这些东西不属于它提供的“核心体验”，有没有都无所谓的
话说不知道 Windows 现在还带不带 Windows Script Host 了。现在什么 Ruby Perl 啊都过气了，JavaScript 才是当红炸子鸡，当年 Windows 可是老早就自带了