- 1 名前：デフォルトの名無しさん mailto:sage [2009/12/06(日) 23:54:00 ]
- (#ﾟーﾟ)つ ＜ C#、.NETの話題はこちらでどうぞ。
前スレ
C#, C♯, C＃相談室 Part55
pc12.2ch.net/test/read.cgi/tech/1255530225/
Visual C# 2008 Express Edition 日本語版
www.microsoft.com/japan/msdn/vstudio/express/vcsharp/
その他テンプレ>>2-5くらい
- 266 名前：227 mailto:sage [2009/12/27(日) 15:43:44 ]
- >248
ありです。
>250
ピーク時は一秒間に数百回コールされる可能性あるので。
- 267 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 15:51:11 ]
- 値の取り方はわかってんだから実際に1000回取得して
掛かる時間とかCPU負荷とか調べてみりゃいいじゃん
- 268 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:01:11 ]
- >>266
最大限見積もっても1,000回/sec程度の頻度の読み出しでパフォーマンスを気にする
必要があるほど重い処理とは思えないけどね。
- 269 名前：227 mailto:sage [2009/12/27(日) 16:05:51 ]
- >267
もともとはTickCountのほかに何かいい方法があるかという趣旨の質問です。
>268
1ミリせく違うだけでも一秒の違い生じますが。
- 270 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:09:52 ]
- 1ms違えばそうだろうけど1μs違うだけなら誤差だろ？
- 271 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:10:09 ]
- >>269
msオーダーの時間が掛かるわけないでしょw
恐らく10nsかかんないよ。
10のマイナス6乗見積もる時間が間違ってる。
- 272 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:14:02 ]
- なにをしたいかわからないけど、こんなにたくさん呼ばれるということは、
順番だけが重要なんじゃないか？
- 273 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:43:30 ]
- >>271
10nsって面白い冗談だ。
メモリアクセスですら何倍もかかるというのに
- 274 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:45:18 ]
- まあTickCountは確か数十nsくらいだったと思うけどな。
QueryPerformanceCounterになるとマイクロ秒以上かかる。
- 275 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:48:17 ]
- でまあ元質問の話じゃ別に気にするような用途じゃなかろうが、
キャッシュとかを実装しようとすると気になる話ではあるよ。
TickCountは精度は悪いが速いってこと以外に
値が32ビットに収まるって利点と欠点がある。
- 276 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 16:52:20 ]
- キャッシュとかの実装だと、場合によっては数十nsオーダのパフォーマンスになることもあるからな、
マイクロ秒なんで膨大なオーバーヘッドだ。
- 277 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 17:09:32 ]
- ナノwwwwwwwwwセクwwwwwwwwwwww
- 278 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 17:54:41 ]
- 当然「呼び出し一回あたりの平均処理時間」の話をしてるんだけど、
なんか通じてない奴が数人いるようなw
- 279 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:01:14 ]
- よくわからんが、毎回数字さえ変わればいいなら、
Interlocked..Incrementでカウントアップしたほうが早いんじゃないかな。
- 280 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:07:35 ]
- そんな奴はいない。
まあ平均ってのも曖昧な値だけどな。
- 281 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:17:32 ]
- 用途がカウントアップで合ってるのかって話は置いといて、
なんでインタロックなんだよ。
元の話は明らかにスレッドセーフではない前提なのに。
大体インタロック使ったらTickCountより遅くなるかも知れんぞ。
- 282 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:21:59 ]
- 勘違いしてると思う書き込みを示せば？
時間を書いてるのは明らかに平均だよな、平均でしか測定不能だし。
10nsへの突っ込みに噛みついてるのかな？
特に元の話でなら呼び出し頻度は低い前提だから、
どっちにしてもメモリアクセスより速い訳がないな。
- 283 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:24:11 ]
- >>278
どれが早いと言う話は方がついている。それで遅いならお前の実装が悪い。
- 284 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:30:30 ]
- サイズの大きいメモリストリーム、例えば数十MB以上とかを、
ひょっとするとたくさん同時使う可能性もあるとき、
組み込みのメモリストリームだとエラーになるリスクが大きい。
断片化を避けるために例えばチャンクわけして小さめの配列のコレクションを持つメモリストリームを作ったりとか
いろいろ考えるんだが、他にいい方法はあるだろうか？
サイズが一定のしきい値をこえたら、テンポラリ指定の実質オンメモリファイルを作成するのはどうかなと考えたんだけど、どう思う？
- 285 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 18:36:59 ]
- 実質オンメモリファイルだと、ストリームをプロセス外にうまく追い出せる気がするので、
パフォーマンスオーバーヘッドは大きいとしてもメモリ的にはかなり上限を増やせる気がするんだ。
64ビットOSならそんなことあまり気にしなくてもいいんだろうけど。
- 286 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:09:49 ]
- >>281
Interlock系はCASなんじゃないの？確認はしてないけど。
- 287 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:28:29 ]
- メモリ(CPU)使用率を一定に抑えたり、逆に出来る限り沢山使ったりということはできますか？
計算処理がとても重くPCがすごく重くなってしまいます
一瞬で答えが欲しいタイプのものではないので
バックグラウンドでまわしっぱなしで放置する
といった使い方をしたいのですが
- 288 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:33:32 ]
- ぷらいおりてぃ
- 289 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:35:08 ]
- Process.PriorityClassね
- 290 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:37:13 ]
- 場合によってはThread.Priorityも。
- 291 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:38:44 ]
- ＞メモリ(CPU)使用率を一定に抑えたり、
＞Process.PriorityClassね
何の効果もないわな。
- 292 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:39:05 ]
- ﾌﾟﾗｲｵﾘﾃｨそんなに大事か?
- 293 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:40:29 ]
- >>286
何が言いたいのか分からんが、CASだからなんなんだ？
そもそも（最初の話での用途的には）CASの必要がないだろって話だろ？
- 294 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:42:31 ]
- 優先度ってのはCPUのタイムスライスをどのスレッドに割り当てるかの優先度なんだよ？
だからCPUがアイドルなら優先度が低かろうがCPUは実質100%割り当てられる。
まあ最近のCPUはそもそもマルチコアが普通だから、結局25とか50になるけど。
- 295 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:44:19 ]
- 例えば後ろで動画をエンコーディングしつつ動画見るってシチュエーションで
動画再生がスムーズに行かないって時にプライオリティ設定は覿面
メモリを制約するのは知らないなぁ
- 296 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:44:25 ]
- >>291
> 一瞬で答えが欲しいタイプのものではないので
> バックグラウンドでまわしっぱなしで放置する
> といった使い方をしたいのですが
ちゃんとここも読もうね
質問者が何を求めてるかちゃーんと理解しないとだめだよ！ｴﾍ！
- 297 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:46:45 ]
- そりゃそうだけど、優先度を落とすのは「PCがすごく重くなってしまいます」への解決にはなるでしょ。
- 298 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:48:05 ]
- で、結局どうすればいいんだよ？
- 299 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 19:49:42 ]
- >>293
最初の話は>>227だろどう読んだら
＞元の話は明らかにスレッドセーフではない前提なのに。
なんだ？
＞大体インタロック使ったらTickCountより遅くなるかも知れんぞ。
CASなら競合が無い限りAPI呼び出すより速いだろ。
タイムスタンプの変わりに世代をあらわす整数で十分という前提なら、
この方はどうかということを言ってるのだが。
- 300 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:05:55 ]
- 一億回実行
Interlocked.Increment：00:00:01.3034899
Environment.TickCount：00:00:00.3905401
- 301 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:08:13 ]
- もちろん1スレッドで競合なし。
ま連チャン呼び出しなので、TickCountは実質キャッシュ読み取りだな、APIはコールしてても。
- 302 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:09:09 ]
- 気持ち悪いな。
IT土方ってパチンカスみたいに頭やられてる奴しかいないのかね。
- 303 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:10:35 ]
- ただし調査環境は2コアプロセッサ。
Interlockedはシングルなら多分もっと速いだろうが、そんな前提はあまりよろしくはないな。
- 304 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:11:09 ]
- >>300
調査ご苦労さん
- 305 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:14:06 ]
- すごいな、3倍以上も。
圧倒的な差じゃないか
- 306 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:27:36 ]
- } が必要です。
- 307 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:32:29 ]
- ついでだ。
こっちは遅いので1000万回で。
DateTime.Now：00:00:02.2796051
DateTime.UtcNow：00:00:00.1485831
Stopwatch.GetTimestamp：00:00:06.9976666
※Stopwatch.GetTimestampはつまりQueryPerformanceCounterね
- 308 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:32:34 ]
- TickCountとかQueryPerformanceCounterとかCASとか
結局は議論より実測してみるのが一番だな。
- 309 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:32:38 ]
- 誰だよ10nsなんてありえねえって言ったのは。
- 310 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:33:29 ]
- こんなに差がでるのか
Interlocked厨涙目wwwwwwwwwwwwwwwwwww
- 311 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:34:48 ]
- UtcNowとNowも、ちりつもだと差が開くもんだな
- 312 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:36:49 ]
- 1秒に1000回やったとしても
体感上全く差が無いレベルだけどな
- 313 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:37:22 ]
- 1回あたり約
Interlocked.Increment：13ns
Environment.TickCount：4ns
DateTime.Now：228ns
DateTime.UtcNow：15ns
Stopwatch.GetTimestamp：700ns
てところか。
- 314 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:38:50 ]
- ＞誰だよ10nsなんてありえねえって言ったのは。
ハードウエアから読み取るタイミングおよびキャッシュされてない前提での話だったじゃん。
この調査はほぼキャッシュ読み取りなんだから速いのは当たり前。
- 315 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:41:09 ]
- 結局
>>234
が実証されたわけだ。
- 316 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:42:40 ]
- 気持ち悪いな
- 317 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:47:33 ]
- >>310
>>313
Ｉｎｔｅｒｌｏｃｋed厨だが、そこそこ検討してて安心したよ
- 318 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:50:51 ]
- >>314
キャッシュってのが何のことを言ってるのかわからないけど、
Environment.TickCountの値はシステムで一つだから、もともとその処理には
HWからの読み取りなんて入ってないと想像する。
っていうか、PCのアーキテクチャ詳しいわけじゃないけど、
もともと高精度のHWタイマは必ずしも持ってないんじゃないの？
持ってるのなら巷間いわれてるような「計測精度を上げるとPCへの負荷が変わる」
なんて現象は起こらないはず。
もしそんなことが本当に怒るとすれば、それはタイマ割り込みでSWでタイマを
実装してるからだろう。
- 319 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:52:02 ]
- 本当に怒っちゃうぞ
- 320 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:54:45 ]
- タイマは持ってて、システムの領域にセットされるタイミングが違うとかじゃない？
いや俺も知らないんだけどね。
- 321 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:55:55 ]
- あーでもそんな頻繁にセットしてるってのも考えにくいのかな？よう分からん。
- 322 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:57:37 ]
- そこらへんなんかもう実行環境依存だったりするんじゃないの？
- 323 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 20:58:56 ]
- どういう意味の高精度かは分からんが、x86ならクロック毎でカウントするタイマーがある。
- 324 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:08:42 ]
- >>323
だから、持ってるとしてそれをシステムが使ってるのなら、
アプリレベルではないのと一緒でしょ。
- 325 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:10:19 ]
- x86のrdtscかな。
z80だったかDRAMのリフレッシュ用のレジスターがあって
ゲームの乱数に使っていた遠い記憶が・・・（笑
- 326 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:11:42 ]
- >>317
4コアだと多分さらに倍は遅いぜ。
- 327 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:13:53 ]
- #region
はらたいらも真っ青
#endregion
- 328 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:28:18 ]
- >>319
どぞ
- 329 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:44:54 ]
- しょうもねー議論だわ
- 330 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:47:07 ]
- >>323-325
Stopwatch.GetTimestampが内部で使っている可能性はある。
たぶん、今時のハードウェアならHPETを使っているのだと思うけど。
Stopwatch.GetTimestampはネイティブのQueryPerformanceCounterに対応するとされる。
msdn.microsoft.com/ja-jp/library/system.diagnostics.stopwatch(loband).aspx
QueryPerformanceCounterはRDTSCまたはもっとましな手段を使うという話がある。
msdn.microsoft.com/ja-jp/library/bb173458(loband).aspx
- 331 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 21:58:17 ]
- >>330
なるほど、奥が深いな・・・
- 332 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:24:38 ]
- >>331
酸素が薄くなってきましたね・・・
- 333 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:36:08 ]
- static Stopwatch() {
bool succeeded = SafeNativeMethods.QueryPerformanceFrequency(out Frequency);
if(!succeeded) {
IsHighResolution = false;
Frequency = TicksPerSecond;
tickFrequency = 1;
}
else {
IsHighResolution = true;
tickFrequency = TicksPerSecond;
tickFrequency /= Frequency;
}
}
public void Start() {
if(!isRunning) {
startTimeStamp = GetTimestamp();
isRunning = true;
}
}
public static long GetTimestamp() {
if(IsHighResolution) {
long timestamp = 0;
SafeNativeMethods.QueryPerformanceCounter(out timestamp);
return timestamp;
}
else {
return DateTime.UtcNow.Ticks;
}
}
- 334 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:40:43 ]
- (・∀・)
- 335 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:50:52 ]
- ＞Environment.TickCount：00:00:00.3905401
TickCountは単位としては1/1000秒、精度的には1/100秒程度だろ。
この例では1億回の実行中に39種類しかtickを返してないわけだ。
ちとずるいな。
- 336 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:53:16 ]
- ずるいとかそういう問題なのか？
- 337 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:54:16 ]
- そういう問題だ。ケチ付けんな。
- 338 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 22:59:09 ]
- ケチじゃなくて疑問でしょ。
突っ込まれたら答えられない程度の理解の人が
急いで先回りで釘刺すみたいな反応しなくても。
- 339 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:00:43 ]
- - - - - - - - やまおり - - - - - - -
- 340 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:03:29 ]
- タイムスタンプの呼び出しを気にするような
微細なキャッシュ処理をしてるのに、
タイムスタンプが荒すぎるんじゃないのかと。
- 341 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:08:06 ]
- 227をどう読んでも、その後の227の話をどう読んでも
そんなに粗いとは思わないがな。
- 342 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:09:26 ]
- それは、はじめから分かっていたこと。
たぶんロジックを考え直せばシリアルをつけていけばすむ。
- 343 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:13:01 ]
- ハナから精度の問題じゃねえじゃん。
だから「そういう問題なのか？」って言ったのに。
死ね土方。
- 344 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:14:07 ]
- …
- 345 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:15:40 ]
- 2chには同族嫌悪というか、ニートとかドカタとか同じ境遇の人がののしりあう傾向があるな。
- 346 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:17:01 ]
- 病んでるからね
- 347 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:21:54 ]
- それで少しでも救われるなら喜んでドカタと罵しられるさ。
- 348 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:22:45 ]
- もうすぐハッピーニューイヤーなんだから明るく行こうぜ。
- 349 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:28:35 ]
- お前ら明るく行こうぜ！！！！！！！！！！！
- 350 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:28:46 ]
- テキストデータベースの効率のいい検索方法ってどんな方法がありますか？
Google検索とか膨大なデータベースの割に一瞬で検索できますよね？
どういう仕組みなんでしょうか
- 351 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:31:44 ]
- >>350
Googleはアルゴリズムはもとよりバックボーンが凄いんだと思う。
MapReduceとかもそのバックボーンがあってこその仕組みだし。
テキスト全文検索ならwikipediaにまとめがあるからそっからたどるといいよ
ja.wikipedia.org/wiki/%E5%85%A8%E6%96%87%E6%A4%9C%E7%B4%A2
- 352 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:32:05 ]
- >>350
Google検索に関しては
あらかじめ分類して結果をキャッシュしておく。
最新のデータを使わずキャッシュを使う。
正確さを求めない。
なので勘定系のＤＢでこういう手法はご法度。
- 353 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:33:31 ]
- 全文検索はインデックスを先に作るってことで処理速度の短縮を測るのが多いような。
最近のDBはそういう全文検索機能まで付いてるのもあるんじゃなかったっけ？
- 354 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:35:30 ]
- (・∀・)ﾆｭｰｲﾔｰ!
- 355 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:41:49 ]
- >>335
ずるいっちゃずるいんだけどさ、最初からそういう話で
今さらそこを突っ込まれても困る。
- 356 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:45:19 ]
- たとえばintとlongの計算どっちが速い？
って疑問が出たとして計測したらintのが速かったとして
そこで、intはビット数半分だろ？ちとずるいな
って言われても困るんだ。
- 357 名前：デフォルトの名無しさん mailto:sage [2009/12/27(日) 23:56:23 ]
- 一緒だけどな。
- 358 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 00:23:38 ]
- 一緒だね
- 359 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 00:29:06 ]
- ずっと一緒だよ ///
- 360 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 00:38:24 ]
- x64なら同じ、x86ならlongのが3倍ほど遅いという結果になった。
- 361 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 00:55:02 ]
- x64、x86と来たら次はｘ108になるのかな？
- 362 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 00:55:48 ]
- 80186ですね。わかります。
- 363 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 00:56:13 ]
- 話を戻すが、>>227はキャッシュの有効性を判別する値に使いたいんだから、
精度(precision)はどうでもいいけど分解能(resolution)はかなり重要
で、それぞれの(公称の)分解能は
Environment.TickCount: 500ms
DateTime.UtcNow: 10ms
Stopwatch.GetTimestamp: H/W性能に依存
>>266によると「ピーク時は一秒間に数百回コールされる」とのこと
簡単のため500Hzとすると周期は2msで、あきらかに前2者は不十分
- 364 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:00:04 ]
- ＞Environment.TickCount: 500ms
まあこれは実態に合ってない数値だけどな。
それはおいといて、更新を確実に確認したいなら素直にカウントにするべきだわな。
- 365 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:01:28 ]
- あれＩｎｔｅｒｌｏｃｋed厨大勝利の流れ？
- 366 名前：デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:05:00 ]
- なんでedだけ小文字なん
|
 |
