トップページ > ソフトウェア > 2011年12月07日 > lCMAxtpR0

書き込み順位&時間帯一覧

1 位/826 ID中時間01234567891011121314151617181920212223Total
書き込み数12000010130382000000000021



使用した名前一覧書き込んだスレッド一覧
名無しさん@お腹いっぱい。
JustSystems ATOK総合スレ Part64
Mozilla Firefox Part180
Google日本語入力 サジェスト14候補目

書き込みレス一覧

JustSystems ATOK総合スレ Part64
492 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 00:12:41.14 ID:lCMAxtpR0
>>489
> 「軒を貸して母屋を取られる」で、結局のところは

それに見合う金をもらったんだろ。
Microsoftは基本的に外部のソフトを買収する場合は、
その時のソースはもちろんのこと、未来永劫改変する権利も買い取る。
Visual C++とかも(当時はMS-Cだったが)、大昔にLattice Cを買い取ったものがベースだし。


最初のMS-CはLattice Cとほぼ同じだったが、Microsoftはどんどん改良していって
すぐに性能もシェアも本家を追い越した。
JustSystems ATOK総合スレ Part64
495 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 01:38:44.21 ID:lCMAxtpR0
>>494
そうやってなんかいいこと言ってるつもりなんだろうねぇ。
Mozilla Firefox Part180
604 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 01:40:14.36 ID:lCMAxtpR0
>>603
google全鯖 < 俺たちの本気を見せてやるぜ
JustSystems ATOK総合スレ Part64
498 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 06:53:50.60 ID:lCMAxtpR0
>>496
ちゃんとwindowsに対応したのはwxシリーズの方がatokより先立ったんじゃ。

カーソル位置にプルダウンメニュー的に変換候補が出てくるようになったのは
wxシリーズが先で、その頃atokはdos時代を引きずって、画面の最下行に
横一列にファンクションキーの位置に変換候補が表示されたはず。

アプリとの統合もatokは遅かった。入力文字は一応カーソル付近に出てくるが、
アプリと関係なしに出しているので、ウィンドウの境界をお構いなしに
どんどん右に入力したテキストが表示された。
確定してはじめてアプリの描画領域に文字列がきちんと表示される。

