编译器比你聪明


#82

显然 编译器更懂得如何为CPU生成最高效的代码.


#83

博士,这样说来,国内经常有些人专门以给人家优化代码为生的人,不就是骗子吗?


#84

肯定是骗子啊!

还有人觉得手写的代码才是高效的, 还去论坛发帖子到处宣传他自己发明的什么技巧


#85

博士,果然啊,博士你看,有人到处”到处宣传他自己发明的什么技巧“!!! http://www.oschina.net/question/249672_45194


#86

死代码消除

编译器和连接器(开启链接器优化 -flto) 能自动移除

  • 没有用到的代码
  • 没有用到的 static 函数
  • 没有被用的的整个 obj 文件.

#87

准确说也不能算是编译器出问题。毕竟是比较标准的ARM编译器。更怀疑是芯片设计工艺的问题,导致寄存器数据跟不上。这类情况吃过不少苦。优化过头了

优化过头了啊

如果编译器的优化真的这么牛逼,那么他手动优化导致错误,活该!!


#88

他是交叉编译器来的,有可能的。


#89
#define SAMPLES 1000
#define MATSIZE 512

#include <time.h>
#include <iostream>
int mat[MATSIZE][MATSIZE];

void transpose()
{
   for ( int i = 0 ; i < MATSIZE ; i++ )
   for ( int j = 0 ; j < MATSIZE ; j++ )
   {
       int aux = mat[i][j];
       mat[i][j] = mat[j][i];
       mat[j][i] = aux;
   }
}

int main()
{
   //initialize matrix
   for ( int i = 0 ; i < MATSIZE ; i++ )
   for ( int j = 0 ; j < MATSIZE ; j++ )
       mat[i][j] = i+j;

   int t = clock();
   for ( int i = 0 ; i < SAMPLES ; i++ )
       transpose();
   int elapsed = clock() - t;

   std::cout << "Average for a matrix of " << MATSIZE << ": " << elapsed / SAMPLES;
}

请教,为什么 MATSIZE 为512时耗时 2.46 ms, 而为513时却只需要 0.75 ms。


#90

有关内联汇编

  • 内联汇编很难用
  • 很多人不会用
  • 就算会用, 很多人压根就没有提升性能, 反而更糟糕

如果麼一必要, 不要使用内联汇编


#91

这是典型的 cache 冲突

导致 cpu 的 TLB 缓存经常失效


#92

能详细说下,为什么对齐的时候反而cache失效么? 是和cpu cache相关的么?


#93

CPU 的 cache 也是要做 hash 的, 对齐后, 你每次访问都导致 hash 碰撞.


#94

那什么时候应该选择对齐,什么时候不应该?


#95

我喜欢把汇编另弄ELF,然后ld在一起。。


#96

这种优化只能针对特定 缓存大小的 CPU, 所以建议你不要去盲目的优化. 最好能提供 条件编译, 只在你测试过不对齐能更快的cpu上开启.


#97

优化内存 ? 优化指令?

在 i7 平台上

  • 乘法没用移位优化 : 浪费5个周期

  • 条件分支无命中 : 浪费10个周期

  • L2 缓冲无命中, 但 L3 命中 : 浪费 52 个周期

  • L3 缓冲命中失效 : 浪费 250 个周期

  • 缺页异常(零页) : 浪费 3000 个周期

  • 缺页异常(磁盘缓存命中) : 浪费 10000 个周期

  • 缺页异常(磁盘缓存无命中) : 浪费 10000 00000 个周期

所以

数据结构优化要比代码更重要


#98

严重表示支持这个说法!!!!!!!


#99

哈哈,这些数据太能说明问题了!!


#100

总结

优化不要想当然的进行.

如果优化导致代码不可读, 不要做!!!

编写可读性最好的代码, 让编译器去操心优化!!!

扔掉优化不给力的编译器


#101

好了, 有啥问题的可以继续回复