ポインタが苦手？

IntelC++と付き合って半年近くなるけど、最近彼女はポインタが大の苦手であることが判明した。

たとえば、こんなループ

foo() {
  float *buffer;
  buffer = malloc(256 * sizeof(float));
  for (int i = 0; i < 16 ; i++) {
    float* buf = &buffer[i * 16];
  #pragma vector aligned //＜ベクトル化してお願い
    for (j = 0; j < 16; j++) {
      buf[j] *= 2;
    }
  }
}
というようなループなんだけど、#pragma vector alignedというプラグマでベクトル化をお願いしても、嫌だと断られてしまいます。
で、以下のように書き直すとベクトル化してくれます

foo() {
  float *buffer;
  buffer = malloc(256 * sizeof(float));
  for (int i = 0; i < 16 ; i++) {
    float* buf = &buffer[i * 16];
    DoJ(buf, 16);
  }
}

void DoJ(float* buf, int size) {
  #pragma vector aligned //＜ベクトル化してお願い
  for (int j = 0; j < size; j++) {
    buf[j] *= 2;
  }
}

ようするにbuf = &buffer[i * 16] とかやってループの途中にアドレス計算なんかを入れると途端に何がなんだかわからなくなるのだと思われます。
でも、内側のループを関数に外だしすると何故かベクトル化ＯＫ。。。
うーん、処理の内容はぜんぜん変わらないちゅーのにね。。。。。

微妙に細かいバグというか

仕様的に不自然じゃね？
と思うところというのか、ほころびみたいなのがチラホラ見えてきている。
とりあえずExcelに課題一覧を作ってほうりこんでいるけど、本腰いれて手を入れるのは6月以降だろうなぁ。
今はとにかくアレを完成させねばならぬのよね

●→→→○

いつも仕事で書いているプログラムと違って、今未踏で書いているプログラムは、比較的ローレベルな記述をやっています。
メモリのアライメント（配列の先頭を１６バイト単位であわせる）とか、高速化のための処理の間引き、メモリコピーの回避、分岐の除去とか。。
そんなのを考えてやらないといけないので、SIer的な言葉で説明すると、
「基本設計から実装までの距離が長い」
ということになろうかと思います。
基本設計というのは、「こういうものを作ります」という文章で、ユーザ側（のシステム担当者）と、開発者の双方が理解できることを前提とした文章です。
で、とくにSIerで使うツール（プログラミング言語や、ＤＢ管理システム）は、この基本設計から実装（コーディング）までの距離をなるべく短くするために設計されている。といっても過言ではないでしょう。
画面をデザインするためのツールが用意されていて、それでテキストボックスとかボタンとかを適当に並べる。
で、配置したボタンをダブルクリックするとボタンに対応した処理を行うコードが自動挿入されて、プログラマはその中身を書くだけ。
で、よく使う処理は大方ライブラリが用意されていて、その上っ面の仕様さえ理解していれば必要な機能を満たしたプログラムは書けてしまいます。

ぶっちゃけSIer（おっと、あまり一般化しないで今の現場といっておこう、、）では、基本設計書さえできてれば、詳細設計みたいな工程はすっ飛ばして、いきなりコーディングを始めて、１ヶ月そこらで仕上げてしまえることが実に多いものです。
時間をかけるのは基本設計まで落とし込むところ。ユーザ側での意見調整や、具体的な要件の不明点の洗い出し、システム化する上で問題となる点の洗い出し、スケジュール作成と管理、などなど会議と資料作成の繰り返し、これがメインの仕事となるわけです。

で、今作っているソフトは、基本設計はもちろん必要ですが、なにぶん全ての決定権を持っているのが自分自身ですから、もめることなど何もなく、システム化が難しいものは、サクっと先送りできますし（重要な部分はもちろん力をいれますがね、、）ちょっと悩むことはあっても意見が割れたりすることもない。
いわゆるSIer的なコストというのは限りなく小さいといえます。

