[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 2chのread.cgiへ]
Update time : 07/14 21:46 / Filesize : 141 KB / Number-of Response : 721
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

C#, C♯, C#相談室 Part55



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くらい

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
Interlocked厨だが、そこそこ検討してて安心したよ

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検索に関しては
あらかじめ分類して結果をキャッシュしておく。
最新のデータを使わずキャッシュを使う。
正確さを求めない。

なので勘定系のDBでこういう手法はご法度。

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と来たら次はx108になるのかな?

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 ]
あれInterlocked厨大勝利の流れ?

366 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:05:00 ]
なんでedだけ小文字なん

367 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:09:28 ]
>>363
どうでもいいことに突っ込んで悪いけど、計測において「精度」と対比されるのは
「確度」じゃないの?

その分解能って精度とどう違うのよ?
というより、それって精度そのものじゃん。

368 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:21:03 ]
いやまあ、たぶんLSBの大きさっていうか、
最小測定単位のことを言いたいんだろうってのは分かるけどね。

ただ、>>363に出てくる測定値の「誤差」ってのは、計測器そのものの
量子化誤差によるものというより、測定器を操作する側(つまりソフト)の
問題に起因する誤差だから、「分解能」ってのは概念的にしか意味を持たないよね。

369 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:21:50 ]
ないない



370 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:45:53 ]
>>365
いや、同一スレッドで(Interlocked使わずに)インクリメント&取得をする方がベター

371 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 01:54:28 ]
どこの国のベターだよ

372 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 02:00:20 ]
>>227は下層のエレメントが多数合って、
不特定のスレッドから勝手に情報が書き換えられるイメージで、
上層の管理スレッドが下層のエレメントの様子を見て
変更があればそれに応じた処理をするのだと思うけど。
そうなると変更があったことを示すシーケンスを作る出すのが
同一スレッドというわけにはいかない。

373 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 02:28:52 ]
そうは思えんが。
>上層の管理スレッドが下層のエレメントの様子を見て
>変更があればそれに応じた処理をするのだと思うけど。
こんなことを別スレッドで監視する馬鹿はいない。


374 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 02:34:02 ]
更新自体は複数スレッドからあったとしても、
こういうバージョンカウンタはスレッドセーフでなくてもよい場合もある。


375 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 02:35:10 ]
[割り込み|シグナル|コールバック|イベントドリブン]が理解できないので〜〜〜
よくある話ではある。

376 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 02:44:20 ]
そういう話なら、そもそもバージョン管理自体入らないんじゃね。
変更があったら即書き換える。

377 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 02:58:19 ]
ウェブサーバーもシングルスレッドで大丈夫とか言っちゃう人かな。
できなくはないだろうけがしんどいのと違うかなぁ。
>ピーク時は一秒間に数百回コールされる可能性あるので。 


378 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 03:16:13 ]
>>350
分散処理

379 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 07:20:38 ]
0



380 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 07:43:12 ]
実行中に時刻の修正が入ったら、どうなる?

381 名前:デフォルトの名無しさん mailto:sage [2009/12/28(月) 07:47:12 ]
DateTime系以外は影響なし







[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<141KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef