2020-07-04

rust-trace-event-profilerでtokio::runtime

rust

最近のRustではThread制御までライブラリに任せられるようなので、その機能を使って前回作ったTrace Eventを作るやつで挙動を可視化してみました。

let mut rt = tokio::runtime::Builder::new()
    .core_threads(6)
    .threaded_scheduler()
    .build()
    .unwrap();

rt.block_on(async move {
    let events = put_ten_block().await;
    save_file("flow.json", events);
});

f:id:torini:20200704195314p:plain

async fn put_ten_block(item: TimelineItem) -> Vec<TraceEvent>;

async関数を利用するだけでタスクを適切にスレッドに割り振ってくれています。素晴らしい。

2020-06-30

Rustでプロファイリングの可視化

github.com

Rustのプロファイラを書きました。
正直Rustの知識が浅いのでまともなプロファイラが書けるとは思っていないのでプロファイラ部分はおまけでTrace Event Formatへのシリアライズ定義が本体かなと思っています。
タイムスタンプにオフセットかけたりしたかったのですがserdeでシリアライズ可能にしたTrace Event Format定義が複雑過ぎて悩んでいます。
現状だとPhase毎に追加しないといけなくなりそう。

derive_builderがenum定義のビルドがそのままではできないことも難しい。

rust-derive-builder/build_method.rs at v0.9.0 · colin-kiegel/rust-derive-builder · GitHub

の定義だと

enum Type {
  A { value: u32 },
  B { value: u64 },
}

のような定義、T::Aのビルダーを作成することができない。
struct定義をenumの外部に配置するとできるが、今度はserdeによる自動シリアライズが上手くいかない。

文字列の管理に関してもラベルテーブルのようなものを用意して割り当てることが妥当だがシリアライズとの兼ね合いが難しい。

しかし、Rustの構文木を変更できるマクロやアトリビュートには可能性を感じますね。 RustでRustのコードを生成している様子はリフレクションの未来を感じました。

2019-12-09

VS2019のCMakeインストールパス

export PATH="$PATH:/c/Program Files (x86)/Microsoft Visual Studio/2019/Community/Common7/IDE/CommonExtensions/Microsoft/CMake/CMake/bin"

2019-08-19

喜びは映像にしないと半分も伝わらない

2015年のジャーナルですが面白かったので紹介します。

音声に含まれる感情の認識(pdf)

日常的な事柄を例に使っており非常に読みやすいので、直接読む方が良いかもしれません。
特に興味深かった箇所を引用します。

「悲しみ」のように音声だけであっても 60％程度伝わるものがある一方，「喜び」では，映像等すべて見れば 69％程度伝わるのに，音声だけでは 32％しか伝わらない

私達が小さな小窓であっても顔映像を好むのは、この37%の喜びを理解できるからかもしれませんね。

2019-06-26

MSVCでも頑張ってC++20で導入されるspanを使う

C++

wandboxではspanを利用できるので動作確認だけならそちらが簡単です。

何故人はstringを使わないのか

stringは内部バッファに文字列を蓄えるので例えば

std::vector<std::string> Split(const std::string& text);

みたいな関数があった時に入力のテキストと出力の分割文字列で重複があるので無駄が多いと感じます。
そこで、区間を表す構造体が欲しくなります。

span

struct Span{
  char* pointer;
  size_t size;
};
std::vector<Span> Split(const std::string& text);

これで最小限の情報だけで関数を表現できたが、区間を入手したらその区間をイテレートしたいと思うのは自然なことでしょう。
分割したいアイテムが文字列じゃない場合を想定してテンプレートでSpanを書きたくなるかもしれません。
自分で書くのが億劫になってきました。

ちなみに文字列用のspanとして専用の<string_view>が存在するので、本来ならこっちを使うべきです。
MSVCの最新版では現在でも利用することができます。
string_viewをstring_spanにする案もあったそうですが、通らなかったんですかね。
string_viewはstringとほぼ同じ動作をし、無駄なnull終端を管理しません。
文字列を扱う場合はstring_viewを使いましょう。

#include <iostream>
#include <span>
#include <string_view>

