这种智能是不是 写死了很多编译优化的规则，相当于很多 if else 的判断，然后去掉某些或者增加了针对性的代码转化功能，说到底是不是 都是体力活？ 如果核心人员都 不干了，岂不成屎山代码了？

因为我感觉现在大模型调用工具链，就是脱裤子放屁，太容易成屎山了，如果大模型解析的匹配函数和参数不对，你得搞一堆防御异常的处理，纯纯体力活，是个歧路。
--
FROM 14.154.1.*

虽然我没有做过编译器，但是看一些文章，编译器优化还真的就是体力活，没有太多技术含量，都是工程实践中一点一点经验的积累。这种历史很长的工程，代码可读性肯定好不了，但是也看维护者的技术水平，我们公司的代码30多年了，可读性还撮合吧。据说Oracle的代码非常糟糕，网上还有人专门说过，改一个bug需要几个月。



【 在 Algoquant 的大作中提到: 】
: 这种智能是不是 写死了很多编译优化的规则，相当于很多 if else 的判断，然后去掉某些或者增加了针对性的代码转化功能，说到底是不是 都是体力活？ 如果核心人员都 不干了，岂不成屎山代码了？
: 因为我感觉现在大模型调用工具链，就是脱裤子放屁，太容易成屎山了，如果大模型解析的匹配函数和参数不对，你得搞一堆防御异常的处理，纯纯体力活，是个歧路。
:
--
FROM 183.199.185.*

这么夸张的吗

【 在 foliver 的大作中提到: 】
: 大系统下，这很正常。
: 曾经我们改了一行代码，然后请了牛人评估了相关影响，觉得没有问题。
: 结果到了现场运行一段时间就整个系统崩溃了。
--
FROM 114.254.115.*

请教几个比编译优化更具技术含量的项目来

【 在 buildtolast 的大作中提到: 】
: 虽然我没有做过编译器，但是看一些文章，编译器优化还真的就是体力活，没有太多技术含量，都是工程实践中一点一点经验的积累。这种历史很长的工程，代码可读性肯定好不了，但是也看维护者的技术水平，我们公司的代码30多年了，可读性还撮合吧。据说Oracle的代码非常糟糕，网
: 匣褂腥俗潘倒囊桓鯾ug需要几个月。
--
FROM 71.198.4.*

最近遇到过一例优化， 确实水平挺高
类似于a*2+b循环N次， 给优化成了a*4+3b 循环N/2次， 循环unroll后，可以节省近一半的alu指令
就不是清楚是怎么做的， 靠规则的话，那编译器同学挺辛苦的

【 在 lookforit 的大作中提到: 】
: 很多年前，就听说编译器比绝大多数汇编程序员水平高了
--
FROM 117.35.158.*