Itaniumで64ビットLinuxだぁ！

IntelのItanium（Mackinlay）でLinuxして64ビット
コンピューティングしましょう。AMDの64ビットCPUも
いいかもしれん。PowerPC64ビットとかSparc、DecAlphaも
あり。

http://www.theinquirer.net/?article=7966
Linuxにおける'charming oddity'とは何でしょう？

>>152
rpmもしくはディス鳥かな？

http://www.gdm.or.jp/voices.html

めちゃめちゃ安いっすね

Hammer来るよ〜

（＾＾）

Opteron発売あげ

Opteron用のコンパイラってなにつかうのん？

一応gccではすでに対応してると思うが…
x86_64がそれにあたるはず。

どうせすぐ陳腐化するんだから32の倍で64とかせこいこと言ってないで
1024bit位にすればインパクトあるのに、馬鹿だよな。

iccの64bitが使えればすぐに買うんだが

>>163
ﾜﾛﾀ
1024bitの命令セットってどんなんだろ

別にVLIWプロセッサだったら不思議じゃないかな？
transmetaだけじゃなくてintelも最近ではVLIW寄りになってるし。

でもベース1024bitってすげー意味なさげ。
一体どんなデータ扱うのよ。

PowerPC G4で128ビットのほうが早いんちゃうん?

>167
PPC G4(Power4じゃない)は32bit…

http://homepage.mac.com/ayaya16/

>161
ttp://www.pgroup.com/AMD64.htm

http://www.watch.impress.co.jp/akiba/hotline/20030426/opteron.html
一式揃えてもXeonと同程度の出費で済むぞ

http://muryou.gasuki.com/zenkaku/index.html
http://www.muryou.gasuki.com/hankaku/hankaku08.html
http://muryou.gasuki.com/hankaku/hankaku07.html
http://www.muryou.gasuki.com/hankaku/hankaku10.html
http://muryou.gasuki.com/hankaku/hankaku09.html
http://www.muryou.gasuki.com/hankaku/hankaku06.html
http://muryou.gasuki.com/hankaku/hankaku05.html
http://www.muryou.gasuki.com/hankaku/hankaku02.html
http://muryou.gasuki.com/hankaku/hankaku01.html
http://www.muryou.gasuki.com/hankaku/hankaku04.html
http://muryou.gasuki.com/hankaku/hankaku03.html

>>164
>iccの64bitが使えればすぐに買うんだが

% ecc -V -c
Intel(R) C++ Itanium(R) Compiler for Itanium(R)-based applications
Version 7.0, Build 20021018
Copyright (C) 1985-2002 Intel Corporation. All rights reserved.

のことじゃなくて?

AMDの64ビットCPUが安価になってうられてくれれば、イタニウムも
細い配線長で小さく熱を出さないのを作ってクロックをあげて、
値下げをしてくるのを期待できるし、あるいはAMDにそっくりの
64ビット化のアーキテクチャーを改めて出して来るのが早まるかも。

Itanium無印800MHzを使ってみて印象に残ったのは、レスポンスの
悪さ。おそらく割り込みにレジスターがむやみにあるので時間が
かかるのかな？　後は、インテルコンパイラーの最適化はすばらしいが、
最適化しないときとの性能差が激しいのと、最適化を強くやろうと
すると、コンパイルが重たいということ。64ビットのFP演算を
させると、クロック速度が２倍のCeleron1.7GHzを超えることが無いみたいだし。
（SD-RAMの初代イタ二ウム800MHzとPC2100-DRSDRAMのP4Celeron1.7GHzを
比較しているので、その点は割り引かないといけないが。）

さっきRedHatのFTPサーバーを調べてみると、どうもia64の
サポートはRH7.2以降は無くなってしまったみたいですね。
rawhide はタイムスタンプが新しいみたいだけど、あれに
乗り換えたべきものかなぁ。rawhideってup2dateでアップデート
できたりするのかな。Itaniumでは商売にならなかったのかな。　

