トップページ⇒unix
1001コメント309KB

Sun Microsystems 最大の敵はItanium

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。2006/02/26(日) 01:49:21
まだまだ続く、痛厨との攻防

【前スレ】
Sun Microsystems 最大の滝壷
http://pc8.2ch.net/test/read.cgi/unix/1138786320/
0156名無しさん＠お腹いっぱい。2006/03/12(日) 17:07:55
>>155
コア数が同じでも、CMP の方が速いという事を書いたんだが。
なんちゃってヅアルだとあまり変わらないけどね。
0157名無しさん＠お腹いっぱい。2006/03/12(日) 20:50:55
>>156
だったら、そう書けば良かったのに。

しかし、性能向上分のどれだけがCMPによるもので、どれだけがCGMTによるものなのかな。
0158名無しさん＠お腹いっぱい。2006/03/12(日) 21:04:07
>>153

AMD Opteron 4CPUの方が、236,054 tpmCで速いぞ。
AMD 4coreが出たら、圧勝っぽい。


0159名無しさん＠お腹いっぱい。2006/03/12(日) 21:06:47
価格性能比も、
Montecito $3.25 US / tpmCに対して、
AMD Opteron $2.02 US / tmpCとなってる。
0160名無しさん＠お腹いっぱい。2006/03/12(日) 22:09:37
Montecito って、1.6GHz なの?
0161名無しさん＠お腹いっぱい。2006/03/12(日) 23:51:54
>>160
TDPが若干下がってるからな
0162名無しさん＠お腹いっぱい。2006/03/13(月) 00:27:50
>>158

http://www.tpc.org/tpcc/results/tpcc_result_detail.asp?id=105120501
これかな？
Opteron 2.4DC GHｚ
4Processors/8Cores/8Threads ってなってるぞ。
0163名無しさん＠お腹いっぱい。2006/03/13(月) 00:57:32
Montecitoの2CPUとOpteronの4CPUの比較か。
CPUが少なくても、トータルのコストが高いんじゃぁ・・・。
0164名無しさん＠お腹いっぱい。2006/03/13(月) 01:21:11
そのあたりのクラスだと確かに高コストは売れない要因。
なんでもっと CPU 数の多いのでやらないんだろ。どうせ HP-UX なんだし。
0165名無しさん＠お腹いっぱい。2006/03/14(火) 05:36:44
CPUにまだエラッタがあるんじゃねーの
0166名無しさん＠お腹いっぱい。2006/03/14(火) 20:36:25
やっぱり、「最大の敵はPower」じゃないのかな？
0167名無しさん＠お腹いっぱい。2006/03/15(水) 00:08:38
Intel が Pen-M 系でつまずいたらそうなる。Intel は最近のどんくささからいくと
Pen-M 系でもつまずく可能性は大。それに引き換え、POWER には弱点がない。やぱつおい。
0168名無しさん＠お腹いっぱい。2006/03/15(水) 12:29:45
というか、IBMはもともとIntelなんてめじゃないだろう？
Sun v.s. Intelはあっても、IBMは余裕。
Xeon, Opteronを使っても、一番はPowerという絶対の自信。
Cellのブレードサーバもあるし。
0169名無しさん＠お腹いっぱい。2006/03/15(水) 12:39:12
一番はメインフレームじゃないの
0170名無しさん＠お腹いっぱい。2006/03/15(水) 13:43:25
今全部 POWER だつーの。zSeries も。
0171名無しさん＠お腹いっぱい。2006/03/15(水) 16:50:54
IBM の z は POWER で、NEC の ACOS は Itanium になったわけだが、
富士通の汎用機起源 SPARC64 は、やっぱ GS（だっけ?）への搭載をにらんだ作りに
なってるのかな?
0172名無しさん＠お腹いっぱい。2006/03/15(水) 19:09:19
自意識過剰なSun厨大杉。
0173名無しさん＠お腹いっぱい。2006/03/15(水) 21:07:00
>>172

