J

2004 | 08 | 09 | 10 | 11 | 12 |
2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2007 | 01 | 02 | 03 | 04 | 05 | 06 | 12 |
2008 | 01 | 02 | 04 | 10 | 11 | 12 |
2009 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2010 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2011 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2012 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 12 |
2013 | 01 | 02 | 03 | 05 | 06 | 07 | 08 | 09 | 10 | 11 |
2014 | 01 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 |
2015 | 02 | 03 | 04 | 05 | 06 | 07 | 10 | 11 | 12 |
2016 | 01 | 02 | 04 | 05 | 06 | 07 | 09 | 11 | 12 |

ホーム

日記内の"morihyphen.hp.infoseek.co.jp"へのリンクは切れてます。必要な場合はお手数ですが int.main.jp へ書き換えをお願いします。

TODO: ファイル名確認を忘れないこと > 自分

twitter

 

2016-12-03

ステーキを焼く(カー3) 08:32

昔カリフォルニアにいたころはよくステーキ焼いてたので、たまに焼くが(というほど滅多に焼かないが)、安い肉を焼いてしまうと、うまくいかなかった時に、「これは安い肉を焼いたからうまくいかなかったんだ」とか言い訳してしまうので良くないな。

ちゃんと言い訳する逃げ道を塞いでおかないと練習にならない。

トラックバック - http://d.hatena.ne.jp/w_o/20161203

2016-12-02

コンパイラの最適化を抑制する(GCC編) ひとりなんとかカントカー 2 00:17

性能劣化を調査したりする場合、コンパイラのチューニングによってコードが消えてしまうと困る場合はよくあります。

場合に応じて適切に対応することで、コンパイラのチューニングを抑制していきましょう。


(GCCと互換性の高いclangでも同じように対応できると思います。VC,ICC編はないです)


  • インライン展開しないで
    __attribute__((noinline,noclone))

関数に attribute noinline, noclone を付けます。今のGCCは、引数が定数だった場合などに、その定数にあわせて関数を複数生成することがあるので、nocloneも付けたほうが確実です。

static int f(int a) __attribute__((noinline,noclone));
static int f(int a) { return a; }

int main () { return f(100); } 

などで試すと、noclone の有無で出るコードが変わるのが確認できる可能性が高いです。


  • 途中の値を消さないで欲しい
__asm__ __volatile__( " # test" : : "r" (a) );

のようにasm文のオペランドに残したい値を渡します。


int f(int a) {
    a += 3;
    __asm__ __volatile__( " # test" : : "r" (a) );
    return a + 4;
}

f:
.LFB0:
	.cfi_startproc
	leal	3(%rdi), %eax
#APP
# 3 "op.c" 1
	 # test
# 0 "" 2
#NO_APP
	leal	7(%rdi), %eax
	ret
	.cfi_endproc

+3, +7 が出ます



  • メモリ読み書きを消さないで欲しい
__asm__ __volatile__( " " : : : "memory");

を入れます。

void f(int *p) {
   p[0] = 0;
   __asm__ __volatile__( " " : : : "memory");
   p[0] = 0;
}

f:
.LFB0:
	.cfi_startproc
	movl	$0, (%rdi)
#APP
# 3 "op.c" 1
	 
# 0 "" 2
#NO_APP
	movl	$0, (%rdi)
	ret

残念ながら、

void f(void) {
   int a[10];
   a[0] = 0;
   __asm__ __volatile__( " " : : : "memory");
   a[0] = 0;
}

こういうのは消えますね。

void f(void) {
   int a[10];
   a[0] = 0;
   __asm__ __volatile__( " " :: "r"(a) : "memory");
   a[0] = 0;
   __asm__ __volatile__( " " ::: "memory");

}

まあ臨機応変で…(雑な終わりかた)

トラックバック - http://d.hatena.ne.jp/w_o/20161202

2016-12-01

ひとりなんか書くアドベントカレンダー 1 18:48

習慣を取り戻すためになんか書こう。(残念ながら習慣の問題でなくて加齢の問題なのでもう取り戻すことは不可能だ)

トラックバック - http://d.hatena.ne.jp/w_o/20161201

2016-11-12

33 22:32

33

トラックバック - http://d.hatena.ne.jp/w_o/20161112

2016-11-07

Goldmont 05:00

Goldmont情報全然出てこないし、もうAtom系は終わり(?)かもしれないので、どうせ大した変更入ってないだろと思ってたが、

https://twitter.com/InstLatX64/status/780328535118479360

を見てデコード3になるらしいのでやっぱり変更大きいのではないかという気がした。

なので調べてみた。

https://github.com/tanakamura/instruction-bench/blob/master/glm.log

  • 確かにデコード3っぽい
  • rcpps は 1/6
  • dpps とはなんだったのか

SLM の記録とってないから比較できないな。まあそのうち…

http://d.hatena.ne.jp/w_o/20160619#1466346637

と条件同じにすると、

 Performance counter stats for 'sh -c ../configure ; make -j4':

     316257.223623      task-clock (msec)         #    3.037 CPUs utilized          
           137,387      context-switches          #    0.434 K/sec                  
            34,324      cpu-migrations            #    0.109 K/sec                  
         8,866,202      page-faults               #    0.028 M/sec                  
   683,023,573,273      cycles                    #    2.160 GHz                    
   <not supported>      stalled-cycles-frontend  
   <not supported>      stalled-cycles-backend   
   463,951,050,783      instructions              #    0.68  insns per cycle        
    96,861,409,185      branches                  #  306.274 M/sec                  
     3,428,910,864      branch-misses             #    3.54% of all branches        

     104.117997143 seconds time elapsed

時間[秒]IPC W(load)W(idle)W(load-idle)
rpi3 270 0.444.7 1.8 2.9 Cortex A53 4core
rpi2 490 0.322.9 1.6 1.3 Cortex A7 4core
parallella882 0.563.5 2.8 0.7 Cortex A9 2core
liva ecs 223 0.497.2 3.5 3.7 Silvermont 2core
I3455-ITX 104 0.6826.5 18.5 8.0 Goldmont 4core

アイドル電力大きいのは多分HDDとかUSBとか付いてるからなので許して。

  • IPC が 0.49 → 0.68 に上がっている。
  • Silvermont 2coreとGoldmont 4coreで比べてるのであんまり良くない

まあ参考程度で…


今のKNLの問題として、デコード2で2個FPUを回さないとフル性能出ないという問題が多分あって(真面目に使ったことないので知らないけど)、使いにくいのだろうけど(分岐とかすると性能低下する)、次の世代(Knights Hill or Knights Mill?)でGoldmontコアが採用されるなら、この問題はかなり改善される気がする。

トラックバック - http://d.hatena.ne.jp/w_o/20161107