今天看到有人在讨论，为啥不让AI直接生成机器码，省去中间商编程语言
想起我们之前在 OpenDAL 社区查过的一个问题
最开始的表象是在 Linux 下特定 AMD 型号处理器（或者说是民用产品线上）Rust 读取文件的速度比 Python 更慢
后面我们用 C 复现了类似的问题
然后我们发现更近一步的现象是如果你读取文件（这里是使用 mmap ）是按照 4K 对齐的情况下，特定 AMD 处理器会比不对齐的情况下更慢（而且不对齐是一个特定的 range，即如果不对齐超出这个 range ，那么两者一样快）
然后我们更进一步调查发现这实际上和一个特性有关，早些年 Intel 引入了一个特殊的特性叫 FSRM， aka Fast Short REP MOVSB，简而言之引入了一个特殊指令，叫 rep movsb ，简而言之是一个正向的功能，可以让大量数据拷贝可以放在一个指令内完成
Linux 在 2020 年在内核支持了这个功能 ，FYI github.com/torvalds/linux…
但是问题就在这，在 AMD 特定的 CPU 实现上的微码实现有问题，导致这个指令的效率极低，反而劣化了性能
这个问题直到现在都没修复。
而微软内部很早之前就知道这个问题，并在内部选择关闭了 FSRM for AMD
但是 Linux 社区还是开启的
在我们发现这个问题之前，你在互联网上基本上找不到讨论这个的资料，或者说你现在看到的关于这个问题的讨论与资料基本上可以上溯到我们这次工作。
这个时候如果你写一些底层 code，让 LLM 来优化，那就是非常有了
还是那句话 LLM 对于大部分资料都在水下，没法公开或者领域特化的，就是一坨
Welcome to OpenDAL：github.com/apache/opendal…
https://x.com/i/status/2015834452489097682
想起我们之前在 OpenDAL 社区查过的一个问题
最开始的表象是在 Linux 下特定 AMD 型号处理器（或者说是民用产品线上）Rust 读取文件的速度比 Python 更慢
后面我们用 C 复现了类似的问题
然后我们发现更近一步的现象是如果你读取文件（这里是使用 mmap ）是按照 4K 对齐的情况下，特定 AMD 处理器会比不对齐的情况下更慢（而且不对齐是一个特定的 range，即如果不对齐超出这个 range ，那么两者一样快）
然后我们更进一步调查发现这实际上和一个特性有关，早些年 Intel 引入了一个特殊的特性叫 FSRM， aka Fast Short REP MOVSB，简而言之引入了一个特殊指令，叫 rep movsb ，简而言之是一个正向的功能，可以让大量数据拷贝可以放在一个指令内完成
Linux 在 2020 年在内核支持了这个功能 ，FYI github.com/torvalds/linux…
但是问题就在这，在 AMD 特定的 CPU 实现上的微码实现有问题，导致这个指令的效率极低，反而劣化了性能
这个问题直到现在都没修复。
而微软内部很早之前就知道这个问题，并在内部选择关闭了 FSRM for AMD
但是 Linux 社区还是开启的
在我们发现这个问题之前，你在互联网上基本上找不到讨论这个的资料，或者说你现在看到的关于这个问题的讨论与资料基本上可以上溯到我们这次工作。
这个时候如果你写一些底层 code，让 LLM 来优化，那就是非常有了
还是那句话 LLM 对于大部分资料都在水下，没法公开或者领域特化的，就是一坨
Welcome to OpenDAL：github.com/apache/opendal…
https://x.com/i/status/2015834452489097682
Comments
Be the first to add a comment
Log in to comment