で、そのかわりSIerで詳細設計と呼ばれている部分の比率が大きくなります。
詳細設計は「どう作るか」を決める作業で、これを記載した詳細設計書は、開発リーダーがプログラマに指示を出したり外部の開発会社（主に海外）に外だしするときに必要となる文章です。
で、詳細設計書なんて自分で各分には要らないや
と思っていたのですが、なんか、やっぱり無いとつらい。

というか、今の開発は普通だったら詳細設計のレベルだと思われる部分（関数仕様や、クラス仕様、はもとよりアルゴリズムなんかも）が基本設計で、
ノートや紙に書きなぐりでやっているのは、そのアルゴリズムを「高速」に実行できるように、みたいなところです。

ある処理の準備をするためのクラスで、さらに下請けのクラスを追加して使うみたいなことを日常茶飯事でやっております。（当然全て自分で設計と実装を行います。）

でも大分慣れてきたと思う(思いたい）ので、がんばってやっていくです。

守秘守秘

色々とアイデアがストックされて設計できるものから設計、また実装できるものから書いているのだけれど、まだ特許を出願していないので、シュヒシュヒでございます。
アルゴリズムをかなり効率化できたと思う。
ちょっとだけバラすとオーディオ編集TIPS第１３回のアルゴリズムを使っている。
ＳＳＥ命令使ったり、ノルム計算の間引きなんかをやっていて、あのコラムのサンプルコードよりもさらに数段高速になっていると思う。
早くトータルな枠組みから出てくる音を聴いてみたい！

さあガンバルか！

速くなったり遅くなったり

やはり最適化コンパイラを通していると思わぬ分岐がやたらと遅くなったり、
こうすれば速くなると思ったら遅くなったり。。色々と面倒ですわ。。

今回OpenMPでの並列化をやっているのですが、基本は粗粒度、つまりなるべく外側で並列化を開始したほうが良いとされています。
なので、ループ対象の処理ブロックA、Bが依存性が無い場合も、１つのループにして、ループ全体を並列化した方がいいんだろうなぁ。。と思っておりました。。
つまり、
#pragma omp parallel for
for (int i=0; i < 1000; i++) {
   A();
　 B();
｝

こっちのほうが速いんだろうなぁ、と思ってそう書いていた。
で、ものの試しに、
#pragma omp parallel for
for (int i=0; i < 1000; i++) {
   A();
｝
#pragma omp parallel for
for (int i=0; i < 1000; i++) {
   B();
｝
と書いてみたら、おやおや、こっちの方が速かったよ。。。。。

なんか、分岐があるなしでも大きく速度が変わる（ときもあるし、そうでないときも）
ので、もう速くなるまで色々と書き換えてみるしかないという始末。。。。

だめだ、不毛な作業はやめよう。。。。。
次の作業が待っているのだから。。

Sincじゃなしバージョン

Sinc補間なんぞをやっているから無駄にスピードが遅いと思うようになった。
大抵は線形補間で十分だし、いざとなったらWAVETABLEの元ネタをオーバーサンプリングしておけば、Sinc補間と大差なくなるしと、、

というわけで、WAVETABLE系のオブジェクトに精度のパラメータを追加して、Sinc補間の他に線形補間もできるようにした。（こういうときに、オブジェクト方式にしておいた甲斐があったというもの）

おかげで６００個くらいのディレイタップをウニョウニョ動かせるようになったYO
わーいっ！

でこんな音を楽しんでみた。
http://hanac200x.cocolog-nifty.com/ok8.mp3

パフォーマンスの怪

またまた、計算速度の問題が表面化してきたので、なんとかならないものかと、音質低下覚悟の上で、線形補間していた部分を外してみた。
要するにテーブルルップアップのみって感じにしてみた。
で、遅くなる。。。
テーブルのサイズを大きくしたわけでもあるまいし、、、
なぜ、なぜ、処理を省くと遅くなるの？？？
なんか、疑心暗鬼になるなぁ。。。。。