예비 시합이라고는 해도 전 명인이 이렇게 간단하게 지다니

오늘은 좀 춥지만 아직 참을 수 있다.

어제 컴퓨터 장기 소프트와 요네나가 전 명인이 대전했다. 이것은 내년 1월에 개최될 전왕전(電王戦)의 예비 시합이다.

예비 시합을 할 이유는 아마 이것하고 같은 사람대 컴퓨터의 본격적인 대전이 거의 처음의 시도이기 때문일 것이다. 회장이나 진행의 확인을 했을 것으로 추측된다.

저는 이 시합에 전부터 주목해 있었는데 어제는 컴퓨터가 압승했다. 다음 달은 명인이 대책을 세워서 좋은 시합을 해주시기를 기대하고 있다.

xmxとxmsは小さければ小さいほど良い?

かなり誤解していたところがあるが、JVMのヒープ領域は大きければ大きいほど良いわけではないようだ。逆に小さければ小さいほど良いらしい。

http://people.apache.org/~markt/presentations/2009-04-01-TomcatTuning.pdfには以下の記述がある。大きいとGCの処理に余分に時間がかかってしまうことが原因のようだ。偉い人が書いて、apache.orgに掲載されているんだから間違いないだろう。

-Xms/-Xmx
  – Aim to set as low as possible
  – Setting too high can cause wasted memory and long GC cycles

また、http://www.coderanch.com/t/504688/java/java/Mamimum-Value-which-allowed-XMXによると、SUN JVM以外の商用JVMでは取れるだけ大きくとると恩恵を得られるとのこと。うーん、経験則に基づくものとはいえ、すばらしい情報だ。

I don’t really have a simple answer for you, but here are some things to keep in mind…

1. Never use swap for the JVM…. I repeat. NEVER use swap for the JVM. The garbage collector is the worst case scenario for swap. It touches all memory, and specifically targets the least recently used memory. The garbage collector will take hundreds, perhaps thousands, times longer to do it’s job.

2. Don’t go over 4 gb of heap for the Sun JVM. I have actually seen it as high as 9 gb, but that had dozens of gc related -XX flags, tuning it for the exact application. And even then, it would sometimes fall over during the day. The garbage collector just doesn’t behave very well at high heap sizes.

3. You can have higher heap sizes if you use the JVMs with better GC implementations — such as the newer JRockit, IBM version (whose name escapes me), the new Sun JVM (which I don’t think is out yet). These JVMs could probably give you better performance, and hence, bigger heap sizes. And of course, if you use the Azul JVM (with its pauseless GC), you can have a heap a big as you have the memory for.

As for sizing…

4. In general, the JVM will size the stack memory area to be about 1/4 the size of heap. This means, with a 4GB heap, you will need an additional 1GB for the stack area, and whatever memory needed for the JVM itself. With some JVMs, it is possible to size the stack space too.

Personally, I think it is best (if you want to use all the memory), is to simply try it, using this as an estimate. If it works, great. If it doesn’t, try a smaller heap size.

また、http://www.oracle.com/technetwork/jp/ondemand/application-grid/wls11g-pt-201107-otn-sc-439533-ja.pdfによると、xmxとxmsの値は、Long Lived Objectsのサイズの3倍程度に設定することがベストプラクティスだそうだ。

다국어 에디터 있읍니까?

흐려지기 쉬운 날씨다.

이 블로그를 쓸때 Windows에 붙어 있는 Notepad를 쓰고 있지만 Undo 처리에 불만이 있다.  Terapad란 다른 에디터도 있지만 그것은 한글 font를 표시할 수 없다.  다국어를 잘 쓸 수 있는 가벼운  에디터를 갖고 싶다.

【祝】TeraPadを語るスレpart1【ソフトウェア板】
http://pc11.2ch.net/test/read.cgi/software/1176393102/l50

231 :名無しさん@お腹いっぱい。:2009/02/11(水) 02:01:27 ID:uxQ/ZlVi0
unicodeの レ点(チェックボックス)表示はできませんか?
オプション→文字コード しても 「?」になってしまいます。

