仮想通貨掘りたい

はじめに

この記事は KMCお絵描き Advent Calendar 2017 - Adventar の 20日目の記事です。*1 前回の記事は id:lastcat さんによる KMCお絵かきアドベントカレンダー 12/19 - lastcatのブログ でした。 ねこさん、奈良で修行のように同人活動に精を出していてすごいです。

最近は全然絵を描いていなかった*2ので、 一念発起して絵を描く気力を出そうとしてお絵かきアドベントカレンダーに登録してしまいました。*3

マイニングしたい

最近は仮想通貨の高騰がすごいですね。 バブルバブルだなんて言われていますが、それに乗っかってマイニングしている人々を見ていると 楽しそうだなーと思ってにやにやしてしまいます。 多分今の時代、マイニングするのもそんなに難しくないんでしょうけれど、 取り掛かったあとにはずっとチャートグラフとにらめっこする生活が待っているかもしれないと思うと、 なかなか取り掛かることができずにいています。

家に強いサーバーもないので、もしも採掘するとしたらクラウドVPSとか借りるのかな? VPS といえば ConoHa *4 のこのはちゃんかわいいですよね。

というわけで、 仮想通貨を掘るこのはちゃんを描いてみました。

f:id:CHY72:20171221063741p:plain

最後に

GPUでがっぽがっぽ*5掘って稼いで夢の億万長者になりたい!

仮想通貨バブルが弾けて露頭に迷ったこのはちゃんをごにょごにょする薄い本ください。

明日(今日)のKMCお絵描きアドベントカレンダーは kuniv_bu くんによる リディー&スールのアトリエ発売&アトリエ20周年おめでとうございます!! - ぶろぐ おぶ ぶ です。 彼の池田屋の記事よかった。

*1:一日遅刻!

*2:Piet は描いていたし、なんならPietで修論書きたい

*3:一日遅刻!

*4: https://www.conoha.jp/

*5:ConoHaってGPU使えるんですかね?

ゆーま!(きららベース) が神

この記事は まんがタイムきらら Advent Calendar 2017 - Adventar の 12/20 の記事です。 一個前の記事は枚方さんの Mon Dec 18 2017 でした。かわいい。

はじめに

f:id:CHY72:20171219044950p:plain

瀬名慈孝先生*1の「ゆーま!」というマンガがあります。 seiga.nicovideo.jp この作品は きららベース*2 で公開されており、 隔週火曜日に更新されています。

この作品の主な登場人物は以下の三人*3です。

⬇伊吹。天才美少女発明家! 悪意を持ったドラえもん

f:id:CHY72:20171219043249p:plain

⬇恵那。世界有数の財閥の娘! 笑顔と富で人を地獄に導く

f:id:CHY72:20171219043336p:plain

⬇瑞穂。ちょいガサツ系美少女!この作品唯一のツッコミ

f:id:CHY72:20171219043743p:plain

この三人を中心にして タイトル通り 「ゆーま」*4、 つまり「UMA」こと「Unknown Mysterious Animal」*5 を 研究*6 したりしていく学園物語です。

UMAの中ではよくゴリラやプラズマが出たりします。

f:id:CHY72:20171219050146p:plain

あとは ツチノコが出たりします。

f:id:CHY72:20171219050401p:plain

なんだか不穏なコマばかりですね。 でも、こんなに不穏でも きらら作品 なのです。 なぜならこれが美少女である彼女らの彼女らなりの日常なのですから…。 僕もこんな不穏な生活をしたい。 不穏な非日常に染まった日常、最高じゃないですか?

ゆーま!は 神

f:id:CHY72:20171219050017p:plain

ゆーま!は本当に伸び伸びとシュールギャグが繰り広げられます。 王道な「実家のような安心感」的なギャグマンガとは真逆で、 毎話毎話斬新な切り口からこの作品の日常は綴られて行きます。

f:id:CHY72:20171219045819p:plain

⬆ 番外編でも無いのにいきなり歴史改変しだしたりする

「ゆーま!」は「きらら」を維持出来る作風とシュールギャグの調和が取れた素晴らしい位置にいます。 つまり、美少女成分を感じながらシュールギャグを楽しめる最高の神作品であるといえます。