ところでrawhide に x64-64というのがあったけど、
あれがAMDのOpteron用のブートバイナリとRPMバイナリなんだろね。

http://homepage.mac.com/hitomi18/

>>174
分かっていてわざと書いてるならごめんね．
Itaniumは「アイテニアム」と読むそうです．
(IDF JapanでIntelの人がserver系のセッションの冒頭で
「アイタニウムとかイタニウムとかさまざまに読まれていますがアイテニアムです」と繰り返し説明していました．)

Itanium2 1GHz 3MB L3 を会社で使用してますが，全ての局面でとはいえませんが，
スーパースカラー計算機用の最適化コード(複数レジスタの並列動作を徹底的に狙ったコード)を
efcでコンパイルするとP4 3.06GHzより速いよ．(64ビットのFP演算)

>>177->>178
春厨ｷﾀ━━━━━(ﾟ∀ﾟ)━━━━━ !!!!!

Ｌ３に収まると有利なのかな？

http://homepage.mac.com/ayaya16/

RedHat 7.2 for Itanium を使っています。

Cコンパイラの出力するバイナリの実行速度は、

遅い > GNU GCC 2.98 >SGI Open64 ver.0.010-13 > Intel C++ Compiler Ver7.0 > 速い

こんな具合でした。

他にフリーで使えるC/C++コンパイラで、Itaniumでオススメなもの、ありましたら教えてください。

それでも「Intel Compiler の最適化は、糞」と言ってる企業がある。
そういうところが、無償で自社技術を提供していかなければ良いもの
にはならない。

＞他にフリーで使える
Intel は、こんな事ほざいてるビンボー学術用途向けを狙っている
訳ではないのだよ。パイが広い 32bit の世界ではない。
上述のような「お前のコンパイラ糞。ウチの技術を提供するから対価を遣せ。」
と言ってくれる企業を待っている。もちろん世界の Intel 相手なので
対価≒技術で、技術提携なのだが。

>>180
L3に収まる大きさの問題では無いので，レジスターが多くて同時実行可能命令数が多いことによると思います．L3の効果もあるとは思いますが．
マトリクスの三角分解(skyline形式でブロック分解)の部分では某社のベクトル計算機より速かったです．
(平均ベクトル長がベクトル計算機の性能を十分引き出すには短いこともありますが...)
L3の大きさを考えたチューニングを行えば，もっと性能がでると見込んで，現在，アルゴリズムの検討中です．
IDFの最適化のセッションで行列積のチューニング例が有り，かなりの性能だったと記憶しています．
後日，IDFの記録CD-ROMが送られてくるので，数値がのっていたら報告します．

これが結論！次世代サーバースペックの指標
http://info.nikkeibp.co.jp/opteron/

>>184
151のリンクの記事を読んでみた？アメリカで日本人ががんばっているのだね。

>>186
Kazushige Goto のことですね．
ソースコードが公開されていないのは残念だと思っていました．

>>187
Linux/Alphaの数値演算が遅かった時代に
libmをアセンブラで書き直してた方ですな。

まあ、アセンブラの方が、便利なこともありますからな。
特にコンパイラのバージョンが変わると、せっかく機械語命令
の並びまでを意識して最適化したソースが、コンパイルしなおし
たら、性能が落ちるコードを出すようになったりもするんで。

（　´Д｀）/＜ 先生！！こんナのが有りますた。
http://togoshi.ginza.st/mona/mona05.html
http://www.togoshi.ginza.st/mona/
http://www.togoshi.ginza.st/mona/mona03.html
http://togoshi.ginza.st/mona/mona02.html
http://www.togoshi.ginza.st/mona/monaz08.html
http://togoshi.ginza.st/mona/mona06.html
http://www.togoshi.ginza.st/mona/mona10.html
http://togoshi.ginza.st/mona/mona04.html
http://www.togoshi.ginza.st/mona/mona07.html
http://togoshi.ginza.st/mona/mona01.html
http://www.togoshi.ginza.st/mona/mona09.html