232 :名無しさん@お腹いっぱい。:2009/02/11(水) 05:00:01 ID:Ew6yCy9L0
>>231
内部処理がShift-JISですからね。

最新版のMIFES、WZ EDITORを使え。
フリーのエディタで、中国語、ハングル文字がそのまま入力できるものは少ない。
完全にUnicodeをサポートしているエディタとなると、シェアウエアや有料ソフトになるな。

意外なサイトに助けられた

明日のデモに向けて準備していたらWindowsアプリケーション内で文字が四角になる問題を発見。最初はWindowsの環境の問題だと思っていたが、調べていくうちにWindows2000でだけ発生し、Windows2003では発生しないことがわかってきた。

フォント関係の問題だということはわかっていたが、最終的な決め手となったのは、Web上のこの掲示板の情報。
http://forums.station.sony.com/eq2/posts/list.m?start=30&topic_id=343727&#3981084

調べてみたら、文字化けするダイアログはArialでフォント設定されていた。Windows 2003やXPだと問題ないんだけど2000だけで発生。

オンラインゲームの掲示板に助けられるとは。Google先生ありがとう。

Windows UpdateやらWindowsの修復やらいろいろやって大変だった。これができないとやばいのでよかったよ。

Data update frequency on major search engines

This is a report on frequency of leading search engines’ data update. 
 
I’m maintenancing my company’s official web site and  I had a chance to completely renew it  recently. 
 
Our web site had a definite defect before:  It is made as static html files which are created by Microsoft’s Front Page, so if we want to add some contents, it can affect many (some times all)  pages and it is very difficult to maintenance.
 
Therefore I decided to make use of Content Management System and tried to make it very simple.   I cusomized a CMS which utilizes database and php, take over some contents from the old web site, created some new contents and finally published them to the Internet.
 
I’m curious about how many days it will take for search engines to update their data.  After I replaced the contents,  I frequently checked some search englines if the new contents can be searchable.  The result is as bellow:
 
Yahoo!: 1day
Mooter: 1day
Google: 5days
MSN: over 7days
 
Observations:
-Yahoo! is the one on which I could find our latest contents first.
-Google bots come our web site most frequently, but it is comparatively slow reflecting their data.
-It seems that the top page is collected and reflected first and other pages are reflected at a later time.
-Old contents still remains in search results.

ブログサイトのUTF-8対応

日本の主要ブログサイトのUTF-8対応について調べてみた。
 
【エンコーディング】
ほとんどのサイトがShift_JISかEUCの日本語エンコーディングであった。そのうち、UTF-8を採用しているのはExcite, ココログ、Ameblo, Windows Live Spacesの4つのみであった。
 
【検索の妥当性について】
上記、UTF-8サポートサイトのうち、韓国語「오늘」を検索して妥当な結果が返ってきたのは、Exciteのみ。その他は、全然意味のない検索結果だった。しかも、Amebloは、検索結果ページはEUCというしょぼい仕様。
 
【インターフェースの多言語対応】
インターフェースの多言語対応については、調べなかったが、Windows Live Spacesは、ブラウザの規定言語によって、表示される言語が異なるようだ。これは、MSならではといったところか。
 
【考察】
日本を主な活動拠点とするブログサイトでは、多言語対応が進んでいない。そのなかでもExciteは、言語対応の面で他のサイトに先んじており、すばらしい。需要はあまりないかもしれないが、言語学習者にとって、多言語のブログが書けて、検索ができるというのは理想的な環境といえるので、各社の対応に期待したい。
 
【調べたサイト】
goo 
Yahoo! 
ココログ   
Windows Live Spaces  
Livedoor 
楽天  
Hatena:Diary  
excite 
ウェブリ  
So-net   
Blogzine  
AutoPage 
LOVELOG  
yaplog!   
FC2 
Seesaa  
JUGEM  
Ameba.jp