▲
by tom01h
| 2017-12-31 23:59
| スキー
|
Trackback
|
Comments(0)
▲
by tom01h
| 2017-12-30 23:59
| PCとか
|
Trackback
|
Comments(0)
▲
by tom01h
| 2017-12-27 21:29
|
Trackback
|
Comments(0)
いまさらながら考えてみると…
普通のCPUとしては今更感がある。
特殊な機能を持つIPを制御する名もないマイコンかな?と思っている時もありました。
でも「7th RISC-V Workshop」のニュースをいくつか見た後で、今はこんな感じかと思っています。
制御用のマイコンよりももっと密結合して、つまり特殊な機能を追加命令で実装して、主役は追加命令で、基本ISAなんて減点が少なければよい。
でも、今そこにいるプレーヤはみんな、自分のコアを持っているような気がする。
言い換えると、Rocket に命令を追加している人いない。
まぁ、Chesel がだいたい悪いんだろうけど…
Rocket が立派すぎてとっつきが悪いっていうのもあるのかな?
パラメタライズのし過ぎで、どんな設定もできるけど、どの設定もいまいちって気がしないこともないし…
だから、zero-riscy とか V-scale とか拾ってくるんだけど、本当は UCB のお墨付きコアを使いたいんです。
それとも、今のところは CPU を作る人しか RISC-V に興味を持っていないのかな?
■
[PR]
▲
by tom01h
| 2017-12-26 23:25
|
Trackback
|
Comments(0)
▲
by tom01h
| 2017-12-25 20:32
|
Trackback
|
Comments(0)
志賀高原へ初滑りに行ってきました。
最近は全く体を動かしていないのでとっても不安でしたが、まあ何とか2日間無事に滑れました。
今シーズンはなんか上達できるかな?
■
[PR]
▲
by tom01h
| 2017-12-24 20:52
| スキー
|
Trackback
|
Comments(0)
▲
by tom01h
| 2017-12-23 23:59
|
Trackback
|
Comments(0)
いよいよ XNOR とビットカウントを使って、最適化最終段階に入ります。
ビットカウントはネットで拾った下の計算。
// C or C++: use uint32_ti = i - ((i >> 1) & 0x55555555);i = (i & 0x33333333) + ((i >> 2) & 0x33333333);return (((i + (i >> 4)) & 0x0F0F0F0F) * 0x01010101) >> 24;
恐ろしいくらいの最適化ですね。
もちろんこれは、論理演算だろうが掛け算だろうが同じ速度で計算するCPUならではの最適化法です。RTL 設計には当てはまらないのでご注意ください。
話を推論に戻すと、期待以上にだいぶ速くなりました。
置き場所としていまいちかもしれんせんが、Github の zero-riscy のテスト環境 に置いておきました。
ちなみに、
オリジナルっていうのは 32bit float だとこのくらいかなって鉛筆なめた数字で、
bin 値のみはパラメータはバイナリ型を int 型に詰め込んでデータサイズを削減しつつ、ワークメモリのほうは整数型を使っているバージョン、
bin 実行順はアクティベーション間の計算順序を幅優先から深さ優先に変更して保存するワークデータ数を削減しつつ、データ型も signed char に変更して使用メモリ量を削減したバージョン、
bin 完成はワークメモリもバイナリ型を int 型に詰め込んで、計算も XNOR + bit カウントに変更したバージョンです
■
[PR]
▲
by tom01h
| 2017-12-22 00:00
| PCとか
|
Trackback
|
Comments(0)
推論プログラムで使うワークメモリを減らすために、アクティベーション間の計算順序を幅優先から深さ優先に変更しました。
ついでにアクティベーションデータは±1だけなので、char 型に変更してみたのが運の尽き、大変な目にあいました。
char 型って gcc のバージョンによって、デフォルトが符号付きだったり無しだったりするのでしょうか?
[追記 バージョン依存ではなく、ターゲットアーキテクチャに依存するようです。ご参考まで。]
WSL 上で実行するとちゃんと動くのに、RISC-V 用にコンパイルすると動かない。
逆アセンブルしてみるとなんかおかしい。この解析にとっても時間がかかってしまいました。
そんなわけで、XNOR とビットカウントを使った最適化はまた明日。
なんでか知らないけど、実行サイクル数もぐっと減っていますね。
■
[PR]
▲
by tom01h
| 2017-12-21 00:11
| PCとか
|
Trackback
|
Comments(0)
Verilator を使って試行中なのですが、割り当てメモリがどんどん増えて、命令32KBとデータ512KBでデバッグしています。
とりあえず1データだけですが、103775576サイクルで完走しました。正しく計算できている模様です。
だいぶ遅いとはいえ、シミュレーションで流して見れるのはやっぱり便利です。Verilator えらい。
いまさらながら、使用メモリ量をざっと見積もってみました。
ここ においてあるソースファイルから、目立つバッファを抜き出しています。
パラメータと計算中のデータを置いておくメモリの合計で約480KBのメモリを使うみたいです。
データメモリを512KBにしたのでぎりぎり間に合っているかな?でもこのままだと、FPGAには乗らなさそうです。
データを置いておくメモリは全く最適化していないし、そもそも32bit整数型の必要もないはずなんですけどね。
やっぱりソフトウェアもちゃんと最適化たいと思いますが、まずはデータ削減のために演算順序を変えるところから。
アクティベーションからアクティベーションの間を幅優先から深さ優先に変更します。
これで必要な中間バッファががっつり減ります。
まぁ、本来なら中間バッファの再利用もしたほうが良いのでしょうけどね。
ワークメモリはこれくらいに減る予定です。
これなら Arty Z7-20 にも Arty A7-35 にも乗りますかね?
まだ試していませんけど…
■
[PR]
▲
by tom01h
| 2017-12-20 00:00
| PCとか
|
Trackback
|
Comments(0)