Compare commits
8 Commits
sgx
...
d2e6ecbeba
| Author | SHA1 | Date | |
|---|---|---|---|
| d2e6ecbeba | |||
| 3638457aa6 | |||
|
|
e2b50e2188 | ||
|
|
3870b9720b | ||
| a490b98cba | |||
| dcd05056db | |||
| 55e4b8dbb0 | |||
| c3fc09ece7 |
@@ -271,11 +271,11 @@ function sidebarCompiling(): DefaultTheme.SidebarItem[] {
|
||||
link: '/src/compile/why-distributed-compiling'
|
||||
},
|
||||
{
|
||||
text: 'CloudBuild',
|
||||
text: 'CloudBuild分布式编译',
|
||||
link: '/src/compile/cloudbuild'
|
||||
},
|
||||
{
|
||||
text: 'ShareBuild',
|
||||
text: 'ShareBuild共享编译',
|
||||
link: '/src/compile/sharebuild'
|
||||
},
|
||||
]
|
||||
|
||||
@@ -1,11 +1,13 @@
|
||||
# 分布式编译系统CloudBuild
|
||||

|
||||
## 为什么需要分布式编译?
|
||||
- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟,所以缩短大型项目的编译时间的分布式编译系统有重要意义
|
||||
- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率,缩短项目编译时间
|
||||
- 在实际开发时,同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译,从而进一步加快编译效率
|
||||
# CloudBuild私有云分布式编译系统
|
||||
|
||||
## CloudBuild的适用场景
|
||||
|
||||
对于大型开发团队,CloudBuild私有云分布式编译系统不仅可以通过分布式编译加速项目编译过程,而且有大量编译任务是相同的,分布式编译缓存可以避免重复编译,从而节约算力消耗,并进一步缩短项目编译时间。
|
||||
|
||||
## CloudBuild QuickStart
|
||||
|
||||
todo
|
||||
|
||||
## 总体架构
|
||||
### 系统总体架构
|
||||

|
||||
- Ninja:客户端,该机器上需要保存有完整的待编译项目源代码。
|
||||
|
||||
@@ -1,80 +1,24 @@
|
||||
# 编译加速
|
||||
|
||||
|
||||
## 分布式编译技术
|
||||
## 分布式编译
|
||||
|
||||

|
||||
|
||||
- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟,所以缩短大型项目的编译时间的分布式编译系统有重要意义
|
||||
- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率,缩短项目编译时间
|
||||
- 在实际开发时,同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译,从而进一步加快编译效率
|
||||
- [为什么需要分布式编译?](/src/compile/why-distributed-compiling)
|
||||
- [CloudBuild私有云分布式编译系统](/src/compile/cloudbuild)
|
||||
- [ShareBuild分布式共享编译工作站](/src/compile/sharebuild)
|
||||
- [以AOSP14项目为例ShareBuild分布式编译详细配置方法](/src/compile/sharebuild-aosp14.md)
|
||||
|
||||
### CloudBuild
|
||||

|
||||
- Ninja:客户端,该机器上需要保存有完整的待编译项目源代码。
|
||||
- Action Cache:服务端缓存,主要保存编译任务的执行结果。
|
||||
- CAS Cache:服务端缓存,主要保存客户端上传的依赖文件,编译结果文件。
|
||||
- Scheduler:任务调度器,将编译任务id分发到各个编译节点。
|
||||
- Redis:主要存储具体的编译任务供编译节点领取执行,也可存储Action Cache和 CAS Cache中的内容加速编译。
|
||||
- MySQL:主要存储编译过程中的任务统计信息。
|
||||
- Executor:各个编译节点
|
||||
|
||||
### ShareBuild
|
||||

|
||||
CloudBuild主程序分为三个部分:Client、Server、Executor。
|
||||
- Client:运行在客户端,和用户对接,用于生成待执行的远程编译任务, 同时也作为本地编译节点执行本地任务。
|
||||
- Server:运行在主服务器,主要用于连接各个编译节点,以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
|
||||
- Executor:运行在编译节点,负责接收并执行编译任务,是编译任务真正执行的地方。
|
||||
## AI编译器
|
||||
|
||||
### 系统分层结构
|
||||