IBM厨の間違いだろう？
0174名無しさん＠お腹いっぱい。2006/03/15(水) 22:14:49
>>171
Powerなのは、旧AS/400のiSeries
zSeriesは、今も独自CISC
0175名無しさん＠お腹いっぱい。2006/03/15(水) 22:25:31
だよねぇ
0176名無しさん＠お腹いっぱい。2006/03/16(木) 14:02:42
そうなのか。>>170 は撤回。失礼すた。
0177名無しさん＠お腹いっぱい。2006/03/16(木) 21:27:08
次のインテルのプロセッサはかなり高性能らしいじゃん。
AMDは4年ぶりにまた暗黒時代に突入ですか。
0178名無しさん＠お腹いっぱい。2006/03/16(木) 22:43:08
AMD64でインテルのメンツを潰したから、ヤバいな。
0179名無しさん＠お腹いっぱい。2006/03/16(木) 23:11:58
ヒータとしての性能がすごくても… ねえ?
0180名無しさん＠お腹いっぱい。2006/03/16(木) 23:21:15
いや焜炉だし
0181名無しさん＠お腹いっぱい。2006/03/19(日) 02:02:22
montecito, montvalは出る前から終わってる。
こうなったらtukiwlaでHyperTransportの真似ごとして挽回するしか
ないというのがIntelの本うわなにするｎ....
0182名無しさん＠お腹いっぱい。2006/03/19(日) 02:45:27
Xeon LV (Sossaman) ってそこそこの性能の割には低消費電力で、なかなかやるじゃん、って
思ってたら、なななななんとと、32bit なのね。こんなもん出さなあかんちゅうのは、
やっぱ相当追い詰められてるで。終わるかもね。32bit って、ああた、いまどきサーバー用で 32bit...
0183名無しさん＠お腹いっぱい。2006/03/19(日) 03:11:30
ノートPC用のCPUを使った高密度サーバ向けでしょ?
0184名無しさん＠お腹いっぱい。2006/03/19(日) 03:16:19
IntelとしてはXeon DP Low-Power Platform用の製品でカテゴリ違いということになるんだろうけど
やっつけ仕事に見えるよね…
0185名無しさん＠お腹いっぱい。2006/03/19(日) 13:06:08
32bitでもとりあえず大抵のニーズには合うんじゃないの。
そのうち64bit版が出てくるだろうし。
0186名無しさん＠お腹いっぱい。2006/03/19(日) 13:44:07
Woodcrestが本命だけどBensleyプラットフォームに変更され
メモリもFB-DIMMに、チップセットがBlackfordに変更になるようだしね
SossamanはLindenhurstのままでいけたけど
0187名無しさん＠お腹いっぱい2006/03/19(日) 21:03:32
>>182
俺も最初はそうおもったが、まだまだEM64Tが必須の64bitアプリなんて無い
のだから32bitcpuで十分。EM64T用の solarisだってlinuxだって一部のヲタ
が騒いでいるだけにすぎない。商売には関係なし。もっともwindows vista
がでるタイミングでこんなことをするのだから、intelにはEM64Tからふたたび
IA64の路線に切り替える重大決意があるのかもしれないが。
0188名無しさん＠お腹いっぱい。2006/03/19(日) 21:18:51
単にコアの開発が遅れただけだっての
0189名無しさん＠お腹いっぱい。2006/03/19(日) 23:17:46
CPUコアの開発には何年もかかるから、
AMD64対抗で開発していたものをお蔵入りにしてAMD64を採用する
という決定を下してからも、
続々と日の目をみなかった64ビット拡張を積みつつ、それを無効にしたCPUが登場するわけですよ。

