• make -jN


    今天又一次尝试编译安卓,想测试一下编译的速度如何?

           考虑机器是4核8线程,就用上了 make -j8,感觉上上速度是很快,刷屏就下来了,不过错误了,错误的提示大概是某个文件的规则没找到,想想了多线程并发执行会不会涉及到同步的问题,于是就有了这篇。

            尴尬的clear掉没用的东西,因为发现继续make竟然重新开始了。最后用了 make -j4重新试了试,结果没有任何异常。

            首先,从CPU的核心数想这个问题,我用的虚拟机来编译的,分了4个核给虚拟机,发现window下cpu的占用率始终是50%上下波动。最后发现windows认为我的cpu是8核的,这就是inter cpu牛的地方吗?

            从这里想到编程之美上的一道题目,如果让cpu使用率50%的状态,那么让半数线程满载运行也行?或者是用定时器让每个核心以50%的时间工作在while()之下,另外一半时间调用idle(),总之感觉上可行,有时间不妨来试试。

           这里就明白了一个现象,window能识别出来的核心数,和分配给虚拟机核心数之间的关系。

          这样 make -j8  就是让8个线程让4个核心竞争的执行,(只考虑相关的线程),make -j4 就是4个线程然竞争4个核心。

          这样同步的问题第一种情况会明显比第二种情况激烈,出错也是有很大可能的。 

          不过,应该更关注make 多线程编译怎样避免出错的问题? 首先很明显多线程能提交编译速度,但是如果不处理好依赖关系就会造成编译出错的问题。

          如果依赖问题没有处理好,就只能单线程这样避免编译出错。如果依赖关系设置过于保守,则可能本身编译的可并行度就下降了,也不能取得最佳的效果,总之还有一个平衡的问题。

       最后也没找到特别合适的出错的原因,只好归咎于多线程竞争吧

  • 相关阅读:
    C# Brush Color String 互相转换
    WPF Binding ElementName方式无效的解决方法--x:Reference绑定
    WPF动画应用-几何图形扩散动画
    Timer更新UI的合理办法
    员工管理
    EF CodeFirst 实例Demo
    C# 星期相关代码实例
    WPF Canvas实现进度条
    DispatcherTimer 应用实例
    数据库操作命令
  • 原文地址:https://www.cnblogs.com/senior-engineer/p/4498257.html
Copyright © 2020-2023  润新知