|
||||
todo
|
||||
|
||||
## 运行原理与流程
|
||||
## PGO/LTO编译性能优化
|
||||
|
||||
todo
|
||||
|
||||
### 分布式编译原理
|
||||

|
||||
|
||||
### CloudBuild客户端
|
||||
CloudBuild客户端基于Ninja改造,有下面这些优势
|
||||
- 兼容使用Ninja编译的项目
|
||||
- 使用远程执行的方式提高编译时并发度
|
||||
- 使用编译缓存减少需要编译的任务数量
|
||||
|
||||
### CloudBuild服务端
|
||||
- 使用远程执行的方法提高编译时并发度,实现了任务分发至远程节点同步执行
|
||||
- 使用分布式任务调度提高任务调度效率和计算节点资源利用率,避免集中式调度的任务阻塞问题
|
||||
- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
|
||||
|
||||
### CloudBuild优势
|
||||
- 低成本:组成executor的机器不需要使用专门的高性能计算型机器,可使用多个平价的空闲机器
|
||||
- 高效:CloudBuild实现分布式编译的功能,相比单机大大提升并发度
|
||||
- 兼容Ninja:CloudBuild客户端基于Ninja改造,对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
|
||||
|
||||
### CloudBuild执行流程
|
||||
- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
|
||||
- 服务端:检查任务缓存->检查依赖完整性->调度任务
|
||||
- 编译结点:还原文件目录->还原文件目录->返回编译结果
|
||||
|
||||
## AOSP和LLVM上的应用
|
||||
### LLVM上的应用效果
|
||||

|
||||
### AOSP上的应用效果
|
||||

|
||||
### CloudBuild硬件资源利用率
|
||||
4核CPU利用率:
|
||||

|
||||
8核CPU利用率:
|
||||

|
||||
16核CPU利用率:
|
||||

|
||||
|
||||
## CloudBuild使用方法
|
||||
### CloudBuild安装
|
||||

|
||||
CloudBuild项目地址:https://gitee.com/cloudbuild888/cloudbuild.git
|
||||
### CloudBuild分布式编译
|
||||