template<class T>
void Print(T&& t){
    std::cout << t.size();
    for(auto i : t){
        std::cout << ",[" << i << "]";
    }
    std::cout << std::endl;
}

int main(){
    const char text[] = "ab";
    Print(std::span(text));
    Print(std::string_view(text));
}

//出力
//3,[a],[b],[]
//2,[a],[b]

utf8

更に横にそれますが、C++20になってchar8_tというutf8用の型が提供されるようになったので実際に使われる文字列はstd::u8string_viewが多くなるでしょう。

spanの使い道

コンテナの一部区間を出力したり、バイナリのチャンク分けの際に活躍します。
これらは上記と同じ問題が発生します。そこでspanの出番です。

ただ、概念を考えれば分かる通りspanやviewのスコープは参照元よりも短い必要があります。

現在のMSVCの最新版でもまだspanは導入されていません。C++20で入ることを考えると待っていたらリリースされそうではありますが、今欲しいとなると中々面倒です。

spanの導入

spanはCppCoreGuidelinesで提案されている概念の実装であるGSL (Guidelines Support Library)に含まれています。
今回はその中でもMicrosoftによる実装であるms-gslを利用します。

$ git init
$ git submodule add https://github.com/microsoft/vcpkg
$ cd vcpkg
$ ./bootstrap-vcpkg.bat
$ ./vcpkg.exe install ms-gsl
$ cd ..
$ touch main.cpp
$ touch CMakeLists.txt
$ cmake . -DCMAKE_TOOLCHAIN_FILE=vcpkg/scripts/buildsystems/vcpkg.cmake
$ cmake --build .

cmakeがinstall済みではない場合vcpkgが使っているものが以下にあります。
vcpkg\downloads\tools\cmake-3.14.0-windows\cmake-3.14.0-win32-x86\bin\cmake.exe

// main.cpp
#include <gsl/span>
// 上記と重複部分省略

int main() {
  Print(gsl::make_span("ab"));
}

# CMakeLists.txt
cmake_minimum_required(VERSION 3.1)

find_path(include_root_dir NAMES gsl/span)
include_directories(${include_root_dir})

add_executable(main main.cpp)

2019-06-13

Texture Atlasの生成

Texture Atlas

1回のレンダリングで利用できるテクスチャの枚数は限られているので、複数のテクスチャを1枚のテクスチャにまとめることは非常に重要です。
この色々なテクスチャをまとめたテクスチャをTexture Atlasと呼びます。
今回はこれの作り方をいくつかメモしておきます。

Knapsack problem

入れ物に可能な限り多くのテクスチャを格納するという観点から考えるとナップサック問題として取り扱えるように思えます。
更にMulti-dimensional knapsack problemの項目を読むと2Dナップサック問題の解法としてIHS (Increasing Height Shelf) algorithmというものが存在しているらしいです。

Increasing Height Shelf

まだ論文をちらっと眺めただけですが、最大の高さのアイテムに合わせたラインにそって並べる方法のように見えます。
下記で実装されている方法がそのような挙動っぽいので下記アルゴリズムとの違いを調査したいところです。

下が揃っているラインを複数段作っていくからShelfなんですね。面白いネーミング。

Skyline Bottom-Left algorithm

https://github.com/nothings/stb/blob/master/stb_rect_pack.h
上記ではSkyline Bottom-Left algorithmを利用しているそうです。

2019-04-29

英語の専門用語

概要

いざ学問としての英語を勉強しようとしても、日本語だと受験勉強や資格、PV目当てのブログみたいなのばかり出てきて効率が悪いです。
そこで、学問としての英語で使われている専門用語が出発地点とならないかなと列挙してみました。

Mood

日本語では法と訳されています。文法を学んでいる時に～法とか言われても法則にしか見えないので、ややこしい訳語を当ててしまったものですね。
仮定法(Subjunctive mode)や法助動詞(Modal auxiliary)等の日本語が割り当てられています。

Grammatical mood - Wikipedia

