きしだのはてな このページをアンテナに追加 RSSフィード

2018-01-08(月) 10年のプログラミングの変化といえばクラウド、型推論、リアクティブ

10年間のプログラミングの変化といえばクラウド型推論、リアクティブ 16:12 10年間のプログラミングの変化といえばクラウド、型推論、リアクティブを含むブックマーク

この10年間のプログラミングの変化、というのが流れてきたのだけど、個人的にはクラウド型推論付き静的型、リアクティブかなぁという風に思ってます。


クラウド(とスマホ)

2008年にGoogle App Engineが出たり、最初のHadoopサミットが行われたり、ちょうど10年前に始まったとも言えるクラウドは、すでに流行ではなく常識になっています。

いまや、クラウドを考えずにシステムを組むということはないんじゃないでしょうか。

スマホもこの10年で広まり、端末にUI、データはクラウドということも当たり前になっています。

40%の視聴率をもった紅白で視聴者が同時投票するようなことも、AWSを使って危なげなく行えるようになっていますが、10年前にこのようなサービスをたった4時間だけ行うということはなかなか考えにくいもので、実現できるのも限られたベンダーだけだったと思います。けれどもいまではそれなりに技術力と予算さえあれば、だれでも高負荷に耐えれるサービスを実現できるようになっています。

それと同時に、10年前まではデータストアはRDBMS一辺倒でしたが、NoSQLという言葉がもはや使われなくなるくらい、RDBMS以外のデータストアも普通に使われるようになりました。

ハードウェアで始まっていたスケールアップからスケールアウトへの流れが、完全にソフトウェアに定着した10年と言える気がします。


型推論付き静的型(と関数型)

2010年くらいにScalaが流行り始め、型推論の便利さ強力さが知られるようになり、動的型言語と同じような手軽さで静的型の安心感をもったプログラムができるようになりました。

Swift、Kotlin、Rustなど、この10年、2008年以降に出てきてきた言語は、ほとんどすべて型推論付きの静的型だと言えます。動的型なのはElixirくらいでしょうか。(Clojureは2007年)

それと同時に、関数型というのも一般的になったように思います。C++Javaでもlambdaが使えるようになりました。C++では同時に型推論も使えるようになっています。Javaもlambdaでは変数が型推論されますが、3月に出るJava 10でようやくローカル変数でも型推論できるようになります。

型推論を実現するコンパイラ技術や言語設計技術の進化と普及が、この10年の変化ではないかなと思います。


リアクティブ

クラウドスマホが広まる中で、ひとつの処理が複数のコンピュータをまたがって行われることも多くなりました。

そこで、別のコンピュータに処理を投げてる間にほかのことをする並列実行の必要性が高まってきました。

プログラム言語も関数型的な機能をもつことが当たり前になっていて、並列実行にも関数的な考え方が持ち込まれることになります。

そこで、アクターモデルやリアクティブストリームなど、並列実行モデルが通常の開発でも使われるようになってきています。

いままでは数値計算など限られたプロダクトで限られた技術者だけが使うものだった並列処理が、リアクティブという名前で身近になったように思います。

特に、処理の高速化からリソースの効率利用に並列処理の視点が変わってきたのが、この10年の変化だと思います。


RxJavaリアクティブプログラミング (CodeZine BOOKS)

RxJavaリアクティブプログラミング (CodeZine BOOKS)

2018-01-07(日) 正月からMSXのZ80アセンブラを書いていた

正月からMSXZ80アセンブラを書いていた 11:34 正月からMSXのZ80アセンブラを書いていたを含むブックマーク

あけましておめでとうございます。

どこぞに、正月3日に起こった出来事が1年を決めるという話が流れてましたが、そうすると今年は1年、夜中にZ80アセンブラを書いて昼間寝る感じになるんでしょうか・・・

書いてたのは、こんな感じで誤差拡散でカラーテーブルを表示するプログラムです。

f:id:nowokay:20180103020729p:image


まずは素直なカラーテーブル

最初、年末に何を思ったかこんな感じのカラーテーブル表示プログラムを作りました。MSX2は赤緑8階調、青4階調の256色を同時表示できていたので、それを表示するとこうなるのです。

100 DEFINT A-Z
110 SCREEN 8
120 FOR I=0 TO 15
130 R=(I MOD 8)*32
140 B1=INT(I/8)
150 FOR J=0 TO 15
160 LINE (I*16,J*13)-(I*16+15,J*13+12),R+B1+(J MOD 8)*4+INT(J/8)*2,BF
170 NEXT J
180 NEXT I
190 A$=INPUT$(1)

f:id:nowokay:20180103020741p:image


実際の動きをWebMSXで確認できます。