|
||||
LLVM项目地址:https://gitee.com/mirrors/LLVM.git
|
||||
|
||||
|
||||
|
||||
|
||||
68
src/compile/sharebuild-aosp14.md
Normal file
68
src/compile/sharebuild-aosp14.md
Normal file
@@ -0,0 +1,68 @@
|
||||
# 以AOSP14项目为例ShareBuild分布式编译详细配置方法
|
||||
|
||||
## ShareBuild的适用场景
|
||||
|
||||
在同一局域网内工作的小型团队,ShareBuild以P2P共享架构将空闲算力贡献给团队其他成员,从而为每个团队成员提供编译加速效果。
|
||||
|
||||
## ShareBuild QuickStart
|
||||
|
||||
* 同一个局域网内的A、B、C等所有节点上安装ninja2:
|
||||
|
||||
```
|
||||
wget -c https://raw.githubusercontent.com/ninja-cloudbuild/ninja2/refs/heads/main/install.sh && chmod +x install.sh && sudo ./install.sh
|
||||
```
|
||||
|
||||
* 启用ShareBuild的前置要求
|
||||
|
||||
1. 所有节点上均安装配置好了项目的编译环境,即所有节点上均能采用ninja成功单机编译项目。
|
||||
<!--
|
||||
|
||||
2. 选择任一节点上作为项目开发环境,项目中使用.devcontainer/devcontainer.json 配置了image镜像(示例如下),依次镜像创建的开发容器中能采用ninja成功单机编译项目。
|
||||
|
||||
```
|
||||
{
|
||||
"name": "DevContainer",
|
||||
"image": "devstar.cn/devstar/DevContainer:latest" # 仅作示例,务必使用您已安装配置好项目编译环境的容器镜像!
|
||||
}
|
||||
```
|
||||
> 注意:以上两种方式二选一即可,第2种方式省掉了在其他节点上安装配置项目编译环境,但是首次ShareBuild模式分布式编译时其他节点会自动下载项目编译环境的容器镜像。
|
||||
-->
|
||||
|
||||
* 选择任一节点上作为项目开发环境,开启ShareBuild模式,然后进行分布式编译。
|
||||
|
||||
项目根目录下创建ninja2.conf 文件如下即可开启ShareBuild模式:
|
||||
```
|
||||
sharebuid:true
|
||||
```
|
||||
这时使用ninja编译将自动进入ShareBuild模式分布式编译项目。
|
||||
|
||||
> 如果直接使用ninja命令编译项目,也可以加上-s参数表示启用ShareBuild模式,示例如下:
|
||||
```
|
||||
ninja -s -r `realpath ../` #启动分布式编译,注意-r 指定项目根目录
|
||||
ninja -t clean #清除编译产物
|
||||
````
|
||||
|
||||
* 对一些特殊项目的补充说明
|
||||
|
||||
除以上常规的ShareBuild配置外,对于一些特殊项目需要做一些额外的配置,补充说明如下:
|
||||
|
||||
## 使用ShareBuild编译Android开源项目(AOSP)
|
||||
|
||||
除按照以上方法准备好编译环境和开启ShareBuild模式外,以AOSP14项目为例,还需要替换ninja和准备.sharebuild.yml来过滤掉一些无法远程编译的命令,具体操作如下:
|
||||
|
||||
```
|
||||
cp /usr/bin/android_ninja prebuilts/build-tools/linux-x86/bin/ninja
|
||||
cp /etc/ninja2/aosp14/.sharebuild.yml ./
|
||||
```
|
||||
|
||||
然后就可以单机编译一样使用make命令来分布式编译Android开源项目(AOSP)。
|
||||
<!--
|
||||
## 使用ShareBuild编译鸿蒙开源项目(OpenHarmony)
|
||||
|
||||
todo
|
||||
-->
|
||||
## 版权声明
|
||||
|
||||
Copyright @ Mengning Software
|
||||
|
||||
梦宁软件(江苏)有限公司 版权所有
|
||||
@@ -1,79 +1,74 @@
|
||||
# 分布式编译系统ShareBuild
|
||||

|
||||
## 为什么需要分布式编译?
|
||||
- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟,所以缩短大型项目的编译时间的分布式编译系统有重要意义
|
||||
- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率,缩短项目编译时间
|
||||
- 在实际开发时,同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译,从而进一步加快编译效率
|
||||
|
||||
## 总体架构
|
||||
### 系统总体架构
|
||||

|
||||
- Ninja:客户端,该机器上需要保存有完整的待编译项目源代码。
|
||||
- Action Cache:服务端缓存,主要保存编译任务的执行结果。
|
||||
- CAS Cache:服务端缓存,主要保存客户端上传的依赖文件,编译结果文件。
|
||||
- Scheduler:任务调度器,将编译任务id分发到各个编译节点。
|
||||
- Redis:主要存储具体的编译任务供编译节点领取执行,也可存储Action Cache和 CAS Cache中的内容加速编译。
|
||||
- MySQL:主要存储编译过程中的任务统计信息。
|
||||
- Executor:各个编译节点
|
||||
|
||||
### 部署示意图
|
||||

|
||||
CloudBuild主程序分为三个部分:Client、Server、Executor。
|
||||
- Client:运行在客户端,和用户对接,用于生成待执行的远程编译任务, 同时也作为本地编译节点执行本地任务。
|
||||
- Server:运行在主服务器,主要用于连接各个编译节点,以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
|
||||
- Executor:运行在编译节点,负责接收并执行编译任务,是编译任务真正执行的地方。
|
||||
|
||||
### 系统分层结构
|
||||

|
||||
|
||||
## 运行原理与流程
|
||||
|
||||
### 分布式编译原理
|
||||

|
||||
|
||||
### CloudBuild客户端
|
||||
CloudBuild客户端基于Ninja改造,有下面这些优势
|
||||
- 兼容使用Ninja编译的项目
|
||||
- 使用远程执行的方式提高编译时并发度
|
||||
- 使用编译缓存减少需要编译的任务数量
|
||||
|
||||
### CloudBuild服务端
|
||||
- 使用远程执行的方法提高编译时并发度,实现了任务分发至远程节点同步执行
|
||||
- 使用分布式任务调度提高任务调度效率和计算节点资源利用率,避免集中式调度的任务阻塞问题
|
||||
- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
|
||||
|
||||
### CloudBuild优势
|
||||
- 低成本:组成executor的机器不需要使用专门的高性能计算型机器,可使用多个平价的空闲机器
|
||||
- 高效:CloudBuild实现分布式编译的功能,相比单机大大提升并发度
|
||||
- 兼容Ninja:CloudBuild客户端基于Ninja改造,对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
|
||||
|
||||
### CloudBuild执行流程
|
||||
- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
|
||||
- 服务端:检查任务缓存->检查依赖完整性->调度任务
|
||||
- 编译结点:还原文件目录->还原文件目录->返回编译结果
|
||||
|
||||
## AOSP和LLVM上的应用
|
||||
### LLVM上的应用效果
|
||||

|
||||
### AOSP上的应用效果
|
||||

|
||||
### CloudBuild硬件资源利用率
|
||||
4核CPU利用率:
|
||||

|
||||
8核CPU利用率:
|
||||

|
||||
16核CPU利用率:
|
||||

|
||||
|
||||
## CloudBuild使用方法
|
||||
### CloudBuild安装
|
||||

|
||||
CloudBuild项目地址:https://gitee.com/cloudbuild888/cloudbuild.git
|
||||
### CloudBuild分布式编译
|
||||

|
||||
LLVM项目地址:https://gitee.com/mirrors/LLVM.git
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# ShareBuild分布式共享编译工作站
|
||||
|
||||
## ShareBuild的适用场景
|
||||
|
||||
在同一局域网内工作的小型团队,ShareBuild以P2P共享架构将空闲算力贡献给团队其他成员,从而为每个团队成员提供编译加速效果。
|
||||
|
||||
## ShareBuild QuickStart
|
||||
|
||||
* 同一个局域网内的A、B、C等所有节点上安装ninja2:
|
||||
|
||||
```
|
||||
wget -c https://raw.githubusercontent.com/ninja-cloudbuild/ninja2/refs/heads/main/install.sh && chmod +x install.sh && sudo ./install.sh
|
||||
```
|
||||
|
||||
* 启用ShareBuild的前置要求
|
||||
|
||||
1. 所有节点上均安装配置好了项目的编译环境,即所有节点上均能采用ninja成功单机编译项目。
|
||||
<!--
|
||||
|
||||
2. 选择任一节点上作为项目开发环境,项目中使用.devcontainer/devcontainer.json 配置了image镜像(示例如下),依次镜像创建的开发容器中能采用ninja成功单机编译项目。
|
||||
|
||||
```
|
||||
{
|
||||
"name": "DevContainer",
|
||||
"image": "devstar.cn/devstar/DevContainer:latest" # 仅作示例,务必使用您已安装配置好项目编译环境的容器镜像!
|
||||
}
|
||||
```
|
||||
> 注意:以上两种方式二选一即可,第2种方式省掉了在其他节点上安装配置项目编译环境,但是首次ShareBuild模式分布式编译时其他节点会自动下载项目编译环境的容器镜像。
|
||||
-->
|
||||
|
||||
* 选择任一节点上作为项目开发环境,开启ShareBuild模式,然后进行分布式编译。
|
||||
|
||||
项目根目录下创建ninja2.conf 文件如下即可开启ShareBuild模式:
|
||||
```
|
||||
sharebuid:true
|
||||
```
|
||||
这时使用ninja编译将自动进入ShareBuild模式分布式编译项目。
|
||||
|
||||
> 如果直接使用ninja命令编译项目,也可以加上-s参数表示启用ShareBuild模式,示例如下:
|
||||
```
|
||||
ninja -s -r `realpath ../` #启动分布式编译,注意-r 指定项目根目录
|
||||
ninja -t clean #清除编译产物
|
||||
````
|
||||
|
||||
* 对一些特殊项目的补充说明
|
||||
|
||||
除以上常规的ShareBuild配置外,对于一些特殊项目需要做一些额外的配置,补充说明如下:
|
||||
|
||||
## 使用ShareBuild编译Android开源项目(AOSP)
|
||||
|
||||
除按照以上方法准备好编译环境和开启ShareBuild模式外,以AOSP14项目为例([详细的配置方法](/src/compile/sharebuild-aosp14.md)),还需要替换ninja和准备.sharebuild.yml来过滤掉一些无法远程编译的命令,具体操作如下:
|
||||
|
||||
```
|
||||
cp /usr/bin/android_ninja prebuilts/build-tools/linux-x86/bin/ninja
|
||||
cp /etc/ninja2/aosp14/.sharebuild.yml ./
|
||||
```
|
||||
|
||||
然后就可以单机编译一样使用make命令来分布式编译Android开源项目(AOSP)。
|
||||
|
||||
<!--
|
||||
## 使用ShareBuild编译鸿蒙开源项目(OpenHarmony)
|
||||
|
||||
todo
|
||||
-->
|
||||
|
||||
## 参考链接
|
||||
|
||||
* [以AOSP14项目为例ShareBuild分布式编译详细配置方法](/src/compile/sharebuild-aosp14.md)
|
||||
|
||||
## 版权声明
|
||||
|
||||
Copyright @ Mengning Software
|
||||
|
||||
梦宁软件(江苏)有限公司 版权所有
|
||||
@@ -1,78 +1,52 @@
|
||||
# 为什么需要分布式编译?
|
||||
|
||||
- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟,所以缩短大型项目的编译时间的分布式编译系统有重要意义
|
||||
- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率,缩短项目编译时间
|
||||
- 在实际开发时,同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译,从而进一步加快编译效率
|
||||
|
||||
## 总体架构
|
||||
### 系统总体架构
|
||||