f:id:CHY72:20171219043106p:plain

⬆作品内でもちょっと言及されている

また、他のギャグマンガと比べてこの作品の優れている点として、 自虐ネタや自分の尊厳を捨てるようなボケが極めて少ないという点が挙げられます。 そういったネタは低俗できらら性とは極めて正反対のものです。 それが排除されているわけですから、読んでいて不快になることもなく 美少女成分とギャグ成分を安心して摂取できるというわけなんですね。

f:id:CHY72:20171219065816p:plain

⬆ ちなみに低俗なボケはゴリラが引き受けてくれる

僕は大学四回生になるのですが、先の見えない将来や、 マンネリ化した大学生活に最近やや鬱気味になってしまっています。 そんな中、隔週更新されるこの神作品が心の支えとなって 僕は今まで生き延びてこられました…。

f:id:CHY72:20171219053443p:plain

⬆こういう奇妙な絵図が出てくるとそれだけで心踊る

大学生はセンセーショナルな欲求に身を任せたくなるものです。 この作品はふらっと社会派マンガになったりセンセーショナルな話題に 突っ込んだりしてくれます。 それが生きる希望となり、また明日も頑張ろうという気持ちにしてくれます。

f:id:CHY72:20171219042405p:plain

⬆ 伊吹さんは無政府主義者です

f:id:CHY72:20171219045851p:plain

⬆ センセーショナルな発言がホイホイ飛び出す

f:id:CHY72:20171219042908p:plain

⬆ 危ない

今までの吹き出しのツッコミは全て瑞穂ちゃんのものです。 彼女はゴリラの通訳も手がける苦労人です。 お疲れ様です。

最後に

あ、そうだ。きららファンタジア出演おめでとうございます f:id:CHY72:20171219033542p:plain 特に伊吹は☆5のアルケミストで全体バフがかなり強くて万人にオススメできるキャラになってましたね。 何はともあれおめでとうございます。*7

明日のまんがタイムきらら Advent Calendar は nonamea774 さんの もっと自由に4コマを! - /dev/nona (いっと☆わーくす!) です。 失われしきらら…

参考

kindle で一巻と二巻と三巻が出ているので是非購入しましょう。 ゆーま!は復活すると信じています.

f:id:CHY72:20171219044541p:plain

ゆーま! (全3巻) Kindle版

*1:twitter:fno8

*2:http://seiga.nicovideo.jp/manga/official/kirara

*3:ちなみに苗字はまだ決まってないことが作品内で示唆されています

*4:作品内で「ゆーま」なんて可愛く表示されたことはない

*5:本当は Unidentified Mysterious Animal、作品内で素で間違えている

*6:復讐

*7:この画像は嘘に嘘を塗り固めたコラ画像ですが、東京オリンピックまでには実装されていると思っています。

競プロを楽しむためのNim言語

この記事は KMC Advent Calendar 2017 - Adventar 16日目の記事です。 ついでに、 Nim Advent Calendar 2017 - Qiita の 16日目の記事でもあります。 前日のKMCアドベントカレンダーの記事は asRagi さんの 【KMCAdventCalendar2017】カンタン味玉のススメ - らぎメモ でした。

asRagiさんお誕生日おめでとうございます! 最近のasRagiさんは料理している人みたいなイメージが出来つつあります。 僕も自炊で冬を乗り切りたいです。

以下は関連記事です。

興味を持った方はこちらも御覧ください。

はじめに

競プロをやっているみなさん、C++書いていますか? ところでC++辛くないですか? 速さのために色々と犠牲にしていませんか? Nimっていう最高の言語があるんですけどお話だけでも聞いていってもらえませんか?

はい。

というわけでこの記事では競プロのような問題に Nim 最高と永遠に褒めていきます。 Nim 自体はまだver1.0にも満たない開発途中なマイナーな言語ですので、知らない方も多いと思います。 そうですね…Nimは雑にまとめると 爆速静的型付けGCありお手軽言語 とでも言えましょうか。 以降では主に似た方向の静的型付け手続き型言語との比較をしながらNimのよさを語っていきます。 Nimを知らなくても雰囲気だけ伝われば、この記事を読み終わる頃にはあなたもNimを讃える一人となっているでしょう…。

目次

  1. お手軽 マイナスインデックス配列
  2. お手軽 定数分割代入
  3. お手軽 C++連携
  4. お手軽コンパイル時計算
  5. お手軽 for文
  6. お手軽 range-based for 文
  7. DよりきれいなUFCS
  8. 楽しいオレオレ構文

お手軽 マイナスインデックス配列

問題によっては負のインデックスを使えると効率的ないしは理解しやすいことがあります。 与えられた x の範囲が -50 から 50 など負を含み、その x をインデックスとする配列が作れると楽な場合とか。 C++であれば

int data_raw[100] ; 
int *data = &(data_raw[50]) ; 
data[-10] = 72 ; 

みたいなテクでしたっけ。 さすがにポインタを使わない他の言語ではこういうことは出来ないですよね。

Nim は変態なのでできます。

var A : array[-50..50,int]
A[-10] = 72

ワーオ、変態! ちなみに、RubyPythonでは負のインデックスは配列の後ろからの番号を指しますので、 なんだか変な感じもします。

お手軽 定数分割代入

C++で入力の数値を const な状態で取得するにはどうしていますか ? 多分こうしますよね。

const int n = [](){
  int tmp = 0;
  std::cin >> tmp;
  return tmp;
}();

いいですね。安心です。 では、よくある競プロ入力な 1 2 33 444 5\n2 2 23 244 5\n3 2 33 344 5 のように 列の数が固定で決まっている場合は各行をどのように取りますか ? 上の関数を5回仮にget_int_from_stdinと名付け、こう書きますか ?

const int n = get_int_from_stdin();
const int m = get_int_from_stdin();
const int x = get_int_from_stdin();
const int y = get_int_from_stdin();
const int z = get_int_from_stdin();

にゃーん。 テンプレートを駆使すればもうちょっと行けるかもしれません。 まあでもC++テンプレートはちょっと闇なので触りたくないですね。

Nim ならこう書けます。 まずは一つ

let n = stdin.readline().parseInt()

続いて複数。

macro toTuple*(rhs: seq,cnt: static[int]): auto =
  let t = genSym(); result = quote do:(let `t` = `rhs`;())
  for i in 0..<cnt: result[0][1].add(quote do:`t`[`i`])

let (n,m,x,y,z) = stdin.readline().split().map(parseInt).toTuple(5)

ワーオ、複数分割代入最高! toTupleマクロをちょっと書く必要がありますが、これが大変便利です。 なんせ、問題に従って変数名を直感的にそのまま書くことが出来ますし、なんと全て定数です! このtoTupleマクロは、

let (n,m,x,y,z) = (let t = stdin.readline().split().map(parseInt);(t[0],t[1],t[2],t[3],t[4]))

toTuple(5) で済ましています。 (;;...;;)と複数繋げて最後が返値となるのですね. 僕が競プロでNimを使いたい理由の一つがこれです。最高です。

(注) Nim 0.18 からは構文木の構造が変わり,上記 toTupleコンパイルできなくなります. 代わりに下記をお使いください

macro toTuple*(arr: auto,cnt: static[int]): auto =
  let t = genSym(); result = quote do:(let `t` = `arr`;())
  for i in 0..<cnt: result[1].add(quote do:`t`[`i`])

お手軽 C++連携

こういう言語では C++ と連携したいことが時々あります。 例えば、ちょっと前までの Nim には PriorityQueueがありませんでした。 そんな時、C++のPriorityQueueを使えれば楽ですよね。

type
  CPriorityQueue {.importcpp: "std::priority_queue", header: "<queue>".} [T] = object
proc cNewPriorityQueue(T: typedesc): CPriorityQueue[T]
  {.importcpp: "std::priority_queue<'*1>()", nodecl.}