Mozilla Firefox Part180
631 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 08:09:06.00 ID:lCMAxtpR0
>>608
気になるじゃないか。理由がわかったなら、教えろよ
JustSystems ATOK総合スレ Part64
500 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 09:35:47.45 ID:lCMAxtpR0
>>499
その小学生低学年並のボキャブラリーを何とかしろ。
おまえにatokは必要ない。
Mozilla Firefox Part180
642 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 09:37:28.24 ID:lCMAxtpR0
>>641
firefoxはつっかえるからねぇ。ぎこちないというか。
まあシングルスレッドの限界ですな。
Mozilla Firefox Part180
644 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 09:41:38.70 ID:lCMAxtpR0
>>643
おまえは自分の方が恥ずかしい勘違いしてると、永遠に気づかないだろうな(苦笑
Google日本語入力 サジェスト14候補目
252 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 11:34:56.63 ID:lCMAxtpR0
文節の区切り方の指定方法も知らない奴に呆れた。
どのIMEもできるだろうに。
JustSystems ATOK総合スレ Part64
505 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 11:51:44.99 ID:lCMAxtpR0
>>501
> 広辞苑変換辞書を標準辞書セットに入れると変換精度や速度が落ちる可能性が...と書いてますね(汗

これがatokが複数の辞書を分割している最大の欠点なんだよな。
その通り。atokで辞書をいろいろ追加すると、変換精度は若干落ちる。
google imeは大量の語彙を持っているのに落ちない。atokは落ちる。

記号辞書や駅名辞書も同様で、atokは複数の辞書を標準辞書に入れるほど、
変換精度は悪くなっていく。なぜかわからないが。

で、俺は結局試行錯誤のすえに、普通の変換キーでは標準辞書のみの変換。
別のキーでは広辞苑や駅名辞書など語彙数で勝負の変換に使い分けた。
「ユーザーが辞書切り替えを意識すべきではない」というのが俺の持論なのだが、
atokを使う以上はどうしようもなかった。それだけにgoolge imeの登場は衝撃的だったのだけどね。

で、なぜatokの場合追加辞書を増やしていくたびに変換精度が悪くなっていくのか?
結局良くわからなかったのだが、つまるところ変換候補の並び順の問題な気がする。
何度か述べているが標準辞書でさえ、学習していない初期の状態の変換候補の
並び順には不満がある。使用頻度の高いものが上位に出てこない。

これが複数の辞書を併用すると増幅されるのではなかろうか。
atokが複数の辞書の間の優先順位をどうやって決めているのか、よくわからないんだよね。


JustSystems ATOK総合スレ Part64
506 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 11:51:55.79 ID:lCMAxtpR0
それと分節区切りが馬鹿になりやすい。atokは文節区切りを学習しにくいので、
何度変換しても馬鹿のまま。広辞苑とかに一つの文節として登録されている単語があると、
使用頻度が高くても標準辞書に入っている2つの文節からなる単語が候補として出てこない。
学習もしないので毎回文節を区切りなおさないとならない。

まあ長い文節にマッチする方を優先するというのはアルゴリズム的には間違っていないと思うが、
なんかね。google imeの場合不思議とそういうパターンで苛立つことが少ない。
1文節か2分節かを含めて優先順位が決められている気がする。

atokの場合は先ず1文節の中で優先順位を判定し、その時点でマッチするものがあれば、
どんなに高頻度で使われる単語があっても2文節は探しに行かない様に見える。
だから後者を変換させるには手動で文節を区切り直さなければならない。

ms-imeも以前は同じだったのだが、最近のは若干改善されている気がする。
文節を含めて優先順位を決定しているし、学習もする。

ようするにジャストシステムが長年ふりまいた「語彙を増やすと変換精度が下がる」というのは
atokの文節の処理のアルゴリズム的な欠点なんだと思うよ。

Mozilla Firefox Part180
658 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:00:31.35 ID:lCMAxtpR0
>>651
> マルチプロセスに対応していないって言ってるんでしょ
> シングルスレッドはシングルプロセスの間違えかな?

間違いじゃない。2つのことを言っているのだよ。それが理解出来ない単純なオツムの人が多くて困る。

先ずマルチスレッドの話。firefoxはhttpの通信、htmlや画像のデコードと描画、
メニューなどのユーザーインターフェイスを1つのスレッドでやっている。
一応一つの処理が長く占有しないように適当なタイミングで一旦処理を終わらせ、
他の処理(通信だったら、描画、描画だったらUIと)に順に作業を移すようには作られているが、
どうしてもまとまった処理はまとめて処理したいから、状況によっては他の処理に
なかなか順番が回ってこないケースもある。

これがメニューなどユーザーインターフェイスのぎこちなさに現れているわけだ。
気づきにくいが通信の効率性も落ちている。

要するに処理の切り替えはOSに任せるのが一番効率がいいわけ。
アプリが自分で処理を細切れにするよりも、プログラムは作りやすいし、負担も小さい。
そのうえずっと細かく各処理を分割できるから、パフォーマンスもよくなる。
これがfirefoxがchromeに逆立ちしても勝てない理由。

Mozilla Firefox Part180
660 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:05:24.47 ID:lCMAxtpR0
で、次にマルチプロセスの話。
このように処理の分割をOSに任せる場合、マルチスレッドで実現するか、
マルチプロセスで実現するかが問題となる。

基本的に通信、描画、UIの3つは1つのプロセスの中でマルチスレッドで
実現するしかないだろうと俺は思う。共有する処理が多すぎるから、
複数のプロセスに分割したら、データの受け渡しが大変。

まあでもマルチプロセスでどうしても実現したいなら、それはそれで一つの選択だし、
データの共有が疎になる分、安定性は増加するはず。作るのは大変だが、
一旦作ってしまえば「よくわからないバグ」はマルチスレッドよりも減るだろう。

大変というのplugin containerを一生懸命別プロセスに分離したのだから、
それが出来たのだから、本体のマルチプロセス化もできない理由はない。

ここまでがパフォーマンスの話。



Mozilla Firefox Part180
662 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:12:10.99 ID:lCMAxtpR0
マルチプロセスにする理由はもうひとつある。安定性とセキュリティ面で有利だからだ。
chromeがタブごとにプロセスを分離しているのもこれが理由だろう。
余談だが、chromeはタブごとにマルチプロセス化しているだけでなく、
一つのプロセス内でもマルチスレッドで構成されていると思われる。

だから通信と描画処理がスムーズに並行してできるわけ。
描画が忙しくて通信が疎かになったりしない。
firefoxの場合1つのスレッドでやっているから、どうしてもまとまったデコードや描画の
処理をしていると、通信の方が疎かになるのは前述のとおり。

で、マルチプロセスならそのプロセスがバグかなにかでクラッシュしても
他のプロセスは動き続けることができるから、それがchromeのウリになっているわけだ。
同様にfirefoxのpluginもplugin内でクラッシュしてもfirefox全体がクラッシュするのを避けている。

ただ、これはタブ毎とかpluginとか処理が独立しているからできる芸当で、
通信、描画、UIを各プロセスに分離しても、描画がクラッシュしたから
そのプロセスだけ起動しなおして全体がクラッシュしないように云々というのは
ナンセンスだろう。意味がない。

ということで、
パフォーマンスの話をするときはマルチスレッドについて主として論じ、
安定性の話をする時はマルチプロセスについて主として語っているわけ。

Mozilla Firefox Part180
665 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:13:55.13 ID:lCMAxtpR0
>>659
自分に理解出来ないことはすべてキチガイ認定するというのも
面白いやつだな。つまりおまえより頭のいいやつはみんなキチガイなわけだ。
さぞかしおまえの周りにはキチガイが溢れていることだろう。
Mozilla Firefox Part180
666 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:14:33.09 ID:lCMAxtpR0
>>661
そういわれても、そうなんだから、困るな(笑
Mozilla Firefox Part180
668 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:15:01.23 ID:lCMAxtpR0
>>663
おまえの文句をいう場でもないな。
Mozilla Firefox Part180
670 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:22:25.07 ID:lCMAxtpR0
>>669
おまえはそれがどこから予備されているかもわからないようだな(笑
あほすぎて呆れる。
Mozilla Firefox Part180
671 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 12:23:26.13 ID:lCMAxtpR0
×予備されている
○呼び出されている
JustSystems ATOK総合スレ Part64
511 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 13:53:13.65 ID:lCMAxtpR0
>>509
> そのために候補選択にスペース=キーを何回も押したり、文節区切り直すのが手間でも、それはまったくいといません。
> SKK Largeに入ってる一般名詞・地名・会社名で、ATOKでは変換できない単語にたくさん出会うと
> 力不足という感じがしていました。(あくまで私個人の基準ですよ!)

それならgoogle imeを使えばいいんじゃないか?タダだし。
atok+広辞苑と比べてgoogle imeの語彙数が劣っているとは思えん。

広辞苑はあくまで辞書引きの便利さのために買うもので、
変換の語彙数を増やすために買うのは、コストパフォーマンス悪すぎ。
Mozilla Firefox Part180
680 :名無しさん@お腹いっぱい。[sage]:2011/12/07(水) 13:59:43.14 ID:lCMAxtpR0
>>673
WindowsのアプリとしてDLLとかが勝手に起動するスレッドは別な話。
上で述べているように、通信処理、デコード・描画処理、UI処理など、
あくまでアプリケーションとしての作りの話をしているわけで。

>>676
> OSが切り替えるのはプロセスのCPU使用時間とスレッドのCPU割り当てだけ。

何を言ってるのか、というか何を言いたいのかさっぱりわからんね。
というかわけもわからずOSの入門書に書いていることを書き並べているだけに見える。
基本的に間違ってはいないが、だからどうしたの?と(笑

> マルチプロセスとマルチスレッドは両方実装出来る。

そう書いてるつもりだがね。

>>662
| 余談だが、chromeはタブごとにマルチプロセス化しているだけでなく、
| 一つのプロセス内でもマルチスレッドで構成されていると思われる。

と。ひとつづきのレスぐらい全部読めよ。アホかと。


※このページは、『2ちゃんねる』の書き込みを基に自動生成したものです。オリジナルはリンク先の2ちゃんねるの書き込みです。
※このサイトでオリジナルの書き込みについては対応できません。
※何か問題のある場合はメールをしてください。対応します。