|
||||
- Ninja:客户端,该机器上需要保存有完整的待编译项目源代码。
|
||||
- Action Cache:服务端缓存,主要保存编译任务的执行结果。
|
||||
- CAS Cache:服务端缓存,主要保存客户端上传的依赖文件,编译结果文件。
|
||||
- Scheduler:任务调度器,将编译任务id分发到各个编译节点。
|
||||
- Redis:主要存储具体的编译任务供编译节点领取执行,也可存储Action Cache和 CAS Cache中的内容加速编译。
|
||||
- MySQL:主要存储编译过程中的任务统计信息。
|
||||
- Executor:各个编译节点
|
||||
|
||||
### 部署示意图
|
||||

|
||||
CloudBuild主程序分为三个部分:Client、Server、Executor。
|
||||
- Client:运行在客户端,和用户对接,用于生成待执行的远程编译任务, 同时也作为本地编译节点执行本地任务。
|
||||
- Server:运行在主服务器,主要用于连接各个编译节点,以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
|
||||
- Executor:运行在编译节点,负责接收并执行编译任务,是编译任务真正执行的地方。
|
||||
|
||||
### 系统分层结构
|
||||

|
||||
|
||||
## 运行原理与流程
|
||||
|
||||
### 分布式编译原理
|
||||

