パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

グリッドを使った100万人用のゲームサーバ」記事へのコメント

  • よーし (スコア:2, おもしろおかしい)

    動的にってことなら、LISPで書きますか!
    オブジェクトも動的だから、稼働しながらメンテできちゃいますよ。
    まさにゲーム向け?
    • by Anonymous Coward
      そこまでいかんでも…(笑

      Java とかでも十分動的再構成出来ますがな。C でもプロセスをうまく分けとけばいけそう。
      • まま、そうおっしゃらず、 普通のやつらの上を行きましょう(^^; [dreamhost.com]

        志を低く持てば、Javaでも出来るぞCでも出来るぞという議論も可能ですが、
        どうせならもっと気前よく行きましょう。他にも色々メリット有るんだから。

        ただまあ、Lispそのものが最高の解なのかどうかは俺は何と
        • Java は動的度が低い、とも取れる発言をされては黙ってはおられん!(笑

          LISP、はよく分からんですが、例えば ruby や Smalltalk、これらは確かに高い動的度を持っておるでしょう。しかし、それは他のものを犠牲にして得られたものではあるまいか?

          例えば ruby の thread は、(native 化しようという動きはあれど) 基本的にユーザランドスレッドであり、お手軽な反面、より高機能なハードウェア (マルチプロセッサな環境など) をうまく利用することが出来ないでしょう。Smalltalk や LISP の現存する処理系も、多かれ少なかれそういう面を抱えているのではないですか
          --
          Only Jav^Hpanese available :-)
          • いや、LISPはデータとプログラムが等価なんですよ。
            データの再編成を行うように自分自身のロジックをロジックで再編成できると。
            …でよかったよね?>LISPのえらいひと

            Javaは…早くテンプレート実装してください~
            あ、あとVMのvesionがほんの少しでも変わると
            --
            kusanagi shin
            • > LISPはデータとプログラムが等価なんですよ。

              今のノイマン型コンピュータではどんな言語を使おうがプログラムとデータは等価なのではあるまいか?…なんて原則論をゆってもしょうがないっすね。確かに LISP のその特徴はシンプル、かつ非常に強力な点でありますな。設定ファイルを LISP で書ける環境だと、値を設定すべきところに式が書けたりしてめちゃめちゃ便利ですよねぇ。

              > Javaは…早くテンプレート実装してください~

              なんでも次のバージョンでは実装される予定だそうで。僕自身は全然必要性を感じていないんですけど、Java でも便利ですかね?異なるクラスに対して同一の操作を行うような method を作りたければ、共通の親クラスを用いて多態させればいいように思うんですが、Java にはプリミティブ型、という鬼っ子もいるわけで、もっぱらこちらのために使うことになるのかしら?しかし複数のプリミティブ型に対して同一の処理を行う method を書きたい、という局面は非常に限定的な気もしますが…。

              > あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
              > 変わっちゃうのも大変かもしれない。

              むぅ。僕自身かなり VM をいじめてきたつもりだったんですが、この「ほんの少しでも変わるとがらり」に相当するような挙動は見たことがないです。今後の参考のためにどんな変化だったのか教えていただけたりしませんか?ダメ?

              > C++使いには「自分で解放するから手を出すなっ」と叫びたくなることもたま~にあるが(笑

              参照が残ってる限り GC は手を出さないと思うんですが…って、そんな基本的なことじゃない?あこりゃ失礼しました~。
              --
              Only Jav^Hpanese available :-)
              親コメント
              • Re:よーし (スコア:2, 参考になる)

                by nminoru (5013) <{nminoru} {at} {nminoru.jp}> on 2003年03月03日 11時42分 (#271463) ホームページ
                >> Javaは…早くテンプレート実装してください~
                > なんでも次のバージョンでは実装される予定だそうで。僕自身は全然必要性を感じていないん
                > ですけど、Java でも便利ですかね?異なるクラスに対して同一の操作を行うような method を作
                > りたければ、共通の親クラスを用いて多態させればいいように思うんですが、Java にはプリミティ
                > ブ型、という鬼っ子もいるわけで、もっぱらこちらのために使うことになるのかしら?しかし複数
                > のプリミティブ型に対して同一の処理を行う method を書きたい、という局面は非常に限定的な
                > 気もしますが…。

                正確にはJ2SE 1.5 から入ります。
                JCP(Java の標準団体) の JSR (Javaの仕様案) では JSR 14 Generic Types [jcp.org] です。
                提唱者による実装はすでに公開 [unisa.edu.au]されています。

                Generic Type は主として、コレクションクラスの高速化と安全性のために導入されます。
                現行のコレクションクラスが Object を基底としているため、コレクションから取り出してきた値を使用する前に narrow cast を行う必要があります。これが不要になるぶん高速化されます。
                また、Object 型を基底とするコレクションクラスにはどんなオブジェクトで入れることができるという問題がありましたが、ユーザーが指定したクラス(例えば MyClass) にパラメタライズされたコレクションには、MyClass とその導出型以外のものが入りません。その分、安心して使えますし、余分なチェックが不要になります。

                あと、入れ物のクラス毎にコレクションクラスが複製されるので、JIT コンパイルが効きやすくなったり、Digitune さんが挙げているようにprimitive 型のコレクションに対するナイーブな実装ができる点が有利なポイントですね。

                > > あ、あとVMのvesionがほんの少しでも変わるとがらりとガベージコレクタの挙動が
                > > 変わっちゃうのも大変かもしれない。
                >
                > むぅ。僕自身かなり VM をいじめてきたつもりだったんですが、この「ほんの少しでも変わると
                > がらり」に相当するような挙動は見たことがないです。今後の参考のためにどんな変化だったの
                > か教えていただけたりしませんか?ダメ?

                第3者ですが。
                SUN J2SE の HotSpot VM の 1.4.0 で 1.4.1 の間でボコボコに挙動が変わっている例を一つ。
                できるだけ way 数の大きい SMP マシンで、-XX:+AggressiveHeap を付けた時の挙動を確かめてみてください。天地の差があると思います。

                細かい違いはまだまだ色々あって、困っているのですが。。。
                # 変えるなら、変えると、ちゃんと言って欲しいよ > SUN
                --
                コンタミは発見の母
                親コメント
              • by G7 (3009) on 2003年03月09日 2時43分 (#275352)
                >異なるクラスに対して同一の操作を行うような method を作りたければ、共通の親クラスを用いて多態させればいいように思うんですが

                「同一の」じゃないから厄介なんですよね。「同様の」なんです。templateなるものが欲しくなる場面ってのは。

                コンテナ型がよく引き合いに出されますね。Hoge型のデータを格納するFuga型コンテナ、みたいな。
                Fuga型の仕組みはHogeが何だろうとそうそう変わるわけじゃないけど、一方でFuga型は
                Hoge型とそれ以外とを差別化したくて、しかもHoge型に使いたい型の候補は1つじゃないと来たもんだ、
                というケースですね。「型を作る」ときに他の型(とか)で修飾(?)したくなるという状況。

                そう。「型を作る」なんですよね、問題は。
                Hogeに相当する型を取っかえひっかえして色々なFuga型ファミリーを作りたい、という。

                で、俺としては、いいかげん面倒だから、全部動的にしちゃえ、と思っているわけです(笑)。
                ただまあ、JavaのGenericの方向性は、C++みたいなドロドロしたものにはならずに済むと聞いてる
                (C++のtemplateは導入によって理解が難しくなる(笑)が、GenericなJavaはむしろすんなり理解できる)
                んで、まあ有っても良いかなとは思ってますし、必要に迫られりゃ俺も使うでしょうね。

                >この「ほんの少しでも変わるとがらり」に相当するような挙動は見たことがないです。

                出来れば(出来るだけ)、GCの「挙動」なんかに関わらずに済ませたいものです。
                親コメント

物事のやり方は一つではない -- Perlな人

処理中...