zillionプロジェクト開発ブログ

[かずひろかず]

TOP500において一位の座を勝ち取った日本の次世代スーパーコンピューター、京。
ITProにそのアーキテクチャーの図解が載っています。

http://itpro.nikkeibp.co.jp/article/COLUMN/20111104/372504/?ST=system&P=1

スーパーコンピューター、響きを聞くとなんか恐れをなしちゃいますね。しかし、その演算を行うプロセッサユニットはSPARCの亜種の様なものです。なんら普通の演算器(コンピューター)と変わりません。

しかし、スーパーコンピューターの何が凄いのかというと、圧倒的なスケールにおけるその並列性です。
例えば「京」の構成は次のようになっています:
 

CPU: SPARC64 VIIIfx (4基)
メモリ: 16GB (4枚)
 

これだけでは並列処理向けに設計された優秀なRISC汎用プロセッサ(もちろんSIMDは積んでますよ)と64GBのメモリです。まだスーパー、しかも次世代とは呼びがたいものがあります。
そこでスーパーコンピューターは、並列性を高めるためにモジュールを増やすのです。
 

京はこのボードを24枚 × 約800ラック、 合計約19200枚をネットワークで繋いで一つの「スーパーコンピューター」としました。その結果、このスパコンが叩き出す性能は10PFLOPS、世界最高水準となっているのです。
 

この並列性は、現在スパコンだけでなく、私達一般向けのパソコンにも応用されています。最近は2コア、4コアなんて当たり前の時代になりました。それによって性能も伸び、コンピューティングも随分豊かなものになってきました。

しかし、アーキテクチャーはいまだ変わっていません。
64ビットになった今も、CISCの8086系列の影を引き継いでいます。
これ以上の性能向上を目指すためには、x86のしがらみを抜け新しいアーキテクチャーを創造するという、私達の一般向けパソコンにも大きなイノベーションが必要なのかもしれませんね。

[1回]

9月も半ばになり、ブログを1ヶ月近く開けてしまったようだ。

でも、しっかり続けてる。

サーバーも4,5回作りなおして、やっと方向性が定まった気がする。

今は、サーバーを作り、平行してサーバーと通信するクライアント側のライブラリを作ってる。

チームのページのSVNの方ではなく、非公開のSVNのほうで。やっぱりサーバーも通信ライブラリも、全部公開するのは、セキュリティ的問題があるだろうから。

情報五輪までは、まだまだ3ヶ月近くある。だけど、やっぱり対策には時間がかかるだろうし、やらなくて出来るなんて思ってもいないから、今後対策に咲く時間が増えていくんだろうな。

学校の文化祭で、縁日でアイスを売るので、その企画やらで忙しかったりもする。

そんなこんなで、ブログの更新が疎かになってたわけだが、やっぱりTwitterをやっていると、Twitterでいいかなって思っちゃうんだよね。

3Dの方もかなり進んでるみたい。かずが担当しているけど、3D関係のライブラリは整ってきた感じらしい。。

結局、ライブラリしかまだ作っていないので、クライアント作るのはかなり時間がかかるな。

[3回]

サーバーの方は、ログイン系に関してかなり実装が終わりました。
3Dの方と歩調を合わせつつやるというか、実際に本体を作り始めないとどのような通信が必要かわからなくてサーバーがこれ以上とりあえずは作れないので、第一段階のサーバーの実装は終了ということです。
Admin用の管理ツールの作成とか、ソースを見やすくするとか細かいことは残っていますが。。

んなわけなんですが、今年もおそらく参戦します、情報五輪。
おそらく9月から募集開始な気がしています。
12月中旬が予選。去年は全くの無対策+ケアレスミスで20点落とすという失態。(問題文よく読もう・・・)

いろいろ対策も練っているわけです。コーディング技術も確実に去年よりは上がっていると思います。
アプリケーション作っているわけですから、かなり力にはなっているはずです。

しかし、去年受けてみて実感したのは、アプリケーション作成で身につけられるコーディング技術だけではダメなんだということなんです。
やはり、アルゴリズム問題用のある程度の知識を持つ必要があります。
そしてその力は確実にアプリケーション作成にもいい影響を及ぼすのです。

ループの数を縮小してアプリケーションの高速化を図れたりするわけです。

[3回]

[kyasbal]


GAEでサーバーの方を実装中。
だけど、いろいろ難しい。
とりあえず今やっていることは、アカウント関係の実装。
どんなデータがあればいいのかとか考えつつも、セキュリテイのことも考えつつ・・・(この手のことは初心者)

GAEを使う上での、slim3っていうDB操作ライブラリの使い勝手の良さはすごい。
本当に楽だ。
GAEの管理ページにもとから標準装備の、DBビューワーはちょっと貧弱なので、管理ページもどきを新しく作ることで、ちょっと便利になった。だけど、結果的にあんまりもとからあるのと変わらないという始末。
将来的には、僕ら管理者用のアカウント管理ページとか必要だろうし、いいんじゃないかなと思うけど、今は特に作っても仕方ないな。

基本的には、クライアント側の動作で全て行うので、GAEでユーザーがブラウザを介して見るようなページは作成しない。プロジェクトが進んだら、プロジェクトのサイト作るかもね。でも、開発中の広報は、チームのredmineとJenkinsで十分だろうし、これもまだまだ先だろう。

OpenIDなんていうのも、見てみると、案外仕組みは単純だったりする。
さて、ここで今僕が一つ疑問に思っていて、更に悩んでいることがある。
GAEでユーザーがログインしているということを、どうやってサーバーがわは認識しているのだろうか。
セッション等Cookieを利用した技術であれば、クライアント側からの利用が難しくなる。C#のWebRequestクラスだっけか？ああいうので利用できるかわからないからね。
そうなれば、僕の貧弱なセキュリテイ知識で作られたCookieを一切使用しないサーバーを使うことになる。
いずれにしても、解決すべき難題は多いのだ。

OAuthについてもそうだ、この前かずと話して考えてたのだが、OAuthっていうのは、ホストアプリケーションへのユーザーの操作をゲストアプリケーションに委任するその許可を行うシステムのはずだ。
コンシューマーキーとか、わかってしまえば簡単に偽装が可能なはず。。。
それに、そういったアプリケーションのなりすまし防止用の技術でもなかったはず。
初期の計画では、クライアント側もOAuthで認証するっていう感じになっていた。
これは僕の思い込みかもしれないのだが、本末転倒じゃないのか？
たとえば、「zillionはzillionへのアクセスを要求しています。許可していますか？」などとユーザーに問いかける事になってしまうのではないだろうか。
なんとださいことか。これはおかしいはずなわけで、OAuthのコンセプトについて全く理解していなかった僕ではあったが、まだまだ実装というか活用？はまだまだ先だ。そもそも知識レベルでの解決すべき課題が大きいというのは問題だ。

さて、かずのような花形の部分を作っているわけではないので、特にスクリーンショットとか貼れないので、なんか寂しいと思います。。。
ソースなども、セキュリテイ上の観点からSVNの非公開レポジトリにあげている次第なのです。
こんな飾り気のない文章。。。読んでくれて本当にありがとね。

あと、忍者ブログの編集のFlash変わったね。綺麗になったと思う。
特に新しい機能はなさそうだけど・・・

[3回]

[かずひろかず]

DirectX10.1に対応し、アニメーションなど色々実装。

[2回]