トップ «前の日記(2016-01-11) 最新 次の日記(2016-01-15)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|

ToDo:


2016-01-13

_ リセットボタン

http://mubou.seesaa.net/article/432460939.html

まあ UI が進化したのと起動が遅くなったのとで、ゲームの再起動はゲーム内でやるようになったというのがあり。

てか PS1 PS2 てハードウェアリセットボタンついてた??とか思って、画像検索したらついてた。すごい押した記憶ない

PS1 の絵描けて言われればこういうの描く。で、これリセットボタン忘れてるんだけど、全く違和感無いしリセットボタン描いたら逆に違和感ある気がする。使わないものって記憶に残らないんだなあ

ryoku160113115835.gif

(12:23)

_ 速度

https://twitter.com/kmizu/status/687232554001235969

ポジショントークです

色んな速度があるからなあという話。大雑把に言って

  • 1. スループットが重要なもの
  • 2. レイテンシが重要なもの
  • 3. 書いてる時の速度が重要なもの(ちょっとした問題の修正も含む、いわゆるイテレーション速度)
  • 4. 問題を解決する速度が重要なもの(運用してる間に起きた問題の修正、しょうもない typo とかは含まない…とする)

なんてのがあると思う。 3 と 4 は規模によって結構変わる数字。えんどうさんは Ruby は 3 (や 4)が重要な言語だという観点で、 1, 2 のためにそっちを犠牲にしないで欲しい、的なスタンスなんだと思う。僕も賛成する…が rails の人たちなんかは少し違うバランス感覚を持つだろう

1 が効いてくるなら C/C++ と JVM 以外に解が無いことが多いと思う。それとスクリプト言語で書いてもたいして楽にならないケースが多いように思う。というわけで、 1 は Ruby でやろうとしないのが懸命だと思うけど、まあ言語のベンチマークはおおむねこれを測ってるケースが多い…と思う。とはいえ実行頻度が少なければ、 C/C++ なら1時間ですむけど、 Ruby なら5時間…みたいなタスクでプロジェクトによって Ruby を採用するのもわからんでもない…が個人的には基本イヤだ。

2 はこう、 1 よりは制限が弱くて、 UX 的に問題になるまではどの言語でもいいところではある。 Python Ruby で書いてる大規模なフロントエンドなんて、まあいくらでもあるだろう…とは思う。がなあ、 1, 2 が気になりうるならそもそも Ruby 使うな感はある(このへんポジショントーク)。レイテンシは問題が起きるたびに修正しなきゃなんで、最初から速いので書いときゃ問題が起きる頻度が減るんで。

3 はおおむねスクリプト言語が速い…が今は知らんが昔の rakudo で見てる限り Perl6 の 3 は速くない。 4 は printf で解決するような問題だと 3 の速さが重要になるけど、ややこしいデバッグとかするなら JVM とかが良くなる…と思う。個人的な感覚では JVM は速度に関する問題が起きた時、 4 の解決は C/C++ がツールの充実と GC の不在により、最速になりうる…と思う(このへんもポジショントーク)。

4 はこう、割と 1,2 の速度と 3 の速度が混じる領分で、複雑になればなるほど 1,2 の速度が問題の解決にかかる速度に依存しがちで、簡単なものだと 3 の速度てかイテレーション速度に依存しがち…な気がする。ただそれ以上にツールの充実とかが重要になってきて、言語機能そのものとかより、エコシステムが影響してくる分野だと思う。

1 考える時は C/C++ で良くて、 2 は C/C++ かひょっとしたら JVM とか GC つきの言語もアリで、 3 はスクリプト言語、みたいな使いわけになってる気がする。 4 は色々あるけど、結局エコシステム的に、慣れたせいもあるけど、 C/C++ (+gdb +valgrind +etc.) が素晴らしいんだよな。

でー…僕は 1 と 4 最重視でサクッと書く時は 3 重視、みたいな感覚で、それでなんか C/C++ か Ruby (か会社で書く時はいやだなあと思いつつ Python) しか使わなくなってしまっている。のでえんどうさんの言う https://twitter.com/mametter/status/687227476548833280 は強く賛同するんだけど

2 ぽいことする時は隙があれば Go とか JVM 系言語使ってもいいと思うんだけど、最近そういうのやってないんだよな。あと Go はともかく JVM 系はイテレーション時間かかりがちだよな色々(古い記憶に基くポジション)

で Rails の人てのは 2 なんだろうな

なんていうかスクリプト言語の人とか最新言語好きな人は 3 によりすぎてると思うんだよな基本的に。まあイテレーション速度は重要ですがね。 C/C++ でもコンパイル結果わかるまでは 1 秒あれば普通のプロジェクトなら可能だしな(Chromiumは普通Androidは異常という世界観)。書く速度の方はなあ。1ヶ月くらい1万行越えるコードベースいじってると、アセンブリとかでなければ生産性たいして変わんなくなる気がしてるんだよな。脳の速度が律速する

(22:13)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2016年
1月
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h