Pentium4が素早く対応したので、簡単に見えるけど、そんなことはない。
あれは、AMD64命令を内部命令に変換する部分だけを変更したもので、
AMD64命令を実行できるというだけであって、パフォーマンスは悪い。
0190名無しさん＠お腹いっぱい。2006/03/20(月) 00:54:31
>>187
> EM64T用の solarisだってlinuxだって一部のヲタが騒いでいるだけにすぎない。商売には関係なし。

これは聞き捨てならないな。
64bitのSPARC/Solarisからの移行はAMD64/Linuxが出てやっと現実になった。
いまさら32bitなんてメモリ空間の制限厳しすぎて使ってらんねーよ。
0191名無しさん＠お腹いっぱい。2006/03/20(月) 04:40:03
フローティングのレジスタが増えているのもAMD64/EM64Tの大きなメリットだよ。
メモリが小さい場合でもAMD64/EM64Tの恩恵がある。
0192名無しさん＠お腹いっぱい。2006/03/20(月) 08:40:59
いやいや、そんなことよりなによりも、メモリの搭載量がじきに天井到達でっせ。
4GB 超はまたセグメントみたいなことやらないといかんのだから。
0193名無しさん＠お腹いっぱい。2006/03/20(月) 08:41:43
>>187
> がでるタイミングでこんなことをするのだから、intelにはEM64Tからふたたび
> IA64の路線に切り替える重大決意があるのかもしれないが。
ひどい飛躍と妄想。
0194名無しさん＠お腹いっぱい。2006/03/20(月) 17:58:22
SPARCからAMD64にポーティングするのって楽だよね。
うちも手元で開発→本番機(SPARC)って流れがずいぶんやりやすくなったよ。

0195名無しさん＠お腹いっぱい。2006/03/20(月) 21:36:46
>>192
ど素人さん、おぷてろんの物理アドレスのビット数を知ってる？
>> 4GB 超はまたセグメントみたいなことやらないといかんのだから。
0196名無しさん＠お腹いっぱい。2006/03/20(月) 22:01:15
xeon lv機は、メモリを12GBしか積めない方
32bitで十分だろ
ところで、yonahってPAE(32bitでメモリ32GBまで拡張)
ついてたんだな、以外
0197名無しさん＠お腹いっぱい。2006/03/20(月) 22:12:24
Itanium2は44bit-16TBですが何か。
0198名無しさん＠お腹いっぱい。2006/03/20(月) 23:05:15
>>197
呼んでない。
0199名無しさん＠お腹いっぱい。2006/03/21(火) 02:31:20
いまどきPAEがないx86ってあるの？
0200名無しさん＠お腹いっぱい。2006/03/21(火) 10:57:54
企業や大学だと64bit鯖が無いと話にならんが、お宅のDesktopマシンはまだ32bitで十分だよな。
0201名無しさん＠お腹いっぱい。2006/03/21(火) 15:01:42
> 企業や大学だと64bit鯖が無いと話にならんが、
んなこたーない
0202名無しさん＠お腹いっぱい。2006/03/21(火) 16:03:22
数値計算するのに32bitプロセッサと64bitプロセッサで精度違わないの？
どなたか、

IA32
IA64
AMD64==EM64T
SPARC V9

のlong doubleの精度教えてください。
0203名無しさん＠お腹いっぱい。2006/03/21(火) 16:07:04
>>202
お前は基本的なところを勉強してから出直したほうがいい
0204名無しさん＠お腹いっぱい。2006/03/21(火) 20:37:46
IA-32は、積和算命令を持たないから
積和算命令を持つRISCと、誤差が変わるな
ちなみに、同じIA-32同士でも、xeonとopteronじゃ
精度が違う
グラフィックスだと同じアプリでも、xeonとopteronじゃ微妙に
色が違ったりするそうだ
0205名無しさん＠お腹いっぱい。2006/03/21(火) 22:54:22
>>202
IA32とSPARCの比較ならここにあるけど。
ttp://jp.sun.com/products/software/solaris/wp/Solaris_x86/chap3.html

x86(IA32)が12bytes = 96bit
SPARCが16bytes = 128bit
0206名無しさん＠お腹いっぱい。2006/03/22(水) 01:06:04
96bitってｗ
x87の拡張倍精度の80bitに
16bitパディングして、32bitアラインしてるのかな？
0207名無しさん＠お腹いっぱい。2006/03/22(水) 01:10:56
PAEあっても、1プロセスあたりが使えるメモリの量は変わらないよね?

AMD64では、long doubleは16byte。
Solaris x64って、64bitバイナリでもFPUを普通に使えるんですかね?
SSE2って64bitしか使えないと思うんだけど、
どうやって拡張精度(80から128bit)を実現するのかな。
0208名無しさん＠お腹いっぱい。2006/03/22(水) 09:19:35
Ｃ言語の仕様とアーキ仕様とＣＰＵの仕様は別だっつの
0209名無しさん＠お腹いっぱい。2006/03/22(水) 13:16:00
なんで PAE みたいな汚くて後に禍根を残すような付け焼き刃をあんなに平気でやるんだか
さっぱり理解できん。バランス感覚のないデザイン。
0210名無しさん＠お腹いっぱい。2006/03/22(水) 13:56:16
>>209

そもそも、Intel X86のデザインって、めちゃくちゃじゃない？
Intelはデザインなんて考えてないよ。

デザインでいったら、AMD64の方がメチャ綺麗。
0211名無しさん＠お腹いっぱい。2006/03/22(水) 19:13:42
もともと386の設計は酷すぎるよね
レジスタの値１つ変更するだけでレジスタの退避など全自動でタスクスイッチの処理をしてくれるようなCPU他にあるのか？
0212名無しさん＠お腹いっぱい。2006/03/22(水) 19:16:14
>>210
AMD厨は、こんなところにまで・・・

>>207
64ビットあれば十分で、コストをかけてまで拡張精度を用意する必要はない
という割り切りをしているんだろうね。


PAEについては、一部の例外的にメモリを多量に使うアプリのためのもので、
たとえば、DBMSのように、メモリアクセスにオーバーヘッドがあろうとも、
HDDにアクセスに行くよりは桁違いにマシ、という用途で使うことを想定してる。
0213名無しさん＠お腹いっぱい。2006/03/22(水) 19:25:57
Intel の苦しい苦しい悲しくなるような言い訳を真に受けてるやつもいるんだな...
0214名無しさん＠お腹いっぱい。2006/03/22(水) 22:55:59
>>208
じゃあさ、CPUの仕様の違いを教えてよ。
みんな分かってるようであんまり良く分かってないんで無いの？
画像のエンコードとかやるならSS2の精度で十分だけどまともな数値計算するなら64bitじゃお話にならないし、
ソフトで他倍長計算するのってなんかやだ。
02152142006/03/22(水) 22:57:02
×他倍長計算
○多倍長計算
0216名無しさん＠お腹いっぱい。2006/03/22(水) 23:01:04
多倍長計算でよく使われるのってナンbitなの?
全然知らんｗ
よく使われる精度が決まってないのなら、ソフトで実装するしかないのでは
0217名無しさん＠お腹いっぱい。2006/03/22(水) 23:23:20
>>216
多く使われるといえばIEEE754の倍精度(64bit)か拡張倍精度(80bit)なんじゃない？IA32でサポートしてるし。
でもSPARCやAlphaの4倍精度(128bit)で作ったプログラムを移植しようとしたらIA32じゃつらいよね。
IA64なら問題無いと思うけど、SSE2を推奨するx64はどうなんだろ？
0218名無しさん＠お腹いっぱい。2006/03/23(木) 07:46:11
>>207
めんどくさい手法で4GB以上使えると聞く。
どっかのDBが利用してるらしい。
0219名無しさん＠お腹いっぱい。2006/03/23(木) 07:59:28
IEEE754が4倍精度を定義しなかったのが悪い
もう、二十年来の不満だよｗ
0220名無しさん＠お腹いっぱい。2006/03/23(木) 09:26:50
>>218
SQLServerだっけ
0221名無しさん＠お腹いっぱい。2006/03/23(木) 10:29:04
Oracleモナー
0222名無しさん＠お腹いっぱい。2006/03/23(木) 21:50:08
solaris 11 amd64のgcc 3.4.3で
long double a, b, c;
c = a*b;
をコンパイルしたらこうなった

fldt -16(%rbp)
fldt -32(%rbp)
fmulp %st, %st(1)
fstpt -48(%rbp)
0223名無しさん＠お腹いっぱい。2006/03/24(金) 15:13:09
>>222
long doubleをdoubleにすると、xmm使うみたいですね。
gcc-4.1 amd64
デフォルト(-mfpmath=sse)
movlpd -24(%rbp), %xmm0
mulsd -16(%rbp), %xmm0
movsd %xmm0, -8(%rbp)
-mfpmath=387
fldl -24(%rbp)
fmull -16(%rbp)
fstpl -8(%rbp)

long doubleは必ずFPU使うのか。
0224名無しさん＠お腹いっぱい。2006/03/24(金) 18:55:48
Sun’s T2000 “Coolthreads” Server: First Impressions and Experiences
http://www.anandtech.com/systems/showdoc.aspx?i=2727

Niagaraｼﾎﾞﾝﾇ?
0225ありがとう2006/03/24(金) 21:31:27
UNIXの人々達本当にありがとうそしてこれからも僕らの２ｃｈねるを
守ってください、本当にありがとうよかった・・・・・・
0226名無しさん＠お腹いっぱい。2006/03/24(金) 22:24:19
Japanese consortium rumoured to buy Intel Itanium

http://www.theinquirer.net/?article=30514
0227名無しさん＠お腹いっぱい。2006/03/25(土) 20:16:05
ひとまず、Niagaraは成功っぽいね。
0228名無しさん＠お腹いっぱい。2006/03/25(土) 20:29:37
('A`)えぇェ〜
0229名無しさん＠お腹いっぱい。2006/03/25(土) 20:32:38
>>228

残念でした。Sun復活でつ。。。。
0230名無しさん＠お腹いっぱい。2006/03/26(日) 14:37:44
>>226
結局、痛 やってるのは日本の会社だけだから
インテルから切り離しちゃうんでしょ？ｗ
0231名無しさん＠お腹いっぱい。2006/03/26(日) 17:04:40
>>230
そりゃこのスレ的には『HP-UXを使ってるユーザなんて無視』でもいいけど
現実にはどうしても痛を使いたいユーザのほどんどはHP-UXだろ
WindowsとかLinuxを使っているならx64に移れば桶だし
本当にエンタープライズシステムクォリティが必要なら
POWERに移ればいいのだから
だから痛を日本のメーカーがコントロールするようになっちゃうと
HPが黙っていないだろ
0232名無しさん＠お腹いっぱい。2006/03/26(日) 18:20:01
> 現実にはどうしても痛を使いたいユーザのほどんどはHP-UXだろ

これだけで、Itaniumの数は伸びない...って感じがする。
HP-UXでも、PAからItaniumに移行しないで、IBM, Sunに移行していく
ユーザっていそうだし。PAユーザってまだ相当いそうだし。

HPがPAを止めたのは完全に失敗だったね。
0233名無しさん＠お腹いっぱい。2006/03/26(日) 21:13:42
ITバブルがはじけずにサーバーの出荷台数や出荷額の増加が続いていれば移行には成功したんだろうね
Itaniumは技術的にもマーケティング的にもどう考えてもすべて90年代の発想です
0234名無しさん＠お腹いっぱい。2006/03/26(日) 21:15:38
>>232
hpは何やってもダメでしょ。必要ない。
0235名無しさん＠お腹いっぱい。2006/03/26(日) 21:25:01
Sparkはいつもネタ切れだな。
0236名無しさん＠お腹いっぱい。2006/03/26(日) 21:32:29
HPってIntelにもAMDにも良い顔してて最終的にどっちからも蹴落とされるタイプ。
0237名無しさん＠お腹いっぱい。2006/03/26(日) 21:42:07
AlphaとPAとx86で頑張れば良かったのに。
0238名無しさん＠お腹いっぱい。2006/03/26(日) 21:47:12
PAとHP-UXは捨ててAlphaとTru64 Unix残せば良かったのに。
0239名無しさん＠お腹いっぱい。2006/03/26(日) 21:48:22
Alphaは合併前にCompaqが技術者とコンパイラごとIntelに
売り払っちまったんでないの？
0240名無しさん＠お腹いっぱい。2006/03/26(日) 21:57:14
>>239

Alphaの技術はXeonの方にいっちゃったけど、CPUを使ったホストは
CompaqからHPへ。で、マシンが残っている以上、サポートしないといけないし。

そうなると、HPって、いつまでもAlphaとPA, VAXをサポートしていくのね。
Itaniumへの移行をすすめつつ。まぁ途中でサポートを切るんだろうけど、
今の感じだと、Itaniumへ移行すると、今度はItaniumのサポートが早々
うち切られそうな状況なので、Itaniumを使ったホストへの移行が進みそうにないね。

0241名無しさん＠お腹いっぱい。2006/03/26(日) 22:05:16
Sparkのネタは無いけど、
http://www.asahi.com/politics/update/0326/004.html

> 総務省によると、文部科学省以外の電子申請にはパソコンにあらかじめ、米サン・マイクロシステムズ社のＪＲＥというプログラムを導入する必要がある。パソコンの基本ソフトであるＯＳが違っても申請のための操作を可能にするためだ。
>
> しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によってバージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。

確かにありがち！
0242名無しさん＠お腹いっぱい。2006/03/26(日) 22:11:45
> 総務省によると、文部科学省以外の電子申請には...

この、「文部科学省以外の電子申請には...」って何？
全省庁、Javaで統一しろよ。そういうことしてるから、税金が無駄に使われる。
文部科学省も、Javaを使えよ。
0243名無しさん＠お腹いっぱい。2006/03/26(日) 22:15:03
> しかし、ＪＲＥは随時、バージョンアップされており、各省庁の申請の種類によってバージョンがばらばらになっている。総務省によると、新版を入れたパソコンは旧版対応の申請ができないことが多く、旧版を入れたパソコンは新版対応の申請が難しくなるという。

これって、具体的にどういうこと？

新版で動く ==> 旧版で動かない　っていうのは、アプリが新版で導入された新しい
インタフェース、関数を使っていて、旧版ではその呼び出しができないっていう
ことかなって思うけど、

旧版で動く ==> 新版で動かない　っていうのは、どういう場合？
アプリが新版で廃止になるdeprecateな関数呼び出しを使っているってこと？
（つまりバグ？）

0244名無しさん＠お腹いっぱい。2006/03/26(日) 22:32:24
> 旧版で動く ==> 新版で動かない　っていうのは、どういう場合？


確かに基本的にはあり得そうもないが...
0245名無しさん＠お腹いっぱい。2006/03/26(日) 22:35:02
>>243
オレの経験上では、旧版でセキュリティ的にめちゃくちゃなことやってて、
新版では手動で JVM の設定緩めないと動かなくなって、全クライアント（Web ブラウザ）機で
そんなことやってらんない、ってやつ。JRE のせいにするか普通? って思うけど。
0246名無しさん＠お腹いっぱい。2006/03/26(日) 22:47:46
>>245

そういうのは、アプリの問題で、全然Javaの問題じゃないよね。

そもそも、コーディングの仕方を知らないって言うレベルで、発注先を変えた方が
いいかも。
0247名無しさん＠お腹いっぱい。2006/03/26(日) 22:53:14
でもさ、>>245 はごく大手の、自治体向けのパッケージの話よ。都道府県向けだけどね。
全国あちこちで導入されてる。
0248名無しさん＠お腹いっぱい。2006/03/26(日) 22:55:10
>>247

官庁関係の開発って、孫外注、曾孫外注の開発で、最後は相当スキルの低いとこが
コーディングしてる例って結構あるよ。

0249名無しさん＠お腹いっぱい。2006/03/26(日) 22:57:13
Javaの場合、ネット経由で起動した時にどの位のパフォーマンスがあるかを
調べると、開発元のスキルがみえてくるよ。

スキルがないとこが開発すると、遅いのですぐ分かる。
0250名無しさん＠お腹いっぱい。2006/03/26(日) 23:04:01
>>248
うーん、でも、末端のコーディングとかの問題じゃなくて、アプレットのレイアウトとか
アプリ構成の大枠の話だったりするし、内製だったと思うけど。メンテでその大手企業の
社員さんが来てたから。
スキルとかいうより、セキュリティ感覚というか、文化というか、そういう問題と
思った。その件に関しては。
でも、外ヅラ的には客には Java の互換性問題に見えるし、その大手企業も Java のせいに
してたし、適用やってた作業者も Java に文句たれてたよ。ひどい話だけど。
0251名無しさん＠お腹いっぱい。2006/03/26(日) 23:16:43
> でも、外ヅラ的には客には Java の互換性問題に見えるし、その大手企業も Java のせいにしてたし、適用やってた作業者も Java に文句たれてたよ。ひどい話だけど。

JavaはObj指向のデザイン、コーディングが必要な上に、セキュリティモデルを最初から
設計に入れて、仕様を決めていく必要がある。その上、ネットで展開する場合は、
パフォーマンスを考慮して、詳細仕様を詰めていく必要があるので、それなりの
スキルがないと、ちゃんとしたアプリは開発できないと思うよ。

上の話をみると、請け負った大手コンピュータ？会社側にJavaでアプリを開発する
スキルがなかったということだと思う。

日本でちゃんとJavaでアプリを組めるとこって、まだあんまりないのかもね。
Javaが出てきて10年以上たつのに、何のスキルもつけてこなかったってこと？

海外じゃ、相当量の開発が行われているのに。source forgeでは、C++のプロジェクト
数をJavaが抜いたらしいし。
0252名無しさん＠お腹いっぱい。2006/03/26(日) 23:40:33
電子申請に必要なJavaアプレットなりJavaアプリケーションはそんなに複雑なプログラムでもないだろ
単純にSwingのプログラミング方法をしらないだけじゃない？
確かに、日本語の書籍を見てもSwingの解説を丁寧にしてるJavaの書籍はここ2年くらい前以降に出た
比較的新しい本ばかりだし種類も少ないし情報不足というのもあるんじゃない？
スキルの無い開発者なんて市販の日本語のJavaの書籍で勉強してそうだからな
0253名無しさん＠お腹いっぱい。2006/03/27(月) 00:24:50
Itaniumは、いつまで引っ張るのかな。

クロックを上げることよりも、スレッド数を上げることよりも、
IPC向上を至上命題にしたアーキテクチャは、開発当時は正しくても、今は正しくないよね。
0254名無しさん＠お腹いっぱい。2006/03/27(月) 00:46:01
よく知らないが、バージョン間の細かい仕様の違いがあるんジャマイカ。
Write once debug anywhere と言われていた時もある品。
0255名無しさん＠お腹いっぱい。2006/03/27(月) 10:43:03
>>253
NetBurstはどうなった？
バブル時代の体育会系の営業みたいで大嫌いなんだが。
■ このスレッドは過去ログ倉庫に格納されています