コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2022年11月19日 >>> 2022年11月10日
link もっと後

2022年11月16日

個人で自社製品RISC-V CPUを買うことはできるか?その2 - 個人向け販売チャネル検討中

目次: RISC-V

先日(2022年11月12日の日記参照)送ったNS31Aの評価キット購入についての問い合わせの返事が来ました。あまりに返事が来なくて、メールアドレス書き間違ったかな?って不安だったので安心しました。ちなみに返事の内容は、

  • 個人向け販売は想定外だった
  • 個人向け販売もできないか社内調整する
  • 販売可能か不可能か今は答えられない

とのことです。QAフォームを見た時点で、これBtoB販売しか想定してないでしょ!?とは薄々感じていたので、やっぱりか〜と思いました。

というわけで、何かしらの決定&判断をいただけるまでもう少し待ってみます。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2022/12/19 16:25)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2022年11月14日

電池 - まとめリンク

目次: 電池

ニッケル水素電池(Ni-MH)。

編集者:すずき(2024/01/13 17:24)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2022年11月12日

個人で自社製品RISC-V CPUを買うことはできるか?その1 - 問い合わせ

目次: RISC-V

個人で自社製品を買おうとしたらどうすれば良いか?を調べました。NSITEXEのIPで世の中に出ているものは2種類ありますが、Akaria NS31Aという汎用RISC-V 32bit CPU IPを購入します。

CPU IPそのもの(Verilogのコード)を買うのはライセンス契約等が必要で個人ではほぼ不可能なので、CPU IPを試せるFPGAの購入を検討します。

とにかく買い方がわからなくて辛い

萩原エレクトロニクスがパートナー企業として評価キットを販売してくれています。しかしNSITEXE NS31Aで検索してもかなり下に評価キットのニュースリリースが出るのみで、製品紹介サイトはありません(NSITEXE製RISC-Vコア評価キット発売について - 萩原電気ホールディングス株式会社)。ニュースリリースですといずれ消えるのでは?大丈夫か……?

ニュースリリースにはAkaria NS31AのEntry Kitの特徴は「発売中」と書いてあるものの、買い方が一切書いていません。この時点で興味のあるエンジニアの3割が脱落すると思います。

めげずに読み進めて下の方にある「NSITEXE製RISC-Vコア評価キット製品紹介」というボタンを押すと、チラシがPDFで出てきます。Interface誌にもこのチラシが載っていました(チラシへのリンク)。

チラシを見ても相変わらず買い方がわからないです。あとQRコードだけという仕様も辛いです。PCユーザーを見捨てないでほしいです。この時点で興味のあるエンジニアの6割が興味を失って脱落すると思います。

すぐに買えないのはなぜ?

めげずにスマホを持ってきてQRコードを読むと、良くわからんQAフォームに飛ばされます(お問い合わせ - 萩原エレクトロニクス)。

出た出た!日本の半導体会社の最大の悪癖「営業にご連絡ください」攻撃です。この時点で興味のあるエンジニアの9割が脱落します。上司に言われて仕事で渋々買う人以外は連絡しませんよ。これ。

QAフォームを見ると会社名が必須で「個人の開発者など用はない、去れ」という気持ちがビシビシ伝わりますが、めげずに「個人ですが何か?」とフォームを埋めてメッセージを送信しました。


QAフォーム

しばし待ってみましたが、特に確認メールなどは来ないようです。正常に送れたんでしょうか?不安になりますね。今日はいったんここまでです。買い方がわかったらまた続きを書こうと思います。

他国と比べてしまう

中国や台湾のメーカーはボード1つでも売ってくれるし、一瞬で注文できるし海を越えても届けてくれるのに、日本のボードは1日で発注にすら至らないし、すごく面倒くさいです。相当の機会損失していると思います……。

編集者:すずき(2022/12/19 16:23)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2022年11月11日

手動の最適化 対 コンパイラの最適化

ポッキーの日だそうですが、1(と0)といえば2進数、2進数といえばビット操作ですね(?)。以前 Bit Twiddling Hacks を最新のコンパイラ達に向けて試したときの悲しい結果をメモしておきたいと思います。

試したのはConditionally set or clear bits without branchingという項目で、fがtrueならwとmのビット論理和を、fがfalseならwからmのビットを消去した値を返す処理です。素朴な実装ではif文を使うでしょう。

1つ目の方式: Conditionally set or clear bits

int cond_set_or_clear1(bool f, int m, int w)
{
    if (f)
        return w | m;
    else
        return w & ~m;
}

さきほどのサイトでは最適化版として、条件分岐をなくす、データ依存性をなくす(スーパースカラプロセッサ用)、2つのバージョンを掲げています。まずは条件分岐をなくした版のコードを紹介します。

2つ目の方式: Conditionally set or clear bits (without branching)

int cond_set_or_clear2(bool f, int m, int w)
{
    return w ^ ((-f ^ w) & m);
}

分岐がなくなっています。なんでこれで同じ動作をするのか?は説明が必要でしょう。fがtrueなら -f = -1となり、-f ^ wはwのビット反転(notと同じ)と同じ結果 -1 ^ w = ~wになります。よって右側の括弧内 (-f ^ w) & m = ~w & mです。

あとは~w & mはw = 0, m = 1のビットだけ1になって残り、あとは全部0になります。w ^ (~w & m) はw | mと同じ結果ですが……そう言われてもわかりにくいので表にします。

w~wm~w & mw ^ (~w & m)
10101
10001
01111
01000

一方fがfalseの場合、0とみなされるので -f = 0となって、-f ^ w = 0 ^ w = wです。右側の括弧内 (-f ^ w) & m = w & mです。w ^ (w & m) は先ほどとは逆でw = 1, m = 1のビットだけ1になって残り、あとは全部0になります。

最後にwとこの結果をxorすることでwとmがともに1のビットだけ0になりますから、w ^ (w & m) はw & ~mと同じ結果です、が……これも表がわかりやすいでしょう。

wmw & mw ^ (w & m)
1110
1001
0100
0000

次にスーパースカラ版のコードを紹介します。

3つ目の方式: Conditionally set or clear bits (without branching, superscaler)

int cond_set_or_clear3(bool f, int m, int w)
{
    return (w & ~m) | (-f & m);
}

これは先ほどよりシンプルです。左側の括弧はfによらず常にw & ~mで一定で、右側の括弧の値だけが変化します。

まずfがtrueなら -f = -1となり、-f & m = mです。(w & ~m) | mですが、w & ~mはwからmの1となっているビット位置を0にする演算でした。そこにmをorすると消えたビットは再び1になります。すなわちw | mと同じ結果です。

wmw & ~m(w & ~m) | m
1101
1011
0101
0000

次にfがfalseなら -f = 0となり、-f & m = 0です。よって (w & ~m) | 0 = w & ~mになります。

なぜスーパースカラ向けか書いていませんが、w & ~mと -f & mに依存性がなくて同時に演算できるからだと思われます。じゃあ全部これでいいじゃないか?と思われるかもしれませんが、演算回数を見ると、

2つ目の方式と3つ目の方式の演算回数
2つ目の方式: w ^ ((-f ^ w) & m)

neg, xor, and, xorの4回の演算が必要

3つ目の方式: (w & ~m) | (-f & m)

not, and, neg, and, orの5回の演算が必要

このため同時に演算できないプロセッサの場合は2つ目の方式の方が良いと言えます。

全てを無にするコンパイラの最適化

ここまで長々と紹介しておいてこんなことを言うのは憚られますけど。この手のビット魔術は面白いのでつい手を出したくなりますが、最近のコンパイラに対しC言語レベルでの最適化はあまり意味がないです。

論より証拠でGCC 12.2.0の結果から見てみましょう。


GCC 12.2.0でのコンパイル結果

あれだけグダグダ語った3つ目の方式でしたが、なんと2つ目の方式と全く同じバイナリになりました

GCCだけでは証拠として不安でしょうか?では次にclang 15.0.0の結果も見ましょう。


clang 15.0.0でのコンパイル結果

なんと3つ目の方式は「これ分岐じゃね?」と解釈されて分岐に戻されてしまいました。これが分岐に見えるclangはスゴイですね。私はこのコードを見ても分岐には見えません……。

1つ目の方式と2つ目の方式が違うバイナリになるところを見る限り、全くの無意味ではないです。しかし見やすさでは大幅に劣ります。基本は素朴なコードにしておき、遅くて困る場合のみビット魔術に手を出すべきでしょう。

編集者:すずき(2022/11/13 00:35)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2022年11月19日 >>> 2022年11月10日
link もっと後

管理用メニュー

link 記事を新規作成

<2022>
<<<11>>>
--12345
6789101112
13141516171819
20212223242526
27282930---

最近のコメント5件

  • link 24年4月22日
    hdkさん (04/24 08:36)
    「うちのHHFZ4310は15年突破しまし...」
  • link 24年4月22日
    すずきさん (04/24 00:37)
    「ちゃんと数えてないですけど蛍光管が10年...」
  • link 24年4月22日
    hdkさん (04/23 20:52)
    「おお... うちのHHFZ4310より後...」
  • link 20年6月19日
    すずきさん (04/06 22:54)
    「ディレクトリを予め作成しておけば良いです...」
  • link 20年6月19日
    斎藤さん (04/06 16:25)
    「「Preferencesというメニューか...」

最近の記事3件

  • link 24年2月7日
    すずき (04/24 02:52)
    「[複数の音声ファイルのラウドネスを統一したい] PCやデジタル音楽プレーヤーで音楽を聞いていると、曲によって音量の大小が激しく...」
  • link 24年4月22日
    すずき (04/23 20:13)
    「[仕事部屋の照明が壊れた] いきなり仕事部屋のシーリングライトが消えました。蛍光管の寿命にしては去年(2022年10月19日の...」
  • link 24年4月17日
    すずき (04/18 22:44)
    「[VSCodeとMarkdownとPlantUMLのローカルサーバー] 目次: LinuxVSCodeのPlantUML Ex...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 04/24 08:36