カラーテーブル on WebMSX


BASIC版誤差拡散

で、そうするといまいまいまさのぶという人からこういうツッコミが。


誤差拡散では、こんな感じで誤差を散らします。

描画点7/16
3/165/161/16

じゃあ作ってみるかと思って作り始めたものの、これがつらい。

何がつらいって、まず編集がつらい。行番号を入力して該当行を編集するという謎方式でのコード入力になるのだけど、行の挿入や削除がかなり面倒です。確認もLISTコマンドでいちいち表示させる必要があります。MSXからプログラムを始めたので当時はこれが当たり前だと思っていたのだけど、今やると本当に不可解で、よくこの入力方法が理解できたなという感じです。

あと、画面が小さすぎてつらい。MSX1のときで40x24文字、MSX2で80x24文字しか表示できないのです。しかもリストはスクロールもできなくて、該当行番号を指定してLISTコマンドで表示です。

さらに言語がつらい。変数名は2文字まで。まあ今回はそんなに複雑なプログラムじゃなかったのでいいものの、IF文も一行完結の必要があったり、関数定義できなかったり。


そして最後に実行速度がつらい。ひととおりコードを入力して動かしてみたら、全然描画が進まない。1ラインの描画に40秒くらいかかります。ただしく描画できてるかどうか確認するのに、派手に間違えているときならすぐわかるにしても30秒くらい、細かく間違えていたら10分くらい動かしてようやくわかるレベルです。もちろん試行錯誤も進みません。

ということで結局Javaで等価なコードを書いて動きを検証してからBASICのほうを修正しました。

Javaのコードはこれ。

https://github.com/kishida/msxdiffusion/blob/master/src/main/java/kis/diffusion/Diffusion.java


動かして、2時間かかることは予測できていたので、実行しながら風呂に入って出てみると全然進んでない。Firefoxは別タブで隠れたら実行が止まるらしい。。。

気を取り直して実行開始して寝る。起きたら「Illegal Function Call」のエラー。。。

修正して、時間計測コードも仕込んで、実行して寝ると、今度こそちゃんと表示されてました。

f:id:nowokay:20180103020736p:image


コードはこんな感じに。

https://github.com/kishida/msxdiffusion/blob/master/msx/COLORS2.BAS

WebMSXで実行すると、遅さが体感できます。

誤差拡散BASIC版 on WebMSX


マシン語版誤差拡散

BASIC版のあまりの遅さに、ちょっとこれはマシン語でやってみるとどうなんだろうという疑問が頭をもたげて離れないので、やってみることに。とはいえ、MSX上でコードを書いてアセンブルしてというのは今更さすがに無理なので、Windows上で動くZ80アセンブラを探しました。

http://www.48k.ca/zmac.html


しかし、Z80というのは計算に使えるのがAレジスタしかないし、掛け算も割り算もないし、結構つらい。あと、点を描画するのに、IOをいじってVRAMを書き込む必要があって、VRAMの書き込み方やVRAMの構造を調べる必要もあります。

なんとか全体が動くコードを書いて動かすと、やっぱ変な感じに。

f:id:nowokay:20180107112721j:image

VRAMアドレスを計算するために64で割るときに、右に7回シフトしていたのが敗因。


で、いろいろがんばってたら、こんな感じに。だいぶ近づいた。

f:id:nowokay:20180107112717j:image


最終的にちゃんと表示されました。

f:id:nowokay:20180103020729p:image


2時間26分かかっていたのが50秒に。175倍の高速化です。しかし2日の実装期間。。。

あとは、割り算を引き放し法で高速化して45秒に、裏レジスタを使ってメモリアクセスを減らして43秒に、と最適化して、最終的にこうなりました。

https://github.com/kishida/msxdiffusion/blob/master/msx/loop.mac

ちょっとした工夫で速くなるのは楽しいです。Javaのコードだと、ちょっとした工夫はすでに最適化で行われているので、なかなか細かいところをいじるメリットはないですけど、Z80は書いたコードを正直に実行するので、ちょっとした工夫でもちゃんと処理時間に反映されて、これはこれで楽しいです。

1/9:追記 その後、数値範囲のビット数にあわせて割り算を最適化すると35秒を切りました

1/13:追記 さらに無駄な処理を省くことで30秒を切りました。

1/14:追記 さらに最適化して29秒を切りました。


ここで動かせます。

誤差拡散マシン語版 on WebMSX


1/9:追記

最初のアセンブラバージョンと比べると、かなり速くなっているのがわかります。

誤差拡散マシン語版初期 on WebMSX


ということで、たまにZ80アセンブラを書いてみると楽しい、という話でした。