proc newPriorityQueue*[T](): CPriorityQueue[T] = cNewPriorityQueue(T)
proc size*[T](this: CPriorityQueue[T]):int {.importcpp: "#.size(@)", nodecl.}
proc push*[T](this: CPriorityQueue[T],x:T) {.importcpp: "#.push(@)", nodecl.}

だいたいこんな感じに書くだけで使えます。便利。 使うときも、

var pque = newPriorityQueue[int]()

のように何の問題もなく使えます。最高。 応用はこちら https://qiita.com/sessions/items/96c57a4dad9246d2cd59

お手軽コンパイル時計算

例えば素数テーブルを生成する関数を以下のように定義出来ます。

proc getIsPrimes(n:int) :seq[bool] = 
  result = newSeqWith(n+1,true)
  result[0] = false
  result[1] = false
  for i in 2..n.float.sqrt.int :
    if not result[i]: continue
    for j in countup(i*2,n,i):
      result[j] = false

はい。 これを使う時は、普通は

let isprimes = getIsPrimes(100)
echo isprimes[17]

のように使います。キーワード let で宣言しているので、 この関数の計算は実行時に行われます。 コンパイル時に計算したければ

const isprimes = getIsPrimes(100)

と、 letconst に変えるだけ!超便利! C++ だと constexpr の制約があったり、そもそも関数をconstexpr にしないと いけなかったり、色々めんどくさいですよね!Nim最高!

お手軽 for文

この節では 0 から n まで昇順列挙するfor文について述べます。

個人的に競プロのfor文のREPの文化が好きです。 REP は大抵以下のようなマクロです。

#define REP(i,n) for(int i = 0 ; i < (int)(n) ; ++i)

このマクロは以下のように使用できます。

REP(i,20) std::cout << i << std::endl; 

もちろん、#define によるマクロが悪であることなどは言うまでもありませんが、 競プロに類する問題ではこれは効率的な記法として一定の支持を集めていることは 否定出来ないと思います。 range-based-forと違ってインデックスがとれれば配列の中身を変更できるし インデックスを元にして別の変数と連携して計算できる基本的で最も使用される文なので、 そこが最適化されてしまえばこうなるのでしょう。

はい。

ところで kotlinだと

for (i in 0..20) print(i)

と書けますが、i の範囲は [0,20] であり、

for (i in 0 until 20) print(i)

と書かないと i の範囲を [0,20) に出来ません。 一貫性がなくてめんどい。 D言語だと iota を作ったりします。

さて、Nim はこんな感じで書けます。

for i in 0..<20: echo i

ここの < に注目です。これがあるとiの範囲は[0,20)になり、 これがなければ、iの範囲は[0,20] になります。 わかりやすいですね。これはswiftでも同じです。 最高ですね。

お手軽 range-based for 文

C++ には range-based for文があります。

for(auto d: data) std::cout << d << std::endl;

便利ですね。 しかしながら、そのインデックスを取得するのはちょっとめんどいです。

for(const auto& d:data) auto index = &d - &data[0];

にゃーん。

D言語のrange-based for文は

foreach(d;data) writeln(d);

のように書け、インデックス付きは

foreach(i,d;data) writeln(i," ",d);

のように書けます。かなりいいですね。 ただ、何重にもなると foreachと書くのもちょっと長いような気もします。

ところで Nim は簡潔に書けます。

for d in data: echo d

d の型は勝手に推論してくれるので C++のように auto とか書かなくてもよくて便利です。 index が欲しければ

for i,d in data: echo i," ",d

と書けて便利です。

DよりきれいなUFCS

D言語のUFCS、実はちょっと癖があって使いにくいです。 クラス内で宣言するメンバ関数とUFCSで擬似的にそう見える関数と二重に 定義出来てしまうせいで、ごちゃごちゃしてしまうことがあります。 Nim はメンバ関数とかはなく全て普通の関数記法で書き、モジュール内でエクスポートするものとしないもので分ける設計なのでそのような心配はありません。 Nim 最高!

楽しいオレオレ構文

template times*(n:int,body:untyped): untyped = (for _ in 0..<n: body)
template `max=`*(x,y:typed):void = x = max(x,y)
template `min=`*(x,y:typed):void = x = min(x,y)

