这个研究有点不寻常，但是有时候可能也挺有用的
LLM4Decompile: Decompiling Binary Code with Large Language Models（使用大型语言模型反编译二进制代码）#ai#
- LLM4Decompile是致力于反编译的开创性开源大型语言模型。其当前版本支持将 Linux x86_64 二进制文件（从 GCC 的 O0 到 O3 优化级别）反编译为人类可读的 C 源代码。该项目组致力于扩展该工具的功能，并不断努力纳入更广泛的架构和配置。
- HumanEval-Decompile是第一个反编译基准测试，重点评估反编译代码的可重新执行性方面。它是 HumanEval 数据集的 C 语言改编版，提供了一套 C 解决方案和断言来评估反编译代码的实际效用。
论文：arxiv.org/abs/2403.05286v1
项目：github.com/albertan017/LLM4Decompile
论文摘要：
反编译的目的是将编译后的代码恢复为人类可读的源代码，但在名称和结构等细节上遇到了困难。大型语言模型 (LLM) 显示了编程任务的前景，激励其应用程序进行反编译。然而，不存在任何用于反编译的开源LLM。而且，现有的反编译评估系统主要考虑token级别的准确性，很大程度上忽略了代码的可执行性，而这是任何程序最重要的特征。
因此，我们发布了第一个开放获取的反编译LLM，范围从1B到33B，在40亿个C源代码和相应的汇编代码上进行了预训练。开源LLM可以作为该领域进一步发展的基准。
为了确保程序评估的实用性，我们引入了 Decompile-Eval，这是第一个考虑反编译可重编译性和可重执行性的数据集。该基准强调了从程序语义角度评估反编译模型的重要性。实验表明，我们的LLM4Decompile能够准确反编译21%的汇编代码，比GPT-4提高了50%。
#ChatGPT[超话]#
LLM4Decompile: Decompiling Binary Code with Large Language Models（使用大型语言模型反编译二进制代码）#ai#
- LLM4Decompile是致力于反编译的开创性开源大型语言模型。其当前版本支持将 Linux x86_64 二进制文件（从 GCC 的 O0 到 O3 优化级别）反编译为人类可读的 C 源代码。该项目组致力于扩展该工具的功能，并不断努力纳入更广泛的架构和配置。
- HumanEval-Decompile是第一个反编译基准测试，重点评估反编译代码的可重新执行性方面。它是 HumanEval 数据集的 C 语言改编版，提供了一套 C 解决方案和断言来评估反编译代码的实际效用。
论文：arxiv.org/abs/2403.05286v1
项目：github.com/albertan017/LLM4Decompile
论文摘要：
反编译的目的是将编译后的代码恢复为人类可读的源代码，但在名称和结构等细节上遇到了困难。大型语言模型 (LLM) 显示了编程任务的前景，激励其应用程序进行反编译。然而，不存在任何用于反编译的开源LLM。而且，现有的反编译评估系统主要考虑token级别的准确性，很大程度上忽略了代码的可执行性，而这是任何程序最重要的特征。
因此，我们发布了第一个开放获取的反编译LLM，范围从1B到33B，在40亿个C源代码和相应的汇编代码上进行了预训练。开源LLM可以作为该领域进一步发展的基准。
为了确保程序评估的实用性，我们引入了 Decompile-Eval，这是第一个考虑反编译可重编译性和可重执行性的数据集。该基准强调了从程序语义角度评估反编译模型的重要性。实验表明，我们的LLM4Decompile能够准确反编译21%的汇编代码，比GPT-4提高了50%。
#ChatGPT[超话]#
嗯，老夫从后端一路干到前端。
来到日本之后，人家看我之前写代码写的比较多。。。
居然让我干起了运维[允悲]
vba也会时不时的学一下[允悲]
对对，还有Excel的公式[允悲]
换一个项目就换一个语言的诅咒再次发威，都不带重样的[允悲]
平时工作中用linux的shell，
但是我最近觉得windows的powershell比较有趣，
虽然工作中用不到，但还是学起来[二哈]
暇つぶしとして実行するんだよ[二哈]
来到日本之后，人家看我之前写代码写的比较多。。。
居然让我干起了运维[允悲]
vba也会时不时的学一下[允悲]
对对，还有Excel的公式[允悲]
换一个项目就换一个语言的诅咒再次发威，都不带重样的[允悲]
平时工作中用linux的shell，
但是我最近觉得windows的powershell比较有趣，
虽然工作中用不到，但还是学起来[二哈]
暇つぶしとして実行するんだよ[二哈]
我试了下微软的 Redis 替代品 Garnet。测试确实如宣传的那样，可以兼容各种 RESP 客户端。而且它是完全基于 Csharp+.NET8 的，自然还继承了它的一些特色：
- 速度和 Redis 几乎不相上下，运行很稳定
- 自行编译变得非常简单，只要安装.NET SDK，一个命令就能编译完成
- 除了 Linux/macOS 外，还原生支持 Windows Server（包括 Server Core 和 NanoServer）
由于官方没有提供 Windows 系统的 docker 镜像，所以我自己搭了一套 CI 流水线，很容易就编译出了一份能够运行在 Windows NanoServer 2022 上的 Garnet 镜像
当然，问题也是有的，就是 Garnet 现在（并且将来也）不支持 Lua 脚本。现在很多系统内分布式锁/事务的已有代码都用来 Lua 来实现，它们并没法无痛迁移到 Garnet。
幸好我自己的项目里并没有这些，都是拿 redis 当缓存和简单的锁来用的，服务器也是Win Server，用 Garnet 替换云上的 redis 其实是比较好的选择。
还有个问题就是当前 .NET 8 里面 IDistributedCache 的 Redis 实现内部用了 Lua 脚本（每一个 Cache 都对应了一个 hash set：图1），导致 asp.net redis 分布式缓存现在是用不了 garnet 的，调用分布式缓存组件就会报错。
所以 Garnet 的开发者跑去给 aspnet 的仓库提了个PR（图2），修改了这部分实现，改成用原生 RESP 命令的方式，已经合并到主分支了。从 .NET9 preview4 开始，Microsoft.Extensions.Caching.StackExchangeRedis 包就可以支持 garnet 了。
我看了下PR里的代码，新的实现其实并没有实现之前 lua 版本的原子性（在原子操作中修改值+延长过期时间），但好在在这个场景下，TTL 只会增加，即使遇到了竞争/多线程的情况，多执行几次也不会出现什么问题（在极短时间内，两次设置 Expire 到同一个时间，应该不是问题吧）。所以问题解决~
- 速度和 Redis 几乎不相上下，运行很稳定
- 自行编译变得非常简单，只要安装.NET SDK，一个命令就能编译完成
- 除了 Linux/macOS 外，还原生支持 Windows Server（包括 Server Core 和 NanoServer）
由于官方没有提供 Windows 系统的 docker 镜像，所以我自己搭了一套 CI 流水线，很容易就编译出了一份能够运行在 Windows NanoServer 2022 上的 Garnet 镜像
当然，问题也是有的，就是 Garnet 现在（并且将来也）不支持 Lua 脚本。现在很多系统内分布式锁/事务的已有代码都用来 Lua 来实现，它们并没法无痛迁移到 Garnet。
幸好我自己的项目里并没有这些，都是拿 redis 当缓存和简单的锁来用的，服务器也是Win Server，用 Garnet 替换云上的 redis 其实是比较好的选择。
还有个问题就是当前 .NET 8 里面 IDistributedCache 的 Redis 实现内部用了 Lua 脚本（每一个 Cache 都对应了一个 hash set：图1），导致 asp.net redis 分布式缓存现在是用不了 garnet 的，调用分布式缓存组件就会报错。
所以 Garnet 的开发者跑去给 aspnet 的仓库提了个PR（图2），修改了这部分实现，改成用原生 RESP 命令的方式，已经合并到主分支了。从 .NET9 preview4 开始，Microsoft.Extensions.Caching.StackExchangeRedis 包就可以支持 garnet 了。
我看了下PR里的代码，新的实现其实并没有实现之前 lua 版本的原子性（在原子操作中修改值+延长过期时间），但好在在这个场景下，TTL 只会增加，即使遇到了竞争/多线程的情况，多执行几次也不会出现什么问题（在极短时间内，两次设置 Expire 到同一个时间，应该不是问题吧）。所以问题解决~
✋热门推荐