Sun Microsystem 最大の夜長
■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。
2006/10/01(日) 14:44:01秋の頃合…。
そんな季節感の経営状態だが、秋こそ、秋刀魚イクラの季節！
【前スレ】
Sun Microsystems 最大のリストラ
http://pc8.2ch.net/test/read.cgi/unix/1149485579/
0353名無しさん＠お腹いっぱい。
2006/11/03(金) 20:45:34なぜかRAC構成では性能出ないらしいのだが、HA構成で良ければT2000で十分だな。
FPUがCore毎に載って、なおかつSPUで10G EthernetをワイヤスピードでドライブするNiagara2 1.4GHzが待ち遠しい。
Niagaraの成功でSunは自信をつけている。SPARC64いらないと考えてしまっても仕方ないが、富士通がSPARC陣営から
離れかねない施策は失敗だと思うぞ。特にSPAC64Vの信頼性の高さはSunも見習って欲しいし、製造もTIじゃなくて
富士通に委託して欲しいと願う。SPARCがへたった原因の一つがTIの製造能力にあると思うから。
0354名無しさん＠お腹いっぱい。
2006/11/03(金) 21:02:55やたら高い割りにどこが高可用なの？って感じだし。
スループットにフォーカスしすぎで従来SPARCの後継に据えられない癖の強い造りになっちゃってるし。
Opteronの4コアがどんだけ速いか知らんがHPのMontecito*4鯖がOpteron8220SE*4鯖にC/Pでも絶対性能でも勝ってるし。
そもそも価格的に競合するのはItanium2なのに比較対象が何故かOpteronだし。
全体的に何が言いたいのかよくわからないが、SPARC64への愛は伝わってきたので好しとする。
0355名無しさん＠お腹いっぱい。
2006/11/03(金) 21:25:55ではintel XeonやDual Core、Opteronのそれに負けているような気がするんだけど。
TCPでもTop Ten TPC-C by Price/Performanceでは振るわない。
Itanium2はFPは速いけどINTは速くないよね。
0356名無しさん＠お腹いっぱい。
2006/11/03(金) 21:43:49>決算見る限りではNiagara全然売れてないし
1億ドルも売れれば十分じゃない？ Opteronサーバも6億ドル。
0357名無しさん＠お腹いっぱい。
2006/11/03(金) 21:48:39うひーひひひ。せっかく >>352 が警告してくれたのにww てか、本人かw?
Itanium うくくく、あれは 20 年は笑えるな。
0358名無しさん＠お腹いっぱい。
2006/11/03(金) 22:15:200359354
2006/11/03(金) 22:22:28CPU2006とかTPC-CにMontecitoのスコア来てますよ。
>>356
個人的には「たったの1億ドル？」と思った。(チラ裏
0360名無しさん＠お腹いっぱい。
2006/11/03(金) 23:17:16TPC-Hを見るとOpteronサーバに負けている。
0361名無しさん＠お腹いっぱい。
2006/11/03(金) 23:22:24X64もDual-Core、Quad-Coreと進化しているので4CPU 16Coreのラインでは
Itanium2の出る幕は無いのでは？ なぜItanium2に固執するのか良く分から
ない。公平に見てItaniumはintelの失策だと思う。最近、ようやく採算が
合うようになってきたとは言え、X64の伸張を考えると将来も怪しいのでは？
0362名無しさん＠お腹いっぱい。
2006/11/03(金) 23:22:40Sunサーバ出荷金額50億ドル
0363名無しさん＠お腹いっぱい。
2006/11/03(金) 23:25:55IntegrityはHP9000の後継シリーズ
パチョコンサーバとは求められてるものが違う
0364名無しさん＠お腹いっぱい。
2006/11/03(金) 23:50:47> ない。公平に見てItaniumはintelの失策だと思う。最近、ようやく採算が
失策どころか... Intel 以外だったら会社終わってますわ。IBM ぐらいかな、
こんなドちょんぼに耐えれるの。
で、まぁ、しがみついて墜落してくれw
0365名無しさん＠お腹いっぱい。
2006/11/03(金) 23:55:18OK.確かにItanicのintはCoreに負けている。
>Itanium2はFPは速いけどINTは速くないよね。
でもこれは語弊があるよね？OpteronやPentiumEEより速いわけだし。
それにTPC-H@3000GBはRISC勢の不戦勝ですよ。
0366名無しさん＠お腹いっぱい。
2006/11/04(土) 00:00:44x86 打ち切っちゃえよ? それがいいじゃんww?
0367名無しさん＠お腹いっぱい。
2006/11/04(土) 00:10:43Itanium2陣営においてHP-UXはそれなりの勢力を誇っているけど、
将来的にはLinuxに駆逐されるんではないのと思う？
AIXとSolarisは残るような気はしているんだが。
0368名無しさん＠お腹いっぱい。
2006/11/04(土) 00:12:540369名無しさん＠お腹いっぱい。
2006/11/04(土) 00:14:01リプレースです。
で、Itanium もうすぐ消えるので、HP-UX も消えます。
けど、完全には消えないですよ。今でも Multics や 2.11BSD が稼働してるのと同じでwww
0370名無しさん＠お腹いっぱい。
2006/11/04(土) 00:18:23このまま SPARC が弱ったままの状況が続いて、IBM が常時優位に立てればね。
それでも IBM はハードウェアで儲かるから。OS が AIX だからというシバリで
儲けてる分と天秤できるくらいのメドが立てば採用はありえると思う。
SPARC が復権して、ハードでライバルになったら、AIX のままでいくだろうね。
0371名無しさん＠お腹いっぱい。
2006/11/04(土) 00:22:18Sunのローエンドはパチョコンサーバ同等の機能と信頼性しかなかったから
いわゆる「DELLより安い！DELLより安い！DELLより安い！」
値段が同じでも負けるに決まってる
0372名無しさん＠お腹いっぱい。
2006/11/04(土) 00:24:16HP-UXは文字コードにShift_JISを使ってた記憶が。
Winで開発、HP-UXで運用みたいなときに相性がいいみたいね。
0373名無しさん＠お腹いっぱい。
2006/11/04(土) 00:28:15ｿﾗﾘﾝは Code Set Independent だよ
0374名無しさん＠お腹いっぱい。
2006/11/04(土) 00:28:19いやデフォルトがS_JISなだけ。EUCも選択できる。
0375名無しさん＠お腹いっぱい。
2006/11/04(土) 00:33:200376名無しさん＠お腹いっぱい。
2006/11/04(土) 00:34:05C 言語以前の遺物だ。
0377名無しさん＠お腹いっぱい。
2006/11/04(土) 01:01:170378名無しさん＠お腹いっぱい。
2006/11/04(土) 01:08:07Unix も昔はほとんどが Shift_JIS だったろ。NEWS とか。EUC は少数派だったはず。
0379名無しさん＠お腹いっぱい。
2006/11/04(土) 02:11:250380名無しさん＠お腹いっぱい。
2006/11/04(土) 02:36:00Solarisもそうならないようにがんばろう
0381名無しさん＠お腹いっぱい。
2006/11/04(土) 02:36:00ないでしょ?
0382名無しさん＠お腹いっぱい。
2006/11/04(土) 03:00:430383名無しさん＠お腹いっぱい。
2006/11/04(土) 03:03:18これからも当分抜かれることのない消費電力のはずなのだ。この質問のこたえなんて考えるまでもない。
けれど、Intel MultiCoreProcessorを、みんながどんなふうに感じているのか、それが探りたくてこのテーマにしたのだ。
するとあらら、不思議。寄せられたのは親Intel MultiCoreProcessorのメールばかりだった。
なぜなのかしらん？ というわけで、今回は多数を占める「Intel MultiCoreProcessorは優れた製品」派からいってみよう。
「プロセッサの消費電力の低さは、普及価格帯ですら、『望ましい』ことであって、ましてやエンスージアスト向けならば、『なすべき』ことではない」（住所不明・匿名さん）
「競合する他社製品と同等の発熱で二倍の能力があるから。」（住所不明・匿名さん）
「消費電力は低いほうがいいに決まっているが、パフォーマンスを大きくさげてまで低くする必要はない」（海外在住・匿名さん）。
「低発熱低性能なXE向け製品ならいらない。必要があれば省電力化し、なければパフォーマンスに振り分けるくらいでちょうどいい」（北海道旭川市・優子さん）。
ふー、びっくりした。でも、擁護派の意見はほぼ一点に集中している。
相対的な観点から見ると優れた製品だから、特に発熱だけを問題視する必要はないというもの。
それほんとなのかなあ。今回の答えは数字の上では「しなくていい」派が圧倒的だったけれど、
応募しなかった多数のサイレントマジョリティを考慮にいれて決定させてもらいます。
発熱は低いほうがいい、だからIntel MultiCoreProcessorは失敗作。あたりまえの話だよね。
0384名無しさん＠お腹いっぱい。
2006/11/04(土) 03:05:21C 言語普及以前の遺物って点は何もかわらないがww
MS-DOS が ME でやっと退場したのになんでまだ残ってんだろなずうずうしいwwww
0385名無しさん＠お腹いっぱい。
2006/11/04(土) 11:52:23ハイエンドは、来年に出るSPARC64のAPLでカバーするって話だったじゃん。
APLが遅れているだけで、ビジネスモデルはしっかりできてるよ。
後はストレッジとバックアップ(テープ)のとこがしっかりすれば、完璧。
0386名無しさん＠お腹いっぱい。
2006/11/04(土) 12:20:41ビジネスモデルだ何だのと表だって言うようになったら斜陽だよ。
0387名無しさん＠お腹いっぱい。
2006/11/04(土) 12:27:540388名無しさん＠お腹いっぱい。
2006/11/04(土) 13:41:24にっぽんこくの銀行とは大違いでw
0389名無しさん＠お腹いっぱい。
2006/11/04(土) 15:53:15評価を得られずに来た。T3もパートナーグループなどと言う訳の分からん仕組み
を採用したものだから、後継のT4も泣かず飛ばず。ドットヒルの3510FCに食われ
る情けなさだ。NAS市場への参入も中途半端だったので、ストレージの分野では
注目を浴びることは全く無かった。売り上げの数字がでかいので、一見すると
ストレージがんばっているじゃんと勘違いする向きも多いが、単にSunのサーバと
セットで売れただけで、ストレージを評価して購入したものではない。
StorageTek買収で、彼らの資産をうまく生かして展開していくのかなと期待
していたのだが、ロードマップを見る限り、Tape以外生かすつもり無いみたいね。
同様に買収した製品でSAM-FSやQFSと言う良い製品があるんだけど、こちらも
死んだようなもの。Sunって本当に商売下手。
Sunのサーバとストレージ、Tapeライブラリを買ってくれたら、SAM-FSもQFSも
超格安でバンドルしますくらいの手を打って欲しいものだ。
0390名無しさん＠お腹いっぱい。
2006/11/04(土) 16:38:130391名無しさん＠お腹いっぱい。
2006/11/04(土) 21:27:05なぁーに、かえって免疫がつく。
0392名無しさん＠お腹いっぱい。
2006/11/05(日) 00:31:19コンパイラによる並列化はあまり期待できない、設計は面倒、デバッグは大変だし、
開発者にとってはシングルスレッドの処理が速くなるほうがうれしいと思うのだが。
0393名無しさん＠お腹いっぱい。
2006/11/05(日) 00:56:48オーダーメイドみたいな開発なら絶望的。
0394名無しさん＠お腹いっぱい。
2006/11/05(日) 01:27:24そんな特殊なもんじゃないけど。C と Pthread でガリガリ書くのは確かに
難しいけどね。だけど必要があれば自然と出てくるもんだよ、違うものがね。
そのためのハードウェアは Niagara で提示されたわけだし。
Bill Joy はパラダイムシフトは言語から起きるだろう、ってずっと前に言ってたね。
0395名無しさん＠お腹いっぱい。
2006/11/05(日) 01:44:110396名無しさん＠お腹いっぱい。
2006/11/05(日) 02:45:02諦めたらそこで試合終了ですよ
http://journal.mycom.co.jp/articles/2006/10/12/idf1/images/Photo74l.jpg
0397名無しさん＠お腹いっぱい。
2006/11/05(日) 02:47:110398名無しさん＠お腹いっぱい。
2006/11/05(日) 03:23:140399名無しさん＠お腹いっぱい。
2006/11/05(日) 03:34:21Intelは妄想でｻｿは妄想じゃない
0400名無しさん＠お腹いっぱい。
2006/11/05(日) 03:52:57淫のは妄想で、惨のは妄想ではない
0401名無しさん＠お腹いっぱい。
2006/11/05(日) 10:25:26この驕りがNiagaraの悲惨な性能の原因なのですが。。。
0402名無しさん＠お腹いっぱい。
2006/11/05(日) 10:34:040403名無しさん＠お腹いっぱい。
2006/11/05(日) 11:00:250404名無しさん＠お腹いっぱい。
2006/11/05(日) 11:16:490405名無しさん＠お腹いっぱい。
2006/11/05(日) 14:13:330406名無しさん＠お腹いっぱい。
2006/11/05(日) 15:18:36IBMとAMDはもっと糞♪
0407名無しさん＠お腹いっぱい。
2006/11/05(日) 17:16:220408名無しさん＠お腹いっぱい。
2006/11/05(日) 18:14:14http://www.hardwarezone.com/articles/view.php?id=2102&cid=2&pg=4
Opteronサーバー死んだな…
Clovertown 1.60GHz $455*2 >>> Opteron 2220 SE $786*2
Clovertown 2.33GHz $851*2 >>> Opteron 8220 SE $2149*4
0409名無しさん＠お腹いっぱい。
2006/11/05(日) 18:21:330410名無しさん＠お腹いっぱい。
2006/11/05(日) 19:13:18影のボスはFASL LLCの非公開部門ですｗ
0411名無しさん＠お腹いっぱい。
2006/11/05(日) 19:13:51堅実なアーキテクチャを選ばなくてもやっていける余裕があった
ということなのだと思う。
シェアNo.1なのだから、積極的にブレークスルーにチャレンジする責任があるわけで。
AMDに追い上げられた結果、インテルは余裕かましていられなくなって、
堅実なアーキテクチャを選択して引き離しにかかる、と。
ある程度距離が取れたら、また、堅実ではないアーキテクチャに移行すると思われ。
0412名無しさん＠お腹いっぱい。
2006/11/05(日) 19:19:00シェアを持っていたから、クロック神話から抜け出せなかっただけ。
0413名無しさん＠お腹いっぱい。
2006/11/05(日) 19:20:46前回の似非デュアルのときと状況が違うのは、Core2がそれなりに優れているってだけだな。
0414名無しさん＠お腹いっぱい。
2006/11/05(日) 19:46:12これさ、Win XP x64 Edition を使ってないって事は 32bit でテストしてるんだよね。
Core MA は 64bit だと性能出ないって話だけど（AMD は 64bit の方が速い）、
そこら辺どうなの?
0415名無しさん＠お腹いっぱい。
2006/11/05(日) 22:23:24これ聞く場所間違えると激しく罵倒される質問だから注意。
スレ荒らすための煽りレスとかに使っちゃ駄目だからね？
絶対だぞ。
閑話休題。IA32eだと性能は10%程度「しか」向上しないよ。
ベンチによっては30%以上ブーストするNetburstがどう見ても最強です。
絶対性能では勝てないんだけどね。
0416名無しさん＠お腹いっぱい。
2006/11/05(日) 22:27:38日本語でおk
0417名無しさん＠お腹いっぱい。
2006/11/05(日) 22:33:41だが断る(えげれす語)
http://www.xbitlabs.com/articles/cpu/display/core2duo-64bit.html
0418名無しさん＠お腹いっぱい。
2006/11/05(日) 23:08:24FP と SIMD が速いのは（どうでも）いいんだけど、サーバ用途なら整数演算、マルチスレッド性能、
メモりアクセス性能のベンチは無いの?
そこにも書いてあるけど、EM64T で Macro-Fusion が無いのと LCP の問題がどれだけ性能に
影響するのか知りたい。
0419名無しさん＠お腹いっぱい。
2006/11/06(月) 08:01:460420名無しさん＠お腹いっぱい。
2006/11/06(月) 11:29:36Itanium系はLinuxが多いだろうし、PA系は縮退しているから・・・減る。
ただし、Itanuim系でもHAを考慮したものなら、HP-UXは以前、残るでしょう。
HP-UXの利点としては、LVMがLinuxのLVMと仕様互換なので、汎用性は高い。
SolarisのSVMと比較して、IBM/HPのLVMはEnterprise Volume Management System
との親和性も高いので、乗り換え易い。
VxVMの真の機能は、HP-UXに実装したものなので。
中規模以上のシステムを考慮した場合、HP－UXはまだまだ残る。
大規模：AIXかHP-UX
中規模：AIX/HP-UX/Linux/Solaris
小規模：Solaris/Linux
中規模以上において、次期LVMとしてのEVMSの使用を考慮するなら、
Solarisは使っちゃいけない。
0421名無しさん＠お腹いっぱい。
2006/11/06(月) 12:59:28ところで、CPUキャッシュのサイズが数十～数百Kのコアを並べて、そこに載るプログラム
って一体・・・
現実、JVM上のスレッドは載るとしても、そこにデプロイされて動作するアプリのデータ構造
や実際のプログラムのサイズを考えれば、SUNが主張するほど効率よく動けない。
実際にある程度のキャッシュサイズを持った上、個々のシングルスレッド処理能力もまとも
でないと、各スレッド間の調整やらも含め、オーバヘッドが大きいんじゃないのかな？！
まともなコア(Power4レベル）のマルチコアチップが出てくるまで、多くのユーザは様子見。
で、SUNにはまともなコアが無いので・・・・終わってるって結論でおｋ？？
0422名無しさん＠お腹いっぱい。
2006/11/06(月) 13:00:320423名無しさん＠お腹いっぱい。
2006/11/06(月) 13:06:10SUNのSPECによる見積もりツールの精度の荒さを見れば、誰も信じなくなるわな。
Oracleの性能をSPECで見積もったシステムを知っているが、悲惨。
SUNがSPECしかベンチマークを出さない（出せない）から、余計、信用が・・・・
OASとかでも、SPEC見積もりツールをOracleコンサルが全否定してるしな。
SUNユーザの前でHPならこう見積もるって力説してたから。
少々、CPUが遅くても、まともな見積もりが出せるような基準をSUN営業が用意しないと
商売にならないよな。
ま、まともな見積もりツールで見積もったら、HP/IBMとかのサーバ台数と勝負できない
のがモロバレで余計まずいのか！？
0424名無しさん＠お腹いっぱい。
2006/11/06(月) 13:13:03特にミラーリングのところ。
LV単位でのミラーリングってアホですか？なんでいちいちPVとLVの位置関係を確認せんといかんｗ
その点はVxVMやZFSの場合は、ディスクボリューム（ディスクグループやプール）に対してミラーなりストライプなりを指定するから、
物理デバイスの配置はよきに計らってくれる。
0425名無しさん＠お腹いっぱい。
2006/11/06(月) 13:54:11しかも、LVMを使ったミラーの場合、VG単位でミラー化するのが普通。
#RAID１なんかは玉単位だろ。
逆にストライプ単位の設定の方が訳判らん。
エンタープライズ環境では、PV単位(玉）で考えるだろ。
ストライプとかLV単位でミラーなんて、せこい事はしないよ。
0426名無しさん＠お腹いっぱい。
2006/11/06(月) 14:00:110427名無しさん＠お腹いっぱい。
2006/11/06(月) 14:05:25CTCか新日鉄あたり？
0428名無しさん＠お腹いっぱい。
2006/11/06(月) 14:24:35＞VG単位でミラー化するのが普通。
コマンドわからん。そんなのあったっけ？
通常ミラーリングするときって、lvextend -mじゃないの？
当然、このコマンドで実行すると、同じPV上にあるLV同士でもミラーリング出来てしまうから、
レイアウトを意識する必要がある。
ミラーリングに関しては、SDSやVxVMの方が圧倒的に使いやすいしわかりやすい。
0429名無しさん＠お腹いっぱい。
2006/11/06(月) 14:45:28LinuxのLVM1&2及びAIXのLVMではLVMでミラー化できまする。
んで、HP-UXなら”無い”。
管理考えるならVxVMだろうね。
LVMなんて、あと2年の命なんだから。
EVMSに置き換わって、終わりですよ。
0430名無しさん＠お腹いっぱい。
2006/11/06(月) 16:14:25俺が使いやすいからこれにしたい、って言うなら、そうですか、って感じなんだけど。
0431名無しさん＠お腹いっぱい。
2006/11/06(月) 16:35:42ただし、エンタープライズの分野なら信頼性のある、且つ、汎用性の高い
VMを選択すべき。
なぜなら、それを”自分”や部下が設定・メンテするとは限らないから。
外注や他社のエンジニアが行う可能性が高いんですから。
そういう点を考慮して、OSってのは選ぶべきですね。
0432名無しさん＠お腹いっぱい。
2006/11/06(月) 17:08:50全てのOSでVxVM/FSに統一すれば読めるけど。
結局WindowsサーバはEVMSになんか対応するはず無いので、あまり意味なし。
イメージレベルでバックアップやスナップショットくらいなら取れるんだろうけど、
そんなのストレージレベルでも出来るしな。
あくまで、非機能要件のひとつに過ぎないから、アプリケーションやミドルの要件より優先度は低いしな。
0433名無しさん＠お腹いっぱい。
2006/11/06(月) 18:03:11いや、VMの抽象化概念すら違う（SVM）ものがあると、そのための
概念から揃えるのが大変。
ヘテロジニアスな環境で、膨大なデータを相手にするようなシステムだと
当然、VMの選択=OSの選択となる。
DWH系なんかは、VMの比重も大きいよ。
0434名無しさん＠お腹いっぱい。
2006/11/06(月) 21:36:20今のCPUはISAやアーキ以前に、キャッシュとメモリシステムの実装で性能が決まるんだろ？
まともなコアとか、いってんのはキャッシュ、メモリシステムのことかい？
0435名無しさん＠お腹いっぱい。
2006/11/06(月) 22:55:22そらまたごたいそうなことで。Multics みたいな状況ですか?
0436名無しさん＠お腹いっぱい。
2006/11/06(月) 22:58:430437名無しさん＠お腹いっぱい。
2006/11/06(月) 23:48:360438名無しさん＠お腹いっぱい。
2006/11/06(月) 23:52:19次期versionで待望のdual parity、hot spareがサポート。記憶が怪しいが
SunClusterの共有diskとしても使えるようになるんじゃなかったかな？
system disk(root filesystem)対応も近いと聞いている。
0439名無しさん＠お腹いっぱい。
2006/11/06(月) 23:56:300440名無しさん＠お腹いっぱい。
2006/11/07(火) 01:17:35Sun営業は予定の技術ばかり売り物にする
0441名無しさん＠お腹いっぱい。
2006/11/07(火) 01:26:260442名無しさん＠お腹いっぱい。
2006/11/07(火) 01:37:13今は違って、ずいぶん優秀になったんだね。
PA-RISC のバイナリはアホみたいに巨大だった（で、起動に時間がかかった）。
0443名無しさん＠お腹いっぱい。
2006/11/07(火) 02:05:360444名無しさん＠お腹いっぱい。
2006/11/07(火) 02:29:500445名無しさん＠お腹いっぱい。
2006/11/07(火) 03:54:01LCPってx86の盲腸だよね。
性能出す必要あるの?
IntelのCPUはx87も遅いし、必要ないところはばっさり切り捨ててるだけでは。
0446名無しさん＠お腹いっぱい。
2006/11/07(火) 07:12:040447名無しさん＠お腹いっぱい。
2006/11/07(火) 07:56:371. 16bitコードは動かない(LCP使われない)
2. x87は傍系(SSEが主流)
http://www.intel.co.jp/jp/developer/technology/magazine/computing/Core-programming-0606.htm
0448名無しさん＠お腹いっぱい。
2006/11/07(火) 12:39:27x86_64ではREXバイトが追加され拡張されたレジスタにアクセスする場合や
オペランドが64bitの場合には必ず使用される
REXバイトがあるとCoreMAの実行速度は遅くなる
0449名無しさん＠お腹いっぱい。
2006/11/07(火) 13:19:470450名無しさん＠お腹いっぱい。
2006/11/07(火) 14:28:22SUN儲にはSUNClusterがあればなにもいらないとさ。
0451名無しさん＠お腹いっぱい。
2006/11/07(火) 14:29:53普通のユーザにおいて、SUNは選択肢から除外されてるし。
0452名無しさん＠お腹いっぱい。
2006/11/07(火) 21:00:41REXとLCPは別物だがこれらの前置バイトが付いてるとCoreMAでは遅くなるというのは同じ
だからCoreMAでは64bitモードで遅くなる
REX前置バイトは拡張されたレジスタへのアクセスが発生する命令や
オペランドサイズが64bitの命令には必ず付く前置バイト
64bitモードでは多用される前置バイトが付くと遅くなるのは致命的
パソコン用途では64bitモードはまだほとんど使われてないが
サーバー用途では今後ますます64bitモードでの動作が重要になるはず
■ このスレッドは過去ログ倉庫に格納されています