- MFC相談室 mfc22d.dll
500 ：デフォルトの名無しさん[sage]：2014/06/12(木) 16:06:59.23 ID:SK659vFt - MFC も .NET も糞
Win32API 最高
|
- Swift part2
16 ：デフォルトの名無しさん[sage]：2014/06/12(木) 16:11:34.97 ID:SK659vFt - なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
http://www.atmarkit.co.jp/news/201004/19/twitter.html
RORのままアーキテクチャの変更で10000%高速化したとな。
ttp://b.hatena.ne.jp/entry/highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
ミニブログの Twitterのstats(統計)データ。
http://kaworu.jpn.org/kaworu/2008-01-16-2.php
- 350,000を超えるユーザ。
- 秒間600リクエスト
- 平均毎秒200-300コネクション。最大時は秒間800コネクション
- MySQLは秒間2,400リクエストを処理する
- 180のRailsインスタンスがある。MongrelのWebサーバを使っている。
- 1つのMySQLサーバ(１つの大きな 8コアのサーバ)と１つのスレーブ。スレーブは、統計とレポートのための読み込み専用(リードオンリー)。
- 雑用処理をするための30+のプロセス
- 8台のSun X4100s
- Railsでのリクエストの処理時間は200 msec
- データベースにかかる時間の平均は、50-100 msec
- 16GBの memcached
|
- Ruby 初心者スレッド Part 54
940 ：デフォルトの名無しさん[sage]：2014/06/12(木) 16:12:24.10 ID:SK659vFt - なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
http://www.atmarkit.co.jp/news/201004/19/twitter.html
RORのままアーキテクチャの変更で10000%高速化したとな。
ttp://b.hatena.ne.jp/entry/highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
ミニブログの Twitterのstats(統計)データ。
http://kaworu.jpn.org/kaworu/2008-01-16-2.php
- 350,000を超えるユーザ。
- 秒間600リクエスト
- 平均毎秒200-300コネクション。最大時は秒間800コネクション
- MySQLは秒間2,400リクエストを処理する
- 180のRailsインスタンスがある。MongrelのWebサーバを使っている。
- 1つのMySQLサーバ(１つの大きな 8コアのサーバ)と１つのスレーブ。スレーブは、統計とレポートのための読み込み専用(リードオンリー)。
- 雑用処理をするための30+のプロセス
- 8台のSun X4100s
- Railsでのリクエストの処理時間は200 msec
- データベースにかかる時間の平均は、50-100 msec
- 16GBの memcached
|
- Rubyについて Part49
602 ：デフォルトの名無しさん[sage]：2014/06/12(木) 16:13:04.40 ID:SK659vFt - なぜTwitterは低遅延のままスケールできたのか 秒間120万つぶやきを処理、Twitterシステムの“今” − ＠IT
http://www.atmarkit.co.jp/news/201004/19/twitter.html
RORのままアーキテクチャの変更で10000%高速化したとな。
ttp://b.hatena.ne.jp/entry/highscalability.com/scaling-twitter-making-twitter-10000-percent-faster
ミニブログの Twitterのstats(統計)データ。
http://kaworu.jpn.org/kaworu/2008-01-16-2.php
- 350,000を超えるユーザ。
- 秒間600リクエスト
- 平均毎秒200-300コネクション。最大時は秒間800コネクション
- MySQLは秒間2,400リクエストを処理する
- 180のRailsインスタンスがある。MongrelのWebサーバを使っている。
- 1つのMySQLサーバ(１つの大きな 8コアのサーバ)と１つのスレーブ。スレーブは、統計とレポートのための読み込み専用(リードオンリー)。
- 雑用処理をするための30+のプロセス
- 8台のSun X4100s
- Railsでのリクエストの処理時間は200 msec
- データベースにかかる時間の平均は、50-100 msec
- 16GBの memcached
|
- 【初心者歓迎】C/C++室 Ver.91【環境依存OK】
278 ：デフォルトの名無しさん[sage]：2014/06/12(木) 19:24:27.99 ID:SK659vFt - C++ の thiscall について質問です
http://codepad.org/F7k3yl9O
メンバ関数をポインタで呼び出す際に VC++ の thiscall 規約では
通常は ECX レジスタが this ポインタを指すようにするそうですが
メンバ関数が可変長引数関数だった場合は
引数を全部スタックに積んだ後に this を push するとのことで
最初の引数のひとつ前に this があることを期待したコードを書いてみました
このプログラムを実行すると実体呼び出しかポインタ経由の呼び出しかに関わらず
self と this が常に等しいと思ったのですが
直接インスタンスに対して x.vfunc(9, 80) を呼び出した場合と
ポインタを経由して x.pvfunc((short)&x, 9, 80) を呼び出した場合で
self->r の値と this->r の値が入れ替わっていますが
なぜでしょうか？
コンパイラは VC++ と dmc で試しましたが結果はアドレスが違うだけでほぼ同じでした
|
- 【初心者歓迎】C/C++室 Ver.91【環境依存OK】
279 ：デフォルトの名無しさん[sage]：2014/06/12(木) 19:26:58.04 ID:SK659vFt - 可変長引数の関数ではない普通？の関数で ECX を使った場合は
常に self == this であることは確認出来ています
|