直接法(Realis mood)と非直接法(Irrealis mood)が対比されています。
非直説法は対訳が見つからなかったので私が暫定的に付けたものです。
直説法が事実だと表明する際に使うのに対して非直説法は実現していない事柄を表明します。
学びたてでまだまだ確かなことは言えませんが、英語には実現した事柄と実現していない事柄を明白に分ける表現が重視されているように感じます。

このMoodが文章の発話者、記述者の気持ちを表現するものということを知ると同じ対訳が与えられている英語表現にも違いが見えてきます。
法助動詞(may, shall, must, will)はwikipediaを読む限りでは複合動詞として機能しているようなので動詞に主観を導入していると考えられます。
実際、関さん関連の書籍でもmustを客観的状況で使う場合はhave toを、willを客観的状況で使う場合はbe going toを、wouldを客観的状況で使う場合はused toを使うと書かれています。

上記概念が面白いのは文章に全く関係ない第三者がひっそりと登場していることです。
例えばHe must work.という文章は彼が働くべきだと考えている人によって表現されたものであり、根拠がなくても使うことができます。一方、He has to work.とした場合には暗黙的にしろ明示的にしろ客観的な根拠を元に働くべきだと表明していることになります。これは文章の表現者は彼が働かなくても良いと思っているが気持ちを隠して表現した場合等にも該当します。
日本語だと「～すべき」という表現だけでは主観なのか客観なのか分からないので不思議な感じです。例えば「彼と同じ境遇でも働いている人がいるので、彼も働くべきだ。」という日本語は根拠も付いているので客観的なように見えて実は感情的で主観的な文章です。日本語でhave toを表現するには「彼と同じ境遇でも働いている人はいるので、彼も働くべきだという意見も出ている。」となるでしょうか。反対に主観だと明示する場合には「彼も働くべきだと私は考えている。」とかですかね。こうして考えると日本語は基本は主観で表現されているのかもしれません。そうだとすると、wikipediaや本での参考文献への参照が英語のものと比べると遥かに少ないことにも納得できます。主観の場合根拠の提示義務がないですから。

end-focus

新情報、旧情報、そしてend-focusです。英語では新しい情報、強調したい情報を最後にもってくることで特定の文脈を強調するようです。
文章の先頭に新情報を持ってくることを嫌うので仮主語としてThere等を用いることがあります。
また、受け身も目的語が旧情報の場合それを主語とすることで新情報を後ろに持ってくることを目的として作られる場合もあるようです。
同じ意味の文章が多数ある場合が多いですが、それぞれ強調する場所が異なってくると考えれば良さそうです。

Strong form / Weak form

英語の発音には強形 (Strong form)と弱形 (Weak form)という2種類の発音があるようです。
通常の会話では弱形が使われるので省略した感じの発音に聞こえるようです。

有声化

母音に挟まれた[t]は有声化して[d]と発音するという現象らしいのですが、簡単に調べただけでは有力な情報を得られませんでした。

変種

variety(変種)は文法規則の亜種を指します。例えば3単現に -s を付けない規則等が変種としてありました。

語彙拡散

語彙拡散(lexical diffusion)はWikipedia にもあるように、ある語彙の発音が他の語彙に伝搬していくという現象。最終的に全ての同型の語彙に伝搬するという説と、全部には伝搬しないという説があるらしいです。

該当する専門用語が見つからなかったもの

英語ではまだ起きていないことには原形を使うという考えがあると関さん関連書籍に書いてあったのですが、該当する概念の専門用語は見つけられませんでした。

to不定詞は未来志向で、動名詞は反復のイメージという記述は散見されるが該当する専門用語は見つけられませんでした。
未来志向ということはまだ実現していない、そういうイメージが持てると面白いですね。

その他面白そうな読み物

上記の単語を調べている内に出会った良さそうな情報源。

英語音韻論
英語の発音に関する情報が良くまとまっています。かなり専門的で難しく感じます。

hellog〜英語史ブログ
英語の歴史が書かれています。

英語研究教室 | 美誠社（英語教育図書出版）
英語の文法に合致しているかを学問的に検証するということを行っていて面白いです。

ぷろみん

プログラミング的な内容を扱ってます