の3つを主にオレオレ構文として定義しています。

# n回 hoge と出力
n.times: 
  echo "hoge"

とか、

# data[i][j] = max(data[i][j],data[j][k]) と同義
data[i][j] .max= data[j][k]

とか。 times は ただのforと比べて変数が増えないし便利ですね。 C++の雑魚マクロと違って本当に変数が増えないんですよ? マクロ定義に使用した変数 _ は使う側では見えないんですよ? 最高じゃないですか? C++のマクロって本当にクソですよね?

max=+= のノリで max を適用した感じのオレオレ構文です。 お行儀悪いですが地味に便利なので使ってしまいます。

最後に

以上、Nimの便利だと思う機能をつらつらと書かさせていただきました。 ここまで読んでくださり、ありがとうございました。

Nimに興味を持たれたら、 Nim Advent Calendar 2017 - Qiita を読んだり、 Nim Programming Language を読んだりしてください。

明日のKMC AdventCalendar は id:kazakami さんによる MinecraftでFPGA - kazakami_9’s diary です! マイクラFPGAいいですね、いいです、すごくいいです。

ISUCON7本戦でBigintを殺したかった話

注意:このブログではGo言語のBigint(多倍長整数)について触れています
12/6 追記:殺せました

こんにちは。 ISUCON7本戦に「百万円ドリブン」の一員として参加しました。 メンバーは僕と, @nakario, @aokabi の三人で,二人はサークルのメンバーです。 集中のあまり美味しいお昼のクッキーと珈琲は逃してしまいました。

結果はタイトルの通りであり、競技時間内ではネックとなっていた Bigint を殺すことが出来ず、 悔しかったのでBigint周りで試行錯誤をした結果について述べます。 具体的には、Bigintと__float128について述べます。

今回のボトルネック

ボトルネックの測定と発見は @nakario が率先してやってくれました。 僕の改善担当箇所はそれにより判明したボトルネックの一つ 「Bigint の10進上位15桁の取得」 でした。

初期実装

初期実装では、Bigintを一旦文字列に変換してから先頭から15文字をとるという実装になっていました。 ベンチマークを回すと分かるのですが、このBigintは15万桁程度まで達する可能性があり、 すなわち15万文字の最初の15文字のみしか使わないということが平気で起こり、 遅いのも容易に理解できます。これは改善しなければなりませんね。

改善案

Go言語ではBigintはuint(符号なし64bit整数)の配列として表現されています。 単純に思いつく改善方法は、上位15桁さえ分かればよいので、 その配列の上位2つのuintからその数字を近似して計算する方法です。 例えば、 45桁の整数 111112222233333444445555566666777778888899999
= 326529 × 2128 + 8741109308212120013 × 264 + 7629705161560292767
となっているわけですが、これを上位2つのみを使用し、
326529 × 2128 + 8741109308212120013 × 264
= 111112222233333444445555559037072617328607232
と近似します。 計算すれば分かることですが、桁が増えても上位2つのみを用いればよいことに変わりはありません。 上位2つを用いて近似することにより、桁数オーダーだった部分を改善することが出来ます。 こうすれば BigIntを一つも使わなくてもよくなり、大幅な改善が見込めますね。

実装と精度の問題

上記の案をそのままuint64やfloat64で計算すると桁は容易に溢れるので、 log10 して計算し、最後に10の指数で戻せばよいです。楽勝ですね。



なーんてことは無かった…。 そもそもfloat64は15.9桁までしか整数との1対1対応を保証してくれません。 今回必要な桁は15桁、かなりギリギリです。 log10したり演算をすると、微妙に2桁程度合わないのです…。 ISUCON中ずっと「あと2桁!!あと2桁なんや…!!」って叫んでいました。 本質的に精度が微妙に足りないのです。 このあと僕は迷走してしまい、ISUCONは敗北を期しました。

こたえ

