情報更新

last update 08/22 06:13

ツイート検索

 

@kmizu
サイトメニュー
Twilogユーザー検索

Twilog

 

@kmizu

Kota Mizushima (on a diet)@kmizu

Stats Twitter歴
4,518日(2007/04/10より)
ツイート数
93,806(20.7件/日)

ツイートの並び順 :

表示するツイート :

2019年08月22日(木)3 tweetssource

11時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

@kis 私は、犠牲者の公表を警察がする権利はないと思ってる立場なんですが、そのことを念頭においても、その「検証」てのはやるべきものなのでしょうか?

posted at 02:10:43

2019年08月21日(水)63 tweetssource

20時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

なんか、Javaプロジェクト作るのに、mavenやgradle使わずに(hobbyなら)sbtでいいやって気もしてきた。いやまあ、そいつらの便利なプラグイン使えなくなるデメリットはあるものの、代わりに慣れたsbt plugin使えるし。

posted at 17:21:26

21時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

LL(1)の解説資料作っていて改めて思ったんだけど、説明の順序として字句解析を先にやるのはよくないよなーと。LL(1)だと字句解析なしでうまくないから仕方なく字句解析を導入するというのが本筋の筈。

posted at 16:31:36

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

もちろん、そういう極限チューニングを普通にすべきではないのは言うまでもないです。ただ、生成コードをチューニングするとか、そういう場面ではごく稀に有用なこともあります。

posted at 15:24:46

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

あと、もっと細かいところでいうと、ポインタアクセスを減らすようにリンクトリストより配列(配列でもObject[]おりint[]とか)みたいな話も。

posted at 15:14:54

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

他の、計算量に関する最適化はもちろんなんだけど、極限までチューニングしようとすると、メモリアロケーションを以下に減らすかの戦いになるというのが自分の実感。昔、自前でメモリ管理する最適化よりGCに任せた方がスループット上がるとか聞いたことあるけど、そうとも限らない。

posted at 15:13:14

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

JVM上で動くアプリケーション、というかパーザジェネレータが吐くコードの最適化は色々やったことあるんだけど、interface -> abstract classへの修正で1.5倍速くなったり、リングバッファにするとかプリミティブ専用コレクションの導入などのアロケーションを減らす工夫で速くなったりなどある。

posted at 15:11:30

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

@kis エスケープアナリシスに(JITコンパイラが)かけられる時間がどれくらいか不明ですけど、うまいこと狙ったオブジェクトをスタックアロケーションしてもらうの割と難しい気がします。

posted at 15:08:34

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

ただ、scalacの場合についていうと、スタックアロケーション可能なオブジェクトさえあれば(いや、JVMだから(Valhallaができてない)今は無理だけど)、ここまでせずとも、という思いがある。

posted at 15:04:42

22時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

コンパイラって、アプリケーションの中でもとりわけパフォーマンス(コンパイル速度)が必要とされるので、ダーティな最適化が必要なことは割と必然的で、そのためには結局手続き型プログラミングだったりオーバーヘッドが低いnull(Optionに比べて)が出てくるの仕方ない感ある。

posted at 15:03:34

23時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

@xuwei_k 専用のタプルクラス作って、プールに入れて使い回すとか思い浮かびましたが、別のバグ呼び込みそうで怖い。確かに、もうちょっとましな手段があって欲しいし、ましな手段がありえないとも思えないんですが。

posted at 14:53:43

23時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

markdownで木を簡単にレンダリングできたら自分にとって便利なのだけど、うまい方法ないだろうか。graphvizとかだと、毎度別途コンパイル走るし、markdownに埋め込めないので多少めんどい。

posted at 14:36:35

23時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

ただ、モチベーションの話ではなくて、仕様の話としては直接的にはraw typeという概念が存在するからともいえるので、「それ以外の理由」でも(raw typeのことを連想したのなら)間違ってないです。

posted at 14:10:45

23時間前

@kmizu

