Bulldozer入門
ふたつのコアで1モジュールを構成する それぞれのコアは、4本の整数パイプと、L1D を持つ 整数は、基本的な演算+メモリアクセスを実行するAGLUx2 と、パイプごとに対応する命令を実行するEXx2の4本 L1I、Fetch、Decode、L2、FPUはふたつのコアで共有されている L1I->Fetchは32Byte、4命令デコード/clk FPUは、4本が色々と命令できて、うち2本が128bit FMAを実行できる 思想としては、 FPUはリソース多く使うので無駄遣いしないように実行効率を上げたい → FPUをヘヴィに使うプログラムでは HT みたいになる 整数は軽いのでたくさん入れたい → サーバー等ではHTよりも絶対性能高い ということなんだと思われる。 命令単位ベンチマーク 実際どうなっているか命令単位でベンチマークしてみる ソース(Win32 cl.exeが必要) 手元(A8-4
データモデル考え中 - 急がば回れ、選ぶなら近道
ただいま社内的に論争中なのでちょっとまとめておく 分散環境でのデータモデルはどうあるべきか という議論。 分散環境は非同期処理が中心にはなるのだが 画面系を中心に同期処理も入ってくるので その組み合わせを前提に考えないといけない。 基本的に外部から変更不能のタイミングが必ずある というのが、まずは原則論にはなる。 分散処理のレイテンシーはこの先下がる一方なので ますます使われるようにはなると思う。 その辺りを前提として 各考え方のメリット・デメリット をまとめて置きたい。 1プロセス中心指向 プロセス・フローを中心にモデル（型）の議論をすべき という考えかた。 フローモデルは、プロセス->プロセスが基本で 受け渡しをするエッジの部分がデータモデル的位置付け そもそもデータモデル自体は、 黙示的に一種の振る舞いを想定するはずなので 振る舞いの記述にウェイトを置いた方が良い、 という考え方でも
いきあたりばったりのアーキテクチャと教訓
スライドの作者であるGleicon Moraesは、これらの図を示した上で、リレーショナルデータベースはガムテープのようにつぎはぎで使えるような万能薬ではない。シャーディングや非正規化などは検討すべきよい選択肢であり、またリレーショナル以外のデータベースも選択肢としていれるとよいだろうと説いています。 そして次のような「リレーショナルデータベースの間違った使い方10項目」を示しているのです（訳は前述の記事「データベースの間違った使い方10項目」から）。 Dynamic table creation（動的なテーブルの作成） Table as cache（テーブルをキャッシュとして使う） Table as queue（テーブルをキューとして使う） Table as log file（テーブルをログとして使う） Distributed Global Locking（分散したグローバルなロック）
MVCとPAC - noopな日々
Presentation-Abstract-ControllerとModel-View-Controllerについてさらっと言及 MVCアーキテクチャはある程度の規模になると限界が訪れる。 http://c2.com/cgi/wiki?RecursiveModelViewController http://d.hatena.ne.jp/noopable/20090127/1233014697 この、1999年の記事でPACについて触れられているが、PACはMVCのスケール問題、その他を解消しうる。MVCでも、RecursiveMVCでMVCに階層構造を持ち込んで解決するという方法もあるらしい。 http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#fig:pac 似たようなことは誰でも一度は考えることだろう
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
ricollab Web Tech Blog » Blog Archive » RESTアーキテクチャスタイル入門の記事をすべて公開しました
1月に三分の一を公開して以来、ずるずると遅れていた残りの記事の公開をやっと行いました。 RESTアーキテクチャスタイル入門 Web アプリケーションのアーキテクチャ Web サービスと REST RESTful な URI の設計 出版は2006年なので2年前の記事です。内容が一部古くなっている部分もあったため、現時点での最新情報に少しだけアップデートしました。
- 設計の終焉?
設計の終焉? (原題: Is Design Dead?) マーチン・ファウラー チーフサイエンティスト , ThoughtWorks エクストリーム・プログラミング(XP) をかじってみて、多くの人がこう感じ ただろう。XP は「ソフトウェア設計など消え失せろ」と言っているのではな いか、と。というのも XP では、多くの設計作業が 「料金前払いのデカい設 計("Big Up Front Design"」などとからかわれているばかりか、UML、柔軟な フレームワーク、そしてパターンまでもを含む設計技法が、ぞんざいな扱い を受けているか、完全に無視されているからだ。 実際には、XP にもたくさんの設計作業が含まれている。しかしそれを、既存 の設計プロセスとは違うやり方で行っているのだ。「進化的設計」という考え 方がある。XP はこの考え方を、「進化」を実行可能な設計戦略へとに変換す るプラク
t-pot『Xbox 360のクセ -XNA Tuning fest 2007-』
■はじめに NyaRuRu さん(Microsoft MVP for DirectX/XNA)の発案で、XNA チューニング勉強会が2007 Nov. 22 に開かれました。 内容は、NyaRuRu さんのC#やCLRの話や、XNAの開発チームのひげねこさんこと伊藤雄一さんのXNAでどのようにプログラムをすれば高速化されるかなど、とてもためになるお話がありました。 私も、つゆはらいとして話させていただいたので、その資料をさらしておきます。 ■資料 ■さいごに 長 健太(ＡＢＡ)さんが途中で質問をはさんでくれたので、やりやすかったでした。 と、いうか、結構、構成がずれて話したところもあって、すまんかったでした。
アーキテクチャドキュメントに必要なこと [arch]
最近本腰を入れて大掛かりなアーキテクチャ設計をしようとしているが，ドキュメントを書く際にいつも帰ってくるのがこのエントリー． Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal: What should be in an Architecture Document? とても素晴らしい内容なので，以下に意訳しておきます．ぜひ原文も合わせて読んでみて下さい． - ドメインモデル (もしあれば)，使用されているパターン，ガイドラインなどに特化したドキュメントを合わせて紹介すること．アーキテクチャドキュメントは，それらのガイドラインと整合性を保つこと． - 1つのドキュメントは50ページを超えないこと．肥大化したドキュメントは誰にも読まれない (少なくともその全ての内容は)． - 当たり
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Blog Zenika