15桁全てを合わすことは到底不可能でも、それが何桁かどうかは精度の問題なしにすぐに計算できます。 よって、桁数を計算しもとのBigIntからその10の桁数分で除算するという方法がとれます。
例えば 111112222233333444445555566666777778888899999 / 100000000000000000000000000000
を行い 111112222233333 にするような感じです。 本質的にはBigIntをStringに変換する処理がBigInt除算の処理に変わります。 実はこれだけでかなり高速になり、 初期実装からこの部分のみを変更してベンチマークを走らせたところ、(ネックは他にもあるので一概には言えませんが) 7000点程度だったものから14000点まであがり、スコアが二倍になりました… はいbigintゲーwwwwwwwwww

bigint許さん

しかしながらこんなにも僕を困らせてくれる bigint 、殺すしかありません。 なんとしてでも bigintを実装から全て消し去り心の平穏を取り戻したいものです。 さて、僕の最初に思いついた実装方法は、精度が足りなかっただけなわけですから、 もっと精度の高いものを使えばbigintを使わなくても実装できるはずです。 残念ながら Go言語には float64までしかありません。 float128くらいまであればよいのですが…



はい、というわけで GCC の __float128 を使ってみましょう。

__float128

__float128 の枠組みは、疑似四倍精度とも呼ばれ、ソフトウェア的に float64を複数用いることで 擬似的に4倍精度を達成する枠組みです。 gccコンパイルすれば簡単に使えるので、Go言語とC言語を繋ぐ cgo を用いれば上手くできそうです。 cgo では、C言語コンパイルしたい関数を書いたC言語のコードを用意し、 そのインターフェースとコンパイルフラグ等をgo言語でシュッと記述すると簡単に二つを繋ぐことができます。 以下にCとGoのコードを載せます。

#include <math.h>
#include <quadmath.h>
typedef unsigned long long UINT64;
void myb2e(UINT64 w1,UINT64 w2,UINT64 bef,UINT64 *o_keta,UINT64 *o_res){
  __float128
    fw1 = w1,
    fw2 = w2,
    log10ed = (64 * bef) * M_LN2q / M_LN10q
              + log10q(18446744073709551616.0Q * fw1 + fw2),
    res = expq((log10ed - floorq(log10ed)) * M_LN10q) * 100000000000000.0Q;
  *o_keta = (UINT64)log10ed - 14;
  *o_res = res + 0.000000000000001Q;
}
package main
//#cgo LDFLAGS: -lquadmath
//#cgo CFLAGS: -O3
//#include <stdlib.h>
//typedef unsigned long long UINT64;
//extern void myb2e(UINT64 w1,UINT64 w2,UINT64 bef,UINT64* o_keta,UINT64* o_res);
import "C"
func B2E(w1, w2, bef uint64) (keta, res uint64) {
    var o_keta C.UINT64
    var o_res C.UINT64
    C.myb2e(C.UINT64(w1), C.UINT64(w2), C.UINT64(bef), &o_keta, &o_res)
    return uint64(o_keta), uint64(o_res)
}

はい。bigintを殺せました。勝利ですね。 早速ベンチを回しましょう…。




6 0 0 0 点!!!

初 期 実 装 よ り 遅 い !!

イヤイヤイヤイヤ、オイオイオイオイ… cgoのオーバーヘッドが意外と大きいのか?と思って計測してみましたが、 そういうわけでもなく、純粋に __float128 が遅いようです…。まじかぁ…

まとめ

BigIntを殺そうとしたが結局BigIntを完全に殺すことはできなかった。 BigIntくんも__float128くんよりは生かす価値があるようだ、命拾いしたな…

この記事を読んだ人はこんな記事も読んでいます

aokabit.hatenablog.com

nakario.hateblo.jp

全コード

github.com

12/6 追記 (実質Bigintを殺せた)

Bigint同士の除算は桁数オーダーの時間が掛かりますが、 初期実装の段階では上記の改善のみでよさそうです。 この後、更に高速化してもう一度この部分がネックになってきた場合には、除算を上位の3つのuintのみで行えばよいですね。 この実装であれば実質BigIntを殺したといっても過言ではないのでかなり満足です。