Kota Mizushima (on a diet)@kmizu

これ、解説してみます。ListやArrayListをそのまま書いた場合はraw typeとみなされて、特別扱いされるから、です。で、なんでそうしたいかというと docs.oracle.com/javase/specs/j "To facilitate interfacing with non-generic legacy code" という話なので、ソースの後方互換性のため、が一番近いです。 twitter.com/kmizu/status/1

posted at 14:09:20

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

@xuwei_k 一般論としてですが、JVM上のアプリケーションをカリカリにチューニングする場合において、とにかくアロケーションを減らすのはかなり重要ですが、ほとんど呼ばれないもののアロケーション減らしても意味ないので、makeAccessibleが多数呼ばれるということかなと思いました。

posted at 12:04:22

8月21日

@taroleo

Taro L. Saito@taroleo

2000年以前のDBMSの話は僕は文献レベルでしか知らないし、RDBMSの黎明期の1980年前後になると図書館で古い論文誌を引っ張り出さないと論文すら読めないので、データ指向アプリケーションデザインのように歴史をまとめてくれるのはありがたい

Retweeted by Kota Mizushima (on a diet)

retweeted at 11:53:40

8月21日

@taroleo

Taro L. Saito@taroleo

データ指向アプリケーションデザインにあるCODASYLなど昔に開発された階層型データモデルの話は、red bookでも触れられているけれど、多様な形態のデータベースがRDBMSに吸収されていった歴史を知るのに良い。リアタイで知っている人は少なくなってきているので

Retweeted by Kota Mizushima (on a diet)

retweeted at 11:53:25

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

@white_azalea Javaが後方互換性を保つために、raw typeをユーザーが定義できるという部分を残したままという「イレイジャとは別の話」と、「イレイジャ」という方式の混同がありそう、というか。たとえば、Scalaはジェネリクスの実装にイレイジャを採用していますが、おっしゃるような問題点が起こり得ません。

posted at 11:48:14

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

@white_azalea 基本的には、私の認識はその通りです。そのうえで、イレイジャ方式そのものは、特にレベルの低いプログラマが、という文脈では影響がないと感じています。「内部的にも型の強制が」というところから、やはり「raw typeをユーザーが書ける」という現在のJavaの仕様とイレイジャの混同があるのではと。

posted at 11:46:35

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

これは、記事とかコメントでも、"statically parse" という表現が用いられているから、そのことには該当記事では皆(?)意識的なのだと思うけど、Perl 5の構文解析が決定不能らしいぜ、という話を広めるときにはこのことは意識した方がいいと思う。

posted at 11:13:10

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

これが表す性質ってのは、Perl 5の構文解析ってのが評価と切り離して考えられないという話なのであって、それをParsing is Undecidableというのは間違っていないものの、「いわゆる構文解析」が決定不能という話になると思う(この「いわゆる」は実行前にされるのが本来の構文解析だという意味)。

posted at 11:10:27

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

Parsing Perl 5 is Undecidableの証明 perlmonks.org/?node_id=663393 を理解した(と思う)。確かに、ある文字列に対して唯一の構文木を決定する問題をparsingだとすると、これは決定不能だと言えそう。一方でParsing Perl 5 is Undecidableってのが独り歩きすると、これは違うイメージを与えそうで、微妙。

posted at 11:08:06

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

@enkinho その辺は開発リソースの問題や、あんまり需要がなかったことが大きいと思いますが、.NET版を維持してても、ScalaとしてはHKTとかも含めてイレイジャとして実装するしかなかったはずですし、.NETの恩恵を受けにくいのは確かだと思います。

posted at 05:52:02

8月21日

@kmizu

Kota Mizushima (on a diet)@kmizu

VMの型システムと言語の型システムを一致させなければいけない.NETのような制約つけてしまうと、それ以上高機能な型システムを実現する制限になってしまいますし(たとえば、Scalaの型システムは.NET上にそのままマッピングできない)。

posted at 05:29:48

このページの先頭へ