http://homepage.mac.com/hitomi18/

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―

第５回
http://info.nikkeibp.co.jp/opteron/

http://pc.watch.impress.co.jp/docs/2003/0702/amd.htm

RedHat7.2なんですが、IntelのCコンパイラで、ビルドし直すと速くなりますか?

64ビットということでは、AppleのG5 PowerMACは注目されてもよいマシンだよ。
値段もデュアルでも４０万台だし。

コマーシャルさせて頂きます。
HP Itanium2機をオークションに出品しております。
興味のある方はご覧ください。
http://page.auctions.yahoo.co.jp/jp/auction/58094356

Itanium2の900MHzはCPUに欠陥があって、インテルがリコールかけてなかった
かな？？

>>199
オークションで買っても交換してもらえるっしょ。

http://www.clubsse.com/camp/zx2000_super/index.html

zx2000が40万円。tbe01217さんほど安くないけど。

何故、安く売っているのだろうか？　Opteronに比べての値下げなのか、
それともまたニューモデルが登場する予定なのかな？
たとえばCPUクロックが倍増しているとか。。

性能が向上した新しいCPU搭載機が出るから、在庫処分だと思われ。

でも、安心汁、Itanium2同士は今のところピン互換だ。

#Mercedは・・・。

やっぱり、欠陥CPUが搭載されているから安く叩き売りなのでは？
どんなコードを実行したらコケルのかだれかご存じない？
もしや、CPUが熱暴走するのか？

>>204
Deerfieldっていう、これよりクロックが5割増で
消費電力もすくないのがでるからでしょ。

覗いたが価値！ウキウキしますよ♪

http://angely.h.fc2.com/page004.html

AMD64並みの値段にして欲しいものだ。
もちろん性能を落としていいとまでは
いわないよ。

来月 hammer 発売なのに全然盛り上がらんから、
６４ビットCPU総合スレを誰か立ててくれ！

再度コマーシャルさせて頂きます。
HP Itanium2機をオークションに出品しております。
興味のある方はご覧ください。
http://page.auctions.yahoo.co.jp/jp/auction/59798506

┌───┐
│ｘゝｘ│
│　⌒　│
├───┤
└───┘

その相田似有無900MHzはチップの熱設計が不良で、900MHzクロックで
作動させると、ハングだか計算結果がおかしくなると言うものじゃなかったかな?
クロックを700だか800だかに下げればOKらしいが。

【hp】は無償交換やってないの?

初代Itaniumについては、無償でオンサイト交換してくれるって言われたけど、
無償でできる時間帯に立ち会えないから、そのままにしています。

>>213
交換どころか、その上の Madison 3M に無償アップグレードしてくれます。

マジ?

AMD64 に対抗してインテル内部で密かに開発がなされていると噂されていた
真の64ビット拡張されたx86アーキテクチャーのCPUはまだでないのかな?
取り合えず,今のインテルのIA32のCPUとピンコンパチにして貰えれば,
いいよね.

ピンコンパチは甘い。

IA32でのピンコンパチの期間は短いこと、
BIOSのサポート(やっぱりEFI欲しくないか?)
などが問題としてあると思います。

>>216
ハイパースレッディングは、機能が殺されてただけで実際にはP3からパターンには
焼き付いていたとの話ですから、今のP4は、メモリバスは64以上だし、SSE２とか64bit
以上のレジスタも扱ってる訳ですから、探せば64bitの汎用レジスターがいるかもしれませんね。
うんがぁ、アセンブラが無きゃどーしようも無さゲデスが。

Intelの場合ピンコンパチでも今の板では使えない罠。
GraniteBayとか使い道ないし。

CPU内部のマイクロ命令を差し替えれば,明日にも64ビットモードが(のろいかも
しれないけれども)動作するようになるというのはどうだろね?

クルーソーのコードモルフィング技術でも,ハードエミュレートできるかも
しれないし.(十分なレジスターがなければキャッシュをピン止めしておいて
レジスタ代わりにつかうとか....)