ただ、昔と違って、資料をWebで調べながらコードが書けるし、エディタは文字をたくさん表示できるし、アセンブルも速いし、断然にコード書きやすくなっていますね。おそらく、MSX上でコードを書いていると、もっと動かすのに時間がかかっていたと思います。


このときのツイートはこっちのモーメントにもまとめています。

https://twitter.com/i/moments/948840407013638145


トラックバック - http://d.hatena.ne.jp/nowokay/20180107

2017-11-08(水) Thymeleaf3は2より3倍速く、JDK9では3割遅くなる

[]Thymeleaf3は2より3倍速く、JDK9では3割遅くなる 04:53 Thymeleaf3は2より3倍速く、JDK9では3割遅くなるを含むブックマーク

Thymeleaf3がどのくらい2より速くなってるか、あとJDK9のcompact stringは有利に働くかどうか、ベンチマークを取ってみました。

結果として、Thymeleaf3は2より3倍速く、JDK9では遅くなっていて、compact stringは関係なさそうという感じ。

あと、Pebble速い。(というかThymeleaf遅い)


まとめると、こう。単位はops/sで、大きいほど良い。

Thymeleaf cache on no cache
3.0.2 on JDK1.8 16378.948 376.295
3.0.2 on JDK9 11239.364 404.544
2.1.5 on JDK1.8 4621.328 1690.995
2.1.5 on JDK9 4185.943 1505.521
Pebble on JDK1.886571.846
Pebble on JDK9 79746.853

キャッシュなしだとThymeleaf2のほうが速いというのも面白い。

ついでにPebbleも試したけど、いずれにせよThymeleaf遅いな。


JDK1.8の設定はこんな感じ

# VM version: JDK 1.8.0_112, VM 25.112-b15
# VM options: <none>

JDK9の設定はこんな感じ

# VM version: JDK 9.0.1, VM 9.0.1+11
# VM options: <none>

compact stringをはずしてみたらこんな感じ

Thymeleaf cache on no cache
3.0.2 on JDK9 cs 11239.364 404.544
3.0.2 on JDK9 no-cs11502.128 383.660
2.1.5 on JDK9 cs 4185.943 1505.521
2.1.5 on JDK9 no-cs4175.685 1541.948
Pebble on JDK9 cs 79746.853
pebble on JDK9 no-cs87707.230

Thymeleafは差はなさそう。Pebbleはcompact string外した方が速くなってる。


no-csがcompact stringなしで、VMオプションはこんな感じ。

# VM version: JDK 9.0.1, VM 9.0.1+11
# VM options: -XX:-CompactStrings

ついでに、パラメータが英語だけの場合も試してみたけど、compact stringの効果はなさそう。en付のデータ。

Thymeleaf cache on
3.0.2 on JDK9 cs en12934.452
3.0.2 on JDK9 no-cs en12877.672
2.1.5 on JDK9 cs en4286.138
2.1.5 on JDK9 no-cs en4287.446
Pebble on JDK9 cs en83942.007
Pebble on JDK9 no-cs en92066.631

あと、テンプレートキャッシュが効かないと劇的に重いので、サーバーレスでやろうとするならテンプレートもプレコンパイルの仕組みが必要そう。


ソースはこちら

https://github.com/kishida/thymeleaf-bench

2017-11-06(月) 電子工作たのしー!ブラウザで回路シミュレーション。Arduinoも簡単

電子工作たのしー!ブラウザ上で回路シミュレーション。Arduinoも簡単 22:59 電子工作たのしー!ブラウザ上で回路シミュレーション。Arduinoも簡単を含むブックマーク

ブレッドボードを使った練習回路をちょっといじろうと思って、たぶんいいツールがあるはずだと探してたら、ブラウザで回路シミュレーションできるTinkercad circuitというのをみつけました。

https://www.tinkercad.com/circuits

f:id:nowokay:20171106132505p:image:w400


もともとはサンハヤトのキットでタイマーICを使ったブザーを作って、これをArduinoに対応させたかったのだけど、電子回路は不慣れなので、なにかシミュレーションできるツールを探していたのでした。


まずはそのままWeb上で動かしてみる。


それから、LEDを追加します。いろいろ試行錯誤して、結局トランジスタを使わないとダメだったので、これは実配線でやってたら絶対にできなかったなという感じ。

実際の回路はこれです。

https://www.tinkercad.com/things/3fwKikMQvyt


実装するとき、横着してトランジスタをそのままGNDに落としていて音がならなかったのだけど、修正してちゃんと音がなるようになりました。これも、最初から配線してたらわからなかっただろうな。


Arduinoもすごく簡単。スクリプトも、左側のブロックを組み立てるだけで自動的に記述されます。

回路はこちら。