// 桁数が増えても大丈夫
func customBigIntDiv(a *big.Int, b *big.Int) int64 {
    alen := len(a.Bits())
    if alen < 4 {
        return big.NewInt(0).Div(a, b).Int64() 
    }
    an := big.NewInt(0).SetBits(a.Bits()[alen-3:])
    bn := big.NewInt(0).SetBits(b.Bits()[alen-3:])
    return big.NewInt(0).Div(an, bn).Int64() 
}

isucon7学生枠で予選通過してしまった

はじめに

@nakario_jp と @aokabit との3人で組んだチーム名 百万円ドリブン で スコア48,950、全体順位76位、学生9位で予選を通過してしまいました。

通過できたのはメンバー二人のおかげです。 Golangのプロ @nakario_jp がGoをチューニングし、 @aokabit先生がmysqlとnginxをチューニングしていたなか、 僕はよしなに環境構築とかベンチ周辺やログ取った後は踊っているみたいな分担だったので…。

社会人と学生でかなりの力の強さの違いを実感しました。 しかし我々のようなisuconに触れる前までサーバーサイドチューニングをしたことがなかった 初心者でも学生枠なら通過出来る可能性が本当にあったんだなあということで、 これからisuconをやってみたいと思う学生のために、備忘録的に記事を書こうと思います。

したこと

isucon講習会に参加した

isucon.net とりあえずメンバー全員右も左も分からなかったので講習会に参加することにしました。 完全抽選制で僕だけ受かったので知見を得に行ってきました。 このイベントはisuconのやり方を完全に教えてくれる上に、 交通費・懇親会費まで全て支給してくれる最高のイベントなので是非行きましょう。 sshの仕方が分からない人すらもサポートしていたのでどんな初心者でも迷わず行きましょう。

ついでに東京に行けたので東京で @joisino とキンプラを見ました。

twitter.com ちょうどこの日から応援上映の4DX版が公開されたということで一緒に見たのですが、 応援上映に加え4DXで没入感が半端なく、脳の処理速度を超える体験が出来たので最高でした。 isucon講習会に行った後は是非応援上映も行きましょう。

isucon3,4,5 + pixiv社内isucon を練習した

やはり過去問は大事です。 幸いなことに各種 ansible、各種 ami、各種 VagrantFile が整備されているので簡単に行なえます。

isucon3,4

全員が個別のVagrant環境で練習しました。 本家のmasterブランチのものは上手く動作しなかったので別の人のforkしたものを使用しました。 プロビジョニングにはやばい時間がかかることが分かってよかったです。 初めてということで学ぶことがいっぱいで、ボーダーたけーとか言ってました。

isucon5

AWSを使ってみました(isucon5 は実はGCPだったのですが…)。 適当にコミュニティAMIを探したら、isucon5q-ubuntu16.04 みたいな名前のそれっぽいのがあったので やってみたところisucon5はubuntu15.04だったのが原因で上手く動作しないみたいな事が発覚して騙されてしまいました。

仕方がないのでubuntu15.04のインスタンスを立て、一からプロビジョニングをするということをしていたところ、 10時半練習開始のはずが気づいたら16時みたいなことになっていました…。 やはりプロビジョニングには時間がかかりますね…。

サークルの部室でこれをやっていたところ、別の部員に「こんなに環境構築に時間が掛かるなんてこのチームは雑魚では…」みたいに 思われていたようであちゃーという感じでした。

この回は、ファイル権限とか気にせずに管理出来るようにしようぜと

sudo chmod -R 777 / 

を打ってしまったところで全てが終了してしまったのが印象に残っています。

(具体的に言うと sudoコマンドが777になり、sudoの危機管理機能が働いてsudoを打てなくなり、全てが終わります。)

pixivisucon

isucon6は講習会でやっていたので、pixiv社内isuconを練習としてやりました。 今回は公式amiが提供されており、すぐにAWSで開始することが出来ました。 このisuconはpixivらしく画像の配信がネックになっている問題という設定でした。 そういう意味では今回のisucon7もこれと似た問題設定だったので直近にpixivisuconを出来たのは かなり勝因に寄与していると思います。

