ORMについて変節した

ORM (Object-relational mapping)については賛否両論あると思います。 私もこの件について思うところが最近あったので、ポエムを投下します。

「ORM SQL」といった感じで検索してみると

のような記事が見つかりました。不要とほぼ断言しているものから、積極的にORMを使う派の方まで。

私もこれまではどちらかといえば、「別にSQLで書けるのに、敢えてORMを使う必要性は無いのでは」と思っていました。 ただ、最近開発をしている際に、初めてORMを使いたくなる場面に遭遇しました。

これは、端的に言えば、上の3番目の回答に挙げられているORMの機能

  • 対応するオブジェクトを通じたレコードの更新、トランザクションの一定の隠蔽

に大きな有用性を感じたためです。

これまでの開発では、コードの開発前にRDBのスキーマがほとんど決まっていたので、 レコードの更新や取得を行うSQLは(手間でも)一回だけ書けば良い場面ばかりでした。

でも、今回経験した開発では、要件が完全に決まっていない段階で開発をスタートしたのもあり、 開発がある程度進んだ段階で要件が精緻化されたところ、(ER図でいうところの)エンティティのテーブルとの対応が大幅に変わる可能性が生じました。 具体的には、現実との整合性を保つために

  • あるエンティティは、これまでの単一のテーブルから、複数のテーブルの結合とした方が良い
  • これまで2つのテーブルにマップされていたエンティティは3つのテーブルの結合とした方が良い

といった状況です。

さて、これまで真心込めたSQLで結合してマッピングしていたエンティティですが、 いざRDBスキーマが変更になると、これらも書き直さなければいけません。当然、検索(SELECT)だけでなく、 更新(UPDATE)もです。多:多でエンティティの属性を取得するためにforループを回している記述も修正する必要があります。

困った… というわけでORMの出番です。実現方法は静的コード生成だったり、実行時のリフレクションだったりしますが、 基本的にORMではエンティティ間の1:多などの関係をメタデータとして記述することで、 関数一撃で関連するエンティティを取得できるようになるわけです。

もちろん、ORMでも、RDBスキーマが変わって際の変更がゼロとはいきませんが、複数のSQLやfor文を正しく書き直す労力を考えれば、 メタデータの更新と関数呼び出しの変更程度で対応できるのであれば、相当有用であると思いました。

まとめると、スキーマが完全に決まっており、将来的にも変更されることは(ほぼ)無い、というのであれば、 SQLのみで記述してもそれほど問題にはならないかも知れません。 一方で、要件に伴ってRDBスキーマが開発中にも変更される可能性があるなら、 ORMを使用するのは保険として大変役立つのではないか、と思いました。

SQLの条件部でif-then-elseを行う

SQLでwhere検索を行うときに、条件によって、さらに検索条件を切り替えたいということが生じることがあります。

例えば、テーブルにカラムC1, C2, C3が存在するとして、気持ちとして以下のように書きたくなる場合です。

select something from tbl where if p(C1) then q(C2) else r(C3)

カラムC1に依存する述語p(C1)がTRUEの時はq(C2)で検索し、FALSEの場合はr(C3)で検索する、というものです。

SQL: If clause within WHERE clause に答えがでていますが、この場合は、

select something from tbl where (p(C1) and q(C2)) or (not p(C1) and r(C3))

が答えになります。if p(C1) then q(C2) else r(C3)がTRUEになる場合を考えると、p(C1)がTRUEであれば、q(C2)がTRUEである必要があり、 p(C1)がFALSEであればr(C3)がTRUEでないといけません。これを論理式で書いたのが上になります。

あるいは、if p(C1) then q(C2) else r(C3)はp(C1)→q(C2)かつ¬p(C1)→r(C3)と書き直すこともできるので、 A→B = ¬A ⋁ Bを使って、

(not p(C1) or q(C2)) and (p(C1) or r(C3))

と書いても同じ結果になります。

今回の例では説明を具体的するためにカラムC1, C2, C3と書きましたが、大切なのは述語p, q, rですので、 カラムとは無関係に条件を書くことができます。

愚直なRTLでソートを記述する

FPGAの部屋の記事、 RGB 24ビット・データ入出力対応のメディアン・フィルタをVitis HLS 2021.1で作成する1RGB 24ビット・データ入出力対応のメディアン・フィルタをVitis HLS 2021.1で作成する2にて、HLS記述にてバブルソートを記述し、Interval=1を得ている(1クロック毎にデータを入力できるパイプラインで動作)のを見て、 実はHLSではなく、愚直にRTLで書いてもInterval=1は達成できるのではないかと思い、実験してみました。