https://www.tinkercad.com/things/6AJg7BYWND4


ただ、実際には、LEDとブザーを同時につなぐと音が出ませんでした。LEDの抵抗が大きいのかな


Autodesk circuitsがTinkercadに移行したものなので、この本とかが参考になると思います。

2017-11-04(土) OpenJDK/amberをビルドしてパターンマッチングの世界を体験する

[][]OpenJDK/amberをビルドしてパターンマッチングの世界を体験する 08:55 OpenJDK/amberをビルドしてパターンマッチングの世界を体験するを含むブックマーク

ほんとはjdk10をビルドしてvarの世界を体験するエントリだったのだけど、ここでバイナリが提供されたので、Amberの話にします。

Project Amberは、Javaにパターンマッチングを導入するプロジェクトです。

varによるローカル変数型推論もAmberの一部だったのだけど、これはjdk10に取り込まれました。jdk10はリポジトリ名で、実際のリリースがJDK10になるかどうかは不明です。


Amberのパターンマッチングがどうなるかというのは、以前ブログにまとめています。

http://d.hatena.ne.jp/nowokay/20170103#1483451037

で、これを試してみるために、ソースをビルドして動かしてみます。今回は、LinuxMacUbuntu on Windowsで試します。


Linux(Ubuntu)でのビルド

ソースをとってきて、ブランチを切り替えて、configureしてmakeというのがビルドの流れです。

ちなみに、OSと必要なライブラリなどあわせて15GBくらいディスクを使うので仮想環境では20GBくらいディスクをとっておく必要があります。ソースとビルド生成物はあわせて6GBくらい。


ビルドにはJDK 9が必要です。

~$ mkdir java
~$ cd java
java$ wget http://download.java.net/java/GA/jdk9/9.0.1/binaries/openjdk-9.0.1_linux-x64_bin.tar.gz
java$ tar zxf openjdk-9.0.1_linux-x64_bin.tar.gz

Mercurialをインストールします。

java$ apt update
java$ apt install mercurial

ソースをとってきて、patternsブランチに切り替えます。cloneは結構時間がかかるので、お風呂とか入るといいと思います。

java$ hg clone http://hg.openjdk.java.net/amber/amber
java$ cd amber
amber$ hg update patterns

今までのビルド手順だとget_source.shを動かしてソースをとってきていましたが、リポジトリ一本化によってcloneだけでよくなったみたいです。amber/amber10-oldなどだと古いパッケージ構成なので、get_source.shが必要のはず。


必要なパッケージをインストールします。

amber$ apt install libx11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev
amber$ apt install lib-cups2-dev  lib-freetype6-dev lib-asound2-dev

では、ビルドを。ビルドにはかなり時間がかかるので、ごはんの支度とかするといいと思います。

amber$ bash configure --with-boot-jdk=~/java/jdk-9.0.1
amber$ make images

configureのときに足りないパッケージはエラーメッセージで教えてくれるので、うまくconfigureできないときは確認してインストールしてください。


さて、ごはんもできたと思うので、おいしくいただきましょう。ついでにJShellも起動してみます。

f:id:nowokay:20171104075418p:image

というか、matches???聞いてないよーーー

matches、キーワードがどうなるかはともかく、かなりキモい仕様になっています。ということで、あとでこのあたりまとめてみます。

ここで試してないけど、ステートメントとしてのswitchもパターンマッチができています。いまのところ、ソースをみる感じswitch式については実装されてない感じです。

※ matchesが使えないときは、patternsブランチに切り替え忘れてないか確認してください。


Macでのビルド

Macでのビルドには、freetypeをインストールしてFreeType関係のオプションを指定する必要があります。

brew install freetype

configureはこんな感じ

bash configure --with-freetype-include=/usr/X11/include/freetype2 --with-freetype-lib=/usr/X11/lib --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk-9.0.1.jdk/Contents/Home

※ 11/14 追記 XCodeをインストールしておく必要があるっぽい。XCode8が入ってたので大丈夫だったみたい。あと--disable-warnings-as-errorsをつけたほうがいいのかな。

macOSでOpenJDK(amber)ビルドするとエラーになってたのをクリアしてビルドした - Fight the Future


Ubuntu on Windows

Windows用のビルドがやりたかったのだけど、どうもVisual Studio Express 2010が必要ぽくて、インストールできなかったのであきらめた。

Ubuntuとほぼ同じだけど、makeとかが入ってないのでインストールが必要です。

~$ apt install build-essential

あとはUbuntuと同じ手順でいけるはず


プログラミングの基礎 ((Computer Science Library))

プログラミングの基礎 ((Computer Science Library))

トラックバック - http://d.hatena.ne.jp/nowokay/20171104