読者です 読者をやめる 読者になる 読者になる

uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかFregeとかJavaとか -

GCR

Grails Groovy

GCR 13thお疲れ様でした。大変盛況でしたね。会場を提供頂きましたIBMさま、発表された須江さま、ありがとうございました。お疲れ様でした。
須江さんの発表で、Groovyユーザの裾野がまた一つひろがったのではないでしょうか。Javaプログラマをひきつけるのに良い内容だったと思います。完成版資料期待(^^)。

以下、GCR飲み会の話で聞いたことや考えたこと。


Grails商用適用における運用面について

運用性や高負荷時の性能評価に関して比較すべきはRails vs Grailsではない。まずは、Rails vs Java環境という話になる(Rails/Grails自体のオーバーヘッドの話は、ちょっと置いといて)。

そのとき、高負荷時・メモリ不足時の挙動としてはJava系の方が予測および設計しやすい。負荷予測およびそれに伴う適切な設計・設定・配備は、ある種の特殊技能ではあるが。PHP・LAMPに代表される「Webフロントが薄い構成」では、とりあえずサービス開始して、重くなったときに適宜のスケールアウトによる腰の軽い対応が可能であるが、予算が限られ、予測が必要なエンタープライズ系、SI開発では許容できないケースがあるはず。

Grailsに限って言うと、運用で普通なのはTomcatによるクラスタリングで、Hibernate側でのキャッシュ共有とかも可能なはずだが未知。

●エンタープライズRubyの適用限界

仕様化されていないRubyは、企業における従来開発の延長線上では、基幹システム開発などでは適用しづらい。仕様化のメリットは、複数ベンダによる(1)性能向上・安定化の「人月集約型」の作業が集積しにくい(2)企業倒産などにおける開発迷走に対する保険であるがゆえに。とはいってもGroovyが言語レベルでJSRなどで「十分に」仕様化されているとは言えないし、他の面でもGroovyが企業システム開発に適用しやすい、といえるほどには行ってないというのも現実だけれども、VMレベルの話としては言える。

・・・というような見解を形成することは可能である。

●言語移行は「タイミング」に左右される

言語技術トレンドは、連続的・平均的ではなく、十年周期ぐらいの「波」として現れる。波と波の間の移行は、次の波から飛び乗れる良いタイミングでやってこないと、移行が促進されない。「前の波が不十分」とアーリーアダプタによって認識されたタイミングで来る「波」が移行に関しては理想的。Rubyはそれにのったため、多数の優秀な開発人材を獲得できた。ひるがえってGroovyは条件が悪い。開始自体はそれほど悪くないタイミングで始まったのに、開発が一時少し停滞し、JSR化で発生してしまった「過剰期待バブル」がはじけたことにより、一部アーリーアダプタにとっては、ネガティブイメージが刷り込まれた(負のブランド化)。実質が伴ってきた今でも、波には乗れない。マイナスからの出発

Grails/Groovyに望むこと

個人的にわたしが望んでるのは、不幸な過去によって過小評価されているGroovyおよびその関連技術を本来の適正状態に戻したいということです。

●Groovy実行速度について

Groovyの速度のネックは、動的メソッドディスパッチのオーバーヘッド(動的なメソッド探索を伴う)であり、プリミティブ型を使用しないことによるメソッド呼び出しの頻発が、乗算的にそれを顕在化させること。

ここらへんはGroovy 1.6betaにおけるメソッドキャッシュによって劇的に改善されてはいるものの、動的メソッド呼び出しの基盤にあるリフレクション呼び出しはJITによっては高速化しないので、Groovyコードの速度は一般に、C言語・マシン語レベルになることはありえない(Javaならありうるのに)。

今後さらなるGroovy(or JVM動的言語)の画期的な速度的ブレークスルーは、Groovyc(GroovyClassLoader)によるコンパイルとJITによるコンパイルが連動連携したときに達成されるのかも。たとえば、動的かどうかを呼び出し履歴的に判別してバイトコードを書き換え再JITかけるような最適化とかね。動的言語を表現するバイトコードには、JITに対するヒント情報がもっと必要だ。Ngといった取り組みには注目である。


また宜しくお願いします。

広告を非表示にする