この回は、git管理のメンバーの意思疎通が取れておらず、 あるメンバーは3層に分けた管理(最奥のウェブアプリのみremoteあり)を想定していたのに、 あるメンバーは1層管理(remoteあり)を想定しており、 気づいたら3層のうち2層が同じremoteを指しているという状況になっていたのが印象的でした。 (具体的に言うと、.gitのobjectファイルがおかしくなり、力技で解決は出来るのでなんとかなったりはします。)

├─ .git/
│  ├─ .git/  ───┐ 
│  │  ├─ .git/  ───:: 同じ remote 
│  │  ├─ ...

まとめ

  • 過去問をやったことで本番でいい感じに出来た
  • goのプロがいたのでgoのオンメモリチューニングなどが爆速に出来た
  • sudo chmod -R 777 /深層.gitなどを事前に経験したので本番で失敗しなかった

最後にはチームメンバーでサイゼで叫びました

高垣楓さんを追って ~クレイジーサイコバス 十津川くまの特急~

行程

f:id:CHY72:20171001225413p:plain

ことの発端

7月くらいに こういうツイートを見ました。

毎年ママチャリで数百キロくらい回るのが習慣になっており、熊野古道チャレンジしたかったのですが、流石に厳しいので断念していました。 …しかし、夏休みが終わってしまうので急遽どこかに行きたいということで @suzusime と熊野古道(熊野本宮大社,那智)に行く今回の旅が幕を明けたのでした。

9/25

この日の夜に部室にいた @nonamea774 が 十津川くまの特急 という路線バスの情報を提供してくれました。 この路線バスは、一本の路線で167もの停留所に停車し、奈良と和歌山を文字通り160km縦断するという恐ろしいバスです。 熊野古道に行くのにはうってつけであり、これは乗るしかないわけです。

↑十津川くまの特急に関する最高のサイトであり、 Internet Explorer 6 で、動作確認を行っているようです)。

9/27

十津川くまの特急

9時発の十津川くまの特急に乗り、熊野本宮大社へ向かいます。 このバスの最大の特徴は前述の通り167ものバス停に停留することです。 これはもう、全てのバス停でチェックインするしかないですね。

本宮大社

142番目の停留所がいわゆる熊野本宮大社であり、ここが本日の目的地です。 本宮大社については有名すぎるので割愛します。 熊野古道を歩きたかったので 3.4km程山を越えた先にある温泉まで、いわゆる熊野古道「大日越」を歩きます。

この温泉に向かう熊野古道を渡る間の旅のログを残さずにいたところ、 勝手に生霊に取り憑かれ美少女にTSしたということにされていました。 みなさまもTSしたければ熊野古道へ行きましょう。

新宮

147 番目の温泉で優勝したあと、167番目の新宮まで十津川くまの特急で向かいます。 新宮は和歌山にしては都会でビジネスホテルも沢山あり、当日に予約無しで行っても泊まれるので便利です。 1~167番目のバス停まで全て乗って(厳密には142~147は乗っていない)約5kのコストでした。 路線バスにこんなに長い期間乗るというなかなか激しい体験が出来たのでとても満足でした。

9/28

新宮を一通り観光した後、楓さんの原風景の本拠地 那智へ向かいました。

前日の温泉へ向かう獣道のような熊野古道とは打って変わって、 那智熊野古道は観光地らしい石畳が整備された文明を感じさせる熊野古道です。 程よく人間の手の入った自然というものは綺麗だなあという感想を持ちました。

那智大社那智の滝で楓さんの神秘を感じとりJRという文明を使って京都へ帰宅。 実は新宮で学割付きの京都行きの切符を買い JRの途中下車というシステムを使って那智で降りたのですが、 こういう便利メソッドは使っていきたいと思いました。

最後に

ここではあまり書きませんでしたが旅の詳細な景色などは、 物理学巫女チノちゃん @suzusime がツイートしてくれています。 @suzusimeと、熊野古道の旅の情報を教えてくださった皆様に感謝の礼を捧げます。

最後に、高垣楓さんの熊野古道の紹介無しには熊野古道に行きたいという欲求は沸かなかったと思うので、 旅の最初のきっかけとなった高垣楓さんに最上級の感謝を捧げ、結びとします。