そんな聞くからに鈍速そうなものを使わされるくらいなら
2Gごとにメモリ管理のワーカープロセス作ってくださいとか言われた方がまだましだ。
#ほんとか?

>>220
マイクロコード方式は遅いので、互換性維持のため、一部の複雑な命令でしか使わず、
多くの良く使われる命令を、ワイヤードロジックで実装することで高速になった・・・のが486。
だと思ってるので、ちょっとパッチをあてる程度以上のことをさせるのは重くなると思う。

#ワイヤードロジックにしちゃったのはNECのV33だっけ?
16ビットではあったものの、当時としては、今のAthlon並みにIntelより速い互換CPUだったね。

今のPENTIUM はCISCの命令列をデコードして，内部のRISC的なマイクロ命令に
変換して回路を制御しています．

>>223
マイクロコード方式と言えなくもないかもしれないけど、
昔のマイクロコード方式とは、違うものなんじゃないかなぁ。

で、Itaniumで姫野ベンチのサイズXLを動かした方、いらっしゃいますか?

サイズLまでは普通に動くんですけど、topコマンドで見ると、
メモリをたった1.8GBしか使っていないので、64ビットの意味ないんですよ。

＞なんちゃって SE (6EzCE8jZ)へ
宿題は自分でやれ

>>226
自分でやって解決できないから、聞いているのですが・・・。

XLをgccとeccの両方で試したが、
片方は実行時に、セグメンテーションフォールト、
もう片方はコンパイル時に、配列が大きすぎる、とエラーになる。
(だいぶ前にやって、記録とってなかったので、どっちがどっちか、わからない。)

飽いたに倦むは,なんだか期待外れだったとしか言いようがない.だって
ちっともクロックの早いの出さないし,値段は高いし,コンパイルは遅いし,
沢山の命令を同時に発行できるというわりには浮動小数演算器の個数が
しょぼいし. とにかく,もういい加減3年目になるのに,ちっとも立ち上がって
いないじゃないか,HPのクラスターを除いては.

確かにコンパイルは遅い。EPICだから、仕方ない。
その分、IA-32よりも、最適化が効いた時の性能向上は大きいと思う。

これでクロックが3GHzとか出れば、暗号化処理とかは32ビットの2倍は出て旨いのだが。

L3-1.5Mの廉価版出たから少し値段はこなれるっぽいけど
どういう風に売りたいのかがさっぱり分からんなぁ。
fpの速さで押したいのか、64bitで押したいのか。

EPICだと,1バンドルに3命令までしか詰めることができないので,
FPユニットを沢山つけてもしかたがないと最初からあきらめて
設計しているみたいでつまらない. それに,もしも1バンドルにもっと
同時並列に実行できる命令の個数を増やそうと思ったら,それは
命令のフォーマットを変えることを意味して,せっかく作り上げた
バイナリコードの資産を捨てることを意味する.それにくらべれば,
EPICではないアーキテクチャーの方が将来ハード側の努力で同時実行
可能な処理を拡大できる期待を遺すものである.

>>231
10年前 RISC は、命令セットを単純にして、ハードも単純に。
深いパイプラインと、スーパースカラは多く。
そう言われつつ滅びようとしてるけどね。

＞将来ハード側の努力で同時実行可能な処理を拡大できる期待を遺すものである.
Itanium は、努力っつーより無理して、何でも詰め込んだ気がします。

＞せっかく作り上げたバイナリコードの資産を捨てることを意味する.
結局は、あと５年。過去の資産は残るから、どうやっても勝ち目は無い。
今は新らし物好きのオモチャでしかない。
新らし物隙は、新しいのが出て、更にコストパフォーマンスが高けりゃりゃ、
またそっちに飛び付くわけで。

＞同時並列に実行できる命令の個数を増やそうと思ったら,それは
＞命令のフォーマットを変えることを意味して
ライナスは頑張ったけど、市場は受け入れなかったし。