|
||||
|
||||
### CloudBuild客户端
|
||||
CloudBuild客户端基于Ninja改造,有下面这些优势
|
||||
- 兼容使用Ninja编译的项目
|
||||
- 使用远程执行的方式提高编译时并发度
|
||||
- 使用编译缓存减少需要编译的任务数量
|
||||
|
||||
### CloudBuild服务端
|
||||
- 使用远程执行的方法提高编译时并发度,实现了任务分发至远程节点同步执行
|
||||
- 使用分布式任务调度提高任务调度效率和计算节点资源利用率,避免集中式调度的任务阻塞问题
|
||||
- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
|
||||
|
||||
### CloudBuild优势
|
||||
- 低成本:组成executor的机器不需要使用专门的高性能计算型机器,可使用多个平价的空闲机器
|
||||
- 高效:CloudBuild实现分布式编译的功能,相比单机大大提升并发度
|
||||
- 兼容Ninja:CloudBuild客户端基于Ninja改造,对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
|
||||
|
||||
### CloudBuild执行流程
|
||||
- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
|
||||
- 服务端:检查任务缓存->检查依赖完整性->调度任务
|
||||
- 编译结点:还原文件目录->还原文件目录->返回编译结果
|
||||
|
||||
## AOSP和LLVM上的应用
|
||||
### LLVM上的应用效果
|
||||

|
||||
### AOSP上的应用效果
|
||||

|
||||
### CloudBuild硬件资源利用率
|
||||
4核CPU利用率:
|
||||

|
||||
8核CPU利用率:
|
||||

|
||||
16核CPU利用率:
|
||||

|
||||
|
||||
## CloudBuild使用方法
|
||||
### CloudBuild安装
|
||||

|
||||
CloudBuild项目地址:https://gitee.com/cloudbuild888/cloudbuild.git
|
||||
### CloudBuild分布式编译
|
||||

|
||||
LLVM项目地址:https://gitee.com/mirrors/LLVM.git
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
# 为什么需要分布式编译?
|
||||
|
||||
大型项目过长的编译耗时给开发、调试、测试和CI/CD都带来延迟,缩短大型项目的编译时间是分布式编译系统的主要目标。
|
||||
|
||||
- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率,缩短项目编译时间。
|
||||
- 在实际开发时,同一个团队有大量编译任务是相同的,分布式编译缓存可以避免重复编译,从而节约算力消耗,并进一步缩短项目编译时间。
|
||||
|
||||
## 分布式编译技术相关工作综述
|
||||
|
||||
当前,国内外已有多种分布式编译系统和技术,如Distcc[8]、 CCache[9]、Bazel[10]、CodeArts Build[11]以及YADCC[12]等。
|
||||
|
||||
Distcc是一款经典的分布式编译工具,采用客户端/服务器的工作模式,用户使用客户端程序启动编译任务,客户端会分析项目代码并在本地完成预处理工作,然后选择一台远程计算机,将文件发送至服务器,服务器进程处理收到的编译任务并将结果返回至客户端。Distcc 的缺点在于其负载均衡算法过于简单,其无法感知各个远程计算机的负载情况,任务分发的依据主要与远程主机在本地环境变量中的次序相关,远程主机名越靠前,得到的编译任务越多,但是当存在某个远程主机的性能过差的情况,整体编译效率将会显著下降。
|
||||
|
||||
CCache(Compiler Cache)是一款编译缓存工具,支持GCC、Clang、MSVC(Microsoft Visual C++)等编译器。其原理是将源代码文件的编译结果保存在文件缓存中,在后续编译过程中再次使用到对应文件且该文件无变动时,可直接从缓存中获取编译结果。CCache的效果类似于Make的缓存功能,不同的是Make是根据源文件的时间戳来实现缓存,而CCache是按文件内容实现缓存,通过计算文件内容的哈希值来标识该缓存文件。有了编译缓存CCache的支持,软件项目能够在无入侵,不影响现有业务代码,对开发人员透明的前提下提高编译效率。CCache的缺点是只能实现本地机器的缓存共享,无法对多个远程计算机提供编译缓存服务。
|
||||
|
||||
Bazel是Google内部编译工具Blaze的开源实现,同时支持多种编程语言。其采用的客户端/服务器模式,可以将任务方便地扩展到多台服务器上进行分布式编译。Bazel的编译指令采用了类似Python的Starlark语言[13]作为领域特定语言DSL[14](domain special language),而且支持细粒度的编译产物管理,使得项目互相引用变得十分简单。虽然Bazel 拥有执行速度快、跨平台、可扩展等优点,但Bazel 运行的前提条件是需要开发人员手动编写依赖描述文件,即BUILD文件。这样也就意味着在代码规模稍大的项目中引入Bazel需要消耗时间精力编写BUILD文件,对于非Bazel项目极其不友好。
|
||||
|
||||
华为云CodeArts Build已经可以支持华为6万研发人员进行软件开发工作和软件高效集成,每日编译任务量达到77万次,并提供24.8万台服务器进行集中的弹性调度。但CodeArts Build是专为华为云平台设计的,因此它的使用会对华为云服务的依赖性较高,同时由于其非开源,用户无法直接了解该系统的具体实现细节和内部工作原理,对后续的优化和维护工作带来不便。
|
||||
|
||||
腾讯YADCC(Yet Another Distributed C/C++ Compiler)是腾讯云推出的一款基于分布式架构的C/C++ 编译器。它采用了分布式编译技术和增量编译技术,可以快速地编译大型C/C++项目,并支持多种编译选项和优化级别。除了分布式编译外,YADCC还提供分布式编译缓存、调度预取优化、并发控制等服务。但由于YADCC的调度器是全局共享的,所有请求均由调度节点统一分配,因此集群在高负载时会阻塞新请求,导致用户无法正常使用服务。而且YADCC主要用于C/C++项目,因为使用范围有限。
|
||||
|
||||
结合国内外现状可以发现,大多数分布式编译系统都是针对C/C++相关项目,对于像Android开源项目、开源鸿蒙等复杂的多语言大型项目的支持能力不足。
|
||||
|
||||
## CloudBuild/ShareBuild分布式编译系统
|
||||
|
||||
CloudBuild/ShareBuild分布式编译系统实现了基于Ninja的高效分布式编译,实验表明,采用本分布式编译系统后AOSP项目的编译时间降低了57.4%,LLVM项目降低了72.4%,OpenCV项目降低了71.6%,因此本系统可以大幅缩短编译时间,加快项目迭代速度。
|
||||
|
||||

|
||||
|
||||
## 参考链接
|
||||
|
||||
- [1] Google. Android开源项目[EB/OL]. https://source.android.google.cn,2021.
|
||||
- [2] Evan Martin. The ninja build system[EB/OL]. 2022. https://ninja-build.org/manual.html.
|
||||
- [3] 王淼. 面向多核处理器的并行编译及优化关键技术研究[D]. 长沙: 国防科学技术大学, 2010.
|
||||
- [4] 崔洋洋. 分布式计算综合实验平台的设计与实现[D]. 西安电子科技大学, 2021.
|
||||
- [5] 童亚拉. 分布式编译的方法和系统研究[J]. 计算机技术与发展, 2010, 20(5): 79-8.
|
||||
- [6] 张朝滨. 基于Ninja的分布式编译系统[D]. 中山大学, 2015.
|
||||
- [7] Nacke, Kai. Learn llvm 12: A beginner’s guide to learning llvm compiler tools and core libraries with c++[M]. Packt Publishing Ltd, 2021: 30 - 34.
|
||||
- [8] Matev, Rosen. Fast distributed compilation and testing of large c++ projects[C]//EPJ Web of Conferences. USA: EDP Sciences, 2020: 3-5.
|
||||
- [9] Joel Rosdahl. Ccache—a fast c/c++ compiler cache[EB/OL]. 2023. h-ttps://ccache.dev.
|
||||
- [10] Google. Bazel官方文档[EB/OL]. 2022. https://bazel.build/start/baz-elintro.
|
||||
- [11] HuaWei. 编译构建 CodeArts Build[EB/OL]. https://www.huaweicloud.com/product/cloudbuild.html,2023.
|
||||
- [12] Tencent. Yadcc 分布式C++编译器[EB/OL]. 2022. https://github.com/Tencent/yadcc.
|
||||
- [13] Google. Starlark language[EB/OL]. 2022. https://bazel.build/rules/language.
|
||||
- [14] 廖万斌, 曹云峰, 王新尧. 面向复杂系统需求分析的 DSL 构建[J]. 系统工程与电子技术, 2022, 44(11): 3443-3454.
|
||||
- [15] Jing, Shimin, Zheng, Xin, Chen, Zhengwen. Review and investigation of merkle tree’s technical principles and related application fields[C/OL]//2021 International Conference on Artificial Intelligen-ce, Big Data and Algorithms (CAIBDA). Xi’an, China: IEEE, 2021: 86-90. DOI:10.1109/CAIBDA53561.2021.00026.
|
||||
- [16] Rawal, Bharat S, Kumar, Lingampally Shiva AND Maganti, Sriram AND Godha, Varun. Comparative study of sha-256 optimization techniques[C]//2022 IEEE World AI IoT Congress (AIIoT). Seattle, WA, USA: IEEE, 2022: 387-392.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -17,7 +17,8 @@ sudo devstar start
|
||||
|
||||
### 二、Ollama私有部署代码大模型
|
||||
|
||||
> 如您使用第三方API及Token,比如从http://xxx 注册申请,可以跳过这一部分。
|
||||
> 如您使用第三方大模型开放API可以跳过这一部分。
|
||||
> 比如从[智谱AI开放平台](https://bigmodel.cn/usercenter/proj-mgmt/apikeys) 上注册申请并添加新的API Key,以Claude Code为例URL使用https://open.bigmodel.cn/api/anthropic
|
||||
|
||||
Ubuntu-20.04下完成安装:
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user