ソートをハードウェアで実装するための手法はよく研究されており、ソーティングネットワークと呼ばれているようです。

Wikipediaによれば、3x3(=9)画素のソートを行うためには、7段のソーティングネットワークが最小の段数であるそうです。

“sorting network generator”などと検索すると、ソーティングネットワークの自動生成ツールなどもあり、興味がある方には面白いかもしれません。

書いてみたRTL記述はこちら:

module sort (
    input            CLK,
    input [15:0]     in[0:8],
    output reg[15:0] out
);

    logic[15:0] tmp;
    logic[15:0] in_val[0:8];
    logic[15:0] result;

    int i,j;

    always @(*) begin
        in_val = in;
        for (i = 1; i < 9; i = i + 1) begin
            for (j = 0; j < 9 - i; j = j + 1) begin
                if (in_val[j] < in_val[j+1]) begin
                    tmp         = in_val[j];
                    in_val[j]   = in_val[j+1];
                    in_val[j+1] = tmp;
                end
            end
        end
        result = in_val[4];
    end

    always_ff @(posedge CLK) begin
        out <= result;
    end

endmodule

9個の数値(各16bit)からなる配列inを、上記記事ではC言語で書かれているのと同じ方法でソートしています。 このようなコードは、ある程度RTL記述に慣れた人の方が違和感を感じるかと思います。 ノンブロッキング代入(<=)ではなくブロッキング代入(=)を使っています。

RTLでforループを使用する場合、同じような回路の複数コピーを作成する、というのが用途の大部分を占めると思います。 上記記述もその一例と言えなくは無いですが、どのような回路が合成されるのか、直観的には把握しずらいです。

どのように論理合成が行われるのか、CRC生成回路に実例と共に説明されていますが、要するに、ループ内で使われている変数tmp, in_valに、i, jの値を添え字としてループ毎に別名を付けてあげると思えば、 理論的には展開できるというのが想像できると思います。内側のループ(j)が8,7,6,…,1回回るので、 合計36回ifの部分が展開されることになります。手計算で行おうと思うと気が遠くなりますが、合成ツールは賢いです。

次のようなテストベンチを作ってみます。

module sort_tb;

    logic CLK;
    logic [15:0] in[0:8];
    logic [15:0] out;

    sort dut (.*);

    initial begin
        CLK = 0;
    end

    always #10 CLK <= ~CLK;

    always @(posedge CLK) begin
        in[0]   <=  $urandom();
        in[1]   <=  $urandom();
        in[2]   <=  $urandom();
        in[3]   <=  $urandom();
        in[4]   <=  $urandom();
        in[5]   <=  $urandom();
        in[6]   <=  $urandom();
        in[7]   <=  $urandom();
        in[8]   <=  $urandom();
    end

endmodule

シミュレーションしてみた波形が次です。画面上のsynthはsortに置き換えてください。

シミュレーション画像

緑の入力に対して、1クロック遅れて黄色の出力が得られています。目視でチェックした限り、9つの値の中央値が得られてそうです。

論理合成してみた結果をRTL Viewerで確認してみます。

RTL Viewer

一番右側に一つだけ16bitのレジスタがあって、残りは比較器とマルチプレクサになっています。 何段になっているか、しっかり数えませんでしたが(12段?)、さすがに最小値の7までは行ってなさそうです。

配置配線まで実行してみたところ、Cyclone Vで、ALM 988個、Total registers 16となりました。

ちなみに、久々にQuartusでシミュレーションしようとしたら、ModelSimの起動方法に手間取って、Quartus Prime と ModelSim の NativeLink の使い方を参考にして解決しました。

HaskellでのWebSocketsサーバの効率改善

前回の記事で、HTMLのCanvas要素とWebSocketsの組み合わせで画像転送と表示の実験を行いました。 想定よりもHaskellで作ったWebSocketsサーバの動作が重いため、少し調査して改善しました。

import Control.Exception (finally)
import Control.Monad (forM_, forever)

import qualified Network.WebSockets as WS
import qualified Data.ByteString.Char8 as C
import qualified Data.ByteString.Lazy as L
import qualified Data.ByteString.Internal as BI

import Foreign.Ptr (plusPtr, Ptr)
import Foreign.Storable (poke)
import Data.Word (Word8)

main :: IO ()
main = WS.runServer "127.0.0.1" 9160 application

-- BI.create :: Int -> (Ptr Word8 -> IO ()) -> IO ByteString
fill :: Int32 -> Ptr Word8 -> IO ()
fill seed ptr = 
    go (0, 0) ptr
      where
        go (j, i) ptr = do
            let val = fromIntegral $ seed + i + j
            poke ptr val
            if i == 1919 then
                if j == 1079 then
                    return ()
                else
                    go (j+1, 0) $ ptr `plusPtr` 1
            else
                go (j, i+1) $ ptr `plusPtr` 1

application :: WS.ServerApp
application pending = do
    conn <- WS.acceptRequest pending
    WS.forkPingThread conn 30
    forever $ do
        bytes <- WS.receiveData conn
        let seed:_ = L.unpack bytes
        let seed2 = fromIntegral (toInteger seed)
        buf <- BI.create (1920*1080) (fill seed2)
        WS.sendBinaryData conn buf

ByteString.Internalのcreate関数を使って、転送するバッファの生成と初期化を同時に行います。 fill関数には、createで確保される領域へのポインタが渡されるので、poke関数を使って当該領域に1つずつデータを書き込みます。 go関数で、1画面分ループします。1ループごとにポインタを1進める(plusPtr)ことで、次のWord8にアクセスできます。

このプログラムを試してみると、FirefoxはCPUを60%程度消費する一方、サーバ側は15%程度で済んでいます。

クライアントからリクエストがあるごとに毎回create関数を呼び出しているので、 あまり効率は良くないと思いますが、それでも初期のサーバ律速であった状況からは大幅に改善しました。

もっとも、このようなプログラムにしてしまうと、中身はCで記述するのと大差ないので、 あえてHaskellで書く意義はかなり失われている感があります。

HTMLのCanvasとHaskellでのWebSocketsを組み合わせる

前回、HTMLでCanvasを使用した描画を試しました。 今回は、HaskellでWebSocketsのサーバを作成し、当該サーバからバイナリデータを受信してCanvasに描画するようにしました。

まずは、ブラウザで動作させるファイルです。

<html>
    <body>
        <script
            src="https://code.jquery.com/jquery-3.2.1.js"
            integrity="sha256-DZAnKJ/6XZ9si04Hgrsxu/8s717jcIzLy3oi35EouyE="
            crossorigin="anonymous"></script>
        <p><div id="time">Time[ms]</div></p>
        <canvas id="canvas" width="1920" height="1080"></canvas>
        <script type="text/javascript">
            $(window).on('load', function(){
                var tm = 0;
                var canvas = $('#canvas').get(0);
                var width = canvas.width;
                var height = canvas.height;
                var ctx = canvas.getContext('2d');
                var imageData = ctx.getImageData(0, 0, width, height);

                var buf = new ArrayBuffer(imageData.data.length);
                var buf8 = new Uint8ClampedArray(buf);
                var data = new Uint32Array(buf);
                var start_ms = performance.now();
                var elapsed_ms;
                var cn = new WebSocket('ws://127.0.0.1:9160/');

                cn.addEventListener('message', function(ev){
                    var reader = new FileReader();
                    reader.addEventListener("loadend", function(){
                        var ary = new Uint8Array(reader.result);
                        //console.log(ary[0]);
                        for (var j = 0; j < height; j++){
                            for (var i = 0; i < width; i++){
                                var val = ary[j*width+i];
                                data[j*width+i] = (255<<24) | (val<<16) | (val<<8) | val;
                            }
                        }
                        imageData.data.set(buf8);
                        ctx.putImageData(imageData, 0, 0);
                        if (tm % 60 == 0){
                            var current = performance.now();
                            elapsed_ms = current - start_ms;
                            $("#time").text(elapsed_ms/60.0 + "[ms]");
                            start_ms = current;
                        }
                    });
                    reader.readAsArrayBuffer(ev.data);
                });

                var getData = function(){
                    var abuf = new ArrayBuffer(1);
                    var view = new Uint8Array(abuf);
                    view[0] = tm & 0xFF;
                    cn.send(abuf);
                    tm++;
                    setTimeout(getData, 1);
                }
                cn.addEventListener('open', function(){
                    getData();
                });
            });
        </script>
    </body>
</html>

上記のとおり、ローカルホストで動作するWebSocketサーバとの通信を開き、getData関数を繰り返し呼び出します。

getData関数では、1バイトの配列要素に、0-255で巡回する値を入れて、WebSocketサーバに送ります。

また、受信するmessageのイベントハンドラでは、ev.dataがJavaScriptのBlobなので、readAsArrayBufferでloadenedハンドラと結びつけます。 当該ハンドラでは、reader.resultがサーバから送られてきた生データの配列になります。これを前回の記事と同様、Canvasに描画します。

一方HaskellでのWebSocketsサーバは次コードです。

{-# LANGUAGE OverloadedStrings, ScopedTypeVariables #-}
module Main where

import Lib
import Data.Int
import Control.Exception (finally)
import Control.Monad (forever)
import qualified Data.Text as T
import qualified Data.Text.IO as T

import qualified Network.WebSockets as WS
import qualified Data.ByteString.Char8 as C
import qualified Data.ByteString.Lazy as L

main :: IO ()
main = WS.runServer "127.0.0.1" 9160 application

application :: WS.ServerApp
application pending = do
    conn <- WS.acceptRequest pending
    WS.forkPingThread conn 30
    forever $ do
        bytes <- WS.receiveData conn
        let seed:_ = L.unpack bytes
        let seed2 = fromIntegral (toInteger seed)
        WS.sendBinaryData conn (L.unfoldr (genData seed2) (0, 0))

genData (seed :: Int32) (j, i) =
    if j >= 1080 then Nothing
    else
        if i == 1919 then
            Just (fromIntegral (seed+i+j), (j+1, 0))
        else
            Just (fromIntegral (seed+i+j), (j, i+1))

何かデータを受信したら、先頭バイトを取り出し、Word8に変換して(fromIntegral . toIntegerの組み合わせ)、 unfoldrにgenData関数を渡して(初期値としてWord8を渡す)、ByteStringを生成させます。

genData関数がNothingを返すと、ByteStringの生成は終了されます。 Just (a, b)を返すと、aがByteStringの新しい要素となり、bがgenDataを再度呼び出すために用いられます。

結局、(0, 0)からスタートして、(1079, 1919)まで、(y座標, x座標)の組が引数として渡されるようにしています。

生成されたByteStringはsendBinaryData関数でクライアントに返されます。

WindowsにStackを使ってGHCや必要なライブラリをインストールし、サーバを動作させて、 Firefoxで同一マシンからアクセスしてみました。

…かなり遅い。前回はFirefoxのプロセスが30%程度CPUを消費していましたが、今回は15%未満でした。 その代わり、WebSocketsのサーバを動作させているコマンドプロンプトのプロセスが50%消費しています。 どうやらサーバ側が律速しているようです。

まだ詳細に調査していませんが、sendBinaryDataで単純にファイルの中身のようなデータを送る場合は、 もっと高速に動作している印象でした。そのことからすると、genDataの繰り返しが遅いのではないかと想像しています。

2017/12/20追記:ちょっと調べたところ、ByteStringはBuilderを使って生成したほうが速いらしいので、 Haskell側のプログラムを以下のように修正しました。

{-# LANGUAGE OverloadedStrings, ScopedTypeVariables #-}
module Main where

import Lib
import Data.Int
import Control.Exception (finally)
import Control.Monad (forM_, forever)
import qualified Data.Text as T
import qualified Data.Text.IO as T

import qualified Network.WebSockets as WS
import qualified Data.ByteString.Char8 as C
import qualified Data.ByteString.Lazy as L
import qualified Data.ByteString.Builder as B

main :: IO ()
main = WS.runServer "127.0.0.1" 9160 application

infixr 4 <>
(<>) = mappend

application :: WS.ServerApp
application pending = do
    conn <- WS.acceptRequest pending
    WS.forkPingThread conn 30
    forever $ do
        bytes <- WS.receiveData conn
        let seed:_ = L.unpack bytes
        let seed2 = fromIntegral (toInteger seed)
        WS.sendBinaryData conn (B.toLazyByteString (genData seed2 (0, 0)))

genData (seed :: Int32) (j, i) =
    if i == 1919 then
        if j == 1079 then
            B.word8 (fromIntegral (seed+i+j))
        else
            B.word8 (fromIntegral (seed+i+j)) <> genData seed (j+1, 0)
    else
        B.word8 (fromIntegral (seed+i+j)) <> genData seed (j, i+1)

大枠は同じですが、unfoldrの代わりに、toLazyByteStringを使用し、 genDataはword8を使用してBuilderを生成します。各画素のBuilderはmappend(<>)にて連結されます。

これで試してみたところ、Firefoxは30%程度まで負荷が上がったので、効率は多少上がったかもしれません。 それでも、まだHaskell側が50%消費しています。ごく単純なプログラムなので、これはいただけません。

仕組みの検証はできましたが、もう少し速くしたいところです。 今度はRustあたりで作成してみようかと検討しています。

2017/12/21追記ByteStringあれこれを見ると、 Internalを使わないとパフォーマンスを出すのは難しそうですね。 mallocByteStringしてからscanrなどで置き換えていくのが良いのかもしれません。 また別途試してみたいと思います。

1/2 »