EPICにせずともハイパースレッド化することで,
システム全体でのスループットを改善出来たりもするし,
同じシリコン面積を使うならオンダイのマルチプロセッサ化
も可能であろう. CPUの再設計の度に命令のフォーマットを
変更してもよくてソフトは全てソースで提供されて,コンパイラが
CPUモデルに併せて最適化コンパイルしてから実行をするという
ので無い限り,アイタニウムの取ったEPICの方式は,x86がこれまで
のように20年間も活躍出来た方式なのと比べて,あまりにもその場
のみのアーキテクチャー(技術の向上で変更を余儀なくされる)に
思える.

つまりAMD64最強ということですね

インテルはIA-32互換を捨てた、IA-64のみの
廉価版アイテニウムを直ぐに市場に出すべきだ。

同時に処理可能なのが1バンドル3命令だけじゃないよ。
パイプラインには何バンドルも流れてるし、
ロジックが複雑化するのも厭わなければ複数バンドルを同時に実行してもいいわけだし。

それよりも、分岐命令の数を減らせるようになっているとか、
そういうところに着目して欲しい。

命令の並列性を確保して個々の命令をグルーピングするまでは
コンパイラに任せるわけだから、いづればそれなりに性能も上がってくるのかな。
今性能をあげないのはわざとな気もしてるけど。あと3,4年はPCサーバで
儲けるつもりというか。個人的にはAMD64の互換機をインテルに出して欲しいけど。

G5のあのTV宣伝CMを観たら,
そんなもの恐ろしがってだれも
買わなくなるんじゃないかと心配
してみたくなる.

はっきりいってgccのia64対応がまずーな限りはLinux/ia64はありえんでしょう。
LinuxはAMD64です

>>231
バンドルというのはフェッチの単位ぐらいの意味しかないのでは？
実行ユニットの個数との関係っていったい？？
それに並列実効可能な命令なんてバンドルの境界を越えていくつでも
並べることができるんだけど、並列実効可能な命令の個数を増やすために
バイナリフォーマットの変更が必要って何？？
言ってることがむちゃくちゃです。

240さんの言うことに100%同意できない部分もあるけど、大筋は同意。

初代Itanium→Itanium2で実行ユニットの構成が変わった
(たしか、浮動小数点が増えて、SIMDが減った)
りしているように、けっこう柔軟にできている。

VLIWではなくEPICである、ということは、そういうことなのかなぁと。

>>233
>x86がこれまで
>のように20年間も活躍出来た方式なのと比べて,あまりにもその場
>のみのアーキテクチャー
ia64のインターフェイスによりハード・ソフトに確保される
柔軟性を見抜けるひとでないと、ia64を語ることは難しい。

それはさておき、個人的にはAMD64マンセーなんで
Itaniumはお蔵入りでもかまわんのです。

Itanium も Itanium2 も乗加算器(乗算と加算が融合した演算器)が
2つしか無いはずだが. 浮動小数点演算能力に関しては,クロックあたり
最大4演算(64ビット浮動小数の場合), 最大8演算(32ビット浮動小数の場合)
だったと思ったが. SIMD演算に関してはSSEレベルでSSE2ではなかったような.

「64ビットにしない理由はない」――Athlon 64ついに登場
http://www.zdnet.co.jp/news/0309/23/ne00_athlon64.html

AMD64まんせー

あーところでAMD64はこのスレ収容なん？方向性違うし別スレ？

>>239
＞はっきりいってgccのia64対応がまずーな限りはLinux/ia64はありえんでしょう。
意味不明。根拠を述べよ。

>>246
そういう前に、使ってみることだ。

>>247
コンパイラは、金出して買うもの。

>>248
イソテルの社員？

インテルのコンパイラのLinux版は条件満たせば無償だったりするのだが・・・。

UNIXにおいてはCコンパイラはシステムの一部だからねえ。
外部からCCを取り入れて使うってのはUNIX的な発想ではないわな。
IntelがGCCの完全互換を目指すならいいけど。

C コンパイラがついてこない Unix もけっこうあるわけだが。