SPARC3はホントに64bitで動いてる?

SUNのSPARC3は64ビットのCPUらしいのですが次のプログラムを動かした
ところなんだかホントかどうか疑わしくなりました。

#define T long long

main()
{
const int N=100;
T a[N],b[N];
for(int i=0;i<N;i++)
{
a[i]=i;
b[i]=i;
}
b[N-1]=0;
T *x,*y;
for(int i=0;i<10000000;i++)
for(x=a,y=b;*x==*y;x++,y++);
}

このプログラムを走らせたところTがintの時とlonglongのときでは
実行時間が倍近く違いました。(int 5.4秒、long long 9.5秒)
SPARC3が64ビットをネイティブで計算できるならintとlonglongでは
これほどの差は出ないと思うのですが。コンパイラはgccを使っているのですが
そのせいでしょうか。OSはソラリスです。

No.6 ベストアンサー 回答者： toysmith 回答日時： 2001/06/04 21:32

#3です。

gnuのGCCのページで「Sparcの64bitコードは生成できない」との記述を見つけました。
GCC2.95に関する記述です。
GCCのバージョンを確認して下さい。

以下、本論とは無関係なので無視してくださってもかまいません。

> sizeofでintやポインタのサイズを表示させたところ４バイトでした。
> つまり６４ビットのコードを生成してなかったみたいです。

この確認方法は乱暴ですね。
intのBit数の保証はコンパイラの責任です。
「ALUまたはレジスタサイズと同一である」というのは慣例にすぎません。
また、
・longはintより短くない
・longはポインタ値を保持するのに充分なBit数を持つ
という規約から64bit処理系でもsizeof(int),sizeof(int *)はsizeof(long)と同じである事が多いのではないでしょうか。

確認は-Sオプションのアセンブラ出力で「多倍長整数として扱われている」事を確認するしかないのではないでしょうか。

参考URL：http://www.gnu.org/software/gcc/install/specific …

この回答への補足

gccではダメだということが分かったのでこの辺で閉めさせて頂きます。
ありがとうございました。

補足日時：2001/06/05 18:11

この回答へのお礼

>gnuのGCCのページで「Sparcの64bitコードは生成できない」との記述を見つけました。
>GCC2.95に関する記述です。
>GCCのバージョンを確認して下さい。

なんと、そうだったんですか。僕の使っているバージョンは２．９１でした。
２．９５が現在最新のバージョンなようなのでGCCではダメということでしょうか。素直にSUNのコンパイラを使ったほうが良さそうですね。

アセンブラを確認せよとのことですが、僕はアセンブラが読めません。
一応ーSオプションをつけてコンパイルしてみましたがさっぱりわかりません。ただintの時とlonglongの時で出力ファイルの行数が違ったのでおそらくlonglongは多倍長整数として扱われていると思われます。

お礼日時：2001/06/04 23:28

No.5 回答者： a-kuma 回答日時： 2001/06/04 15:49

> -xarch=v9bとかやるといいらしいのですが、コンパイルできません。

あなたが使っているのは gcc ではなかったのですか？
あなたが参考にしたという Sun のページは Sun WorkShop という
純正のコンパイラのページです。

違うコンパイラのオプションを与えても、

> cc: language arch=v9 not recognized

「not recognized（＝知らん）」といわれても仕方ない。
私は gcc をあまり使ったことは無いので、良く分からんのですが
-m64 とか -mcpu=v9 といったオプションになるのではないですか？

＃ gcc のマニュアルや info をみましょう

この回答へのお礼

回答ありがとうございます。

-m64と-mcpu=v9やってみましたがダメみたいでした。
gccのinfoには確かに-m64とか-mcpu=v9とかがあったんですけど、
実際にコンパイラにそのオプションを渡すとエラーが出てしまいます。

お礼日時：2001/06/05 00:10

No.4 回答者： ametsuchi 回答日時： 2001/06/03 14:11

No.1の者です。

１）1.0や2.0だと、doubleになっちゃうんでタイプを合わせるために遅くなったのでしょう。ですから、floatの場合は「1.0f」のように書かなくてはなりません。

２）私がfloat, doubleのことを持ち出したのは、昔のスパコンのことを思い出したからです。私は、Cray-1以降は使ってないのですが、同じセイモア・クレイ博士の設計した、
・CDC-6600
・CDC Cyber 176
というマシンを科学技術計算用に使っていました。Cray-1の64bitには及びませんが、60bitマシンです。このマシンの場合、全ての演算が60bitで行なわれる訳ではないし、レジスターも60bitで統一されている訳ではなかったように思います。浮動小数点演算は60bit、整数の計算は正確なビット数は忘れたが、確か36bitだったかな....？

３）もし、１）でfloatとdoubleの計算時間が殆ど変わらなければ、倍精度浮動小数点演算は64bit使っているのでしょう。

因みにSunは、Ultraまでしか使ったことないです。

この回答へのお礼

回答ありがとうございます。
fをつけたところめでたくdoubleとfloatの計算時間はほぼ同じになりました。
しかし32ビットCPUのathlonでもdoubleとfloatの計算時間はほぼ同じでした。
これはどういうことでしょう。athlonはdoubleの計算を特に強化しているんでしょうか。

お礼日時：2001/06/04 23:42

No.3 回答者： toysmith 回答日時： 2001/06/03 01:18

単純にCPU能力だけでは計れないと思います。

・BUS、メモリコントローラが64bitに最適化されている
・OSが64Bitに最適化されている
・コンパイラが64bitコードを生成できる
最低でも以上がクリアされていないと32bit計算のほうが速くなる可能性が残ります。

ちなみに、質問文のコードでは（64bitコードを生成しているとして）int,long longの結果は同一になるべきですね。

iがintの時とlong longの時のアセンブラ展開（-Sオプション）を比較してみたらいかがでしょう？

この回答への補足

回答ありがとうございます。
sizeofでintやポインタのサイズを表示させたところ４バイトでした。
つまり６４ビットのコードを生成してなかったみたいです。すいません。
とりあえずSUNのHPにいってみました。
どうもオプションが必要らしいのですがうまくいきません。
-xarch=v9bとかやるといいらしいのですが、コンパイルできません。

bash-2.03$ cc -xarch=v9b test.c
cc: language arch=v9 not recognized
ld: 重大なエラー: ファイル test.c: 不明なファイルタイプです
ld: 重大なエラー: ファイル処理エラー。a.out へ書き込まれる出力がありません。
collect2: ld returned 1 exit status
bash-2.03$

というエラーがでてしまいます。ちなみに
http://www.sun.co.jp/forte/developer/documentati …
のところをみました。

補足日時：2001/06/03 01:37

No.2 回答者： asuca 回答日時： 2001/06/02 23:16

CPUのビット数によってその大きさの変数の処理能力が早くなるとは一概には言えないのでは？

Spcarc3はriscチップだったと思いますが
それを考えればdoubleの方がfloatより早いというのももちろん納得できることです。

またコンパイラの能力によってもかなり左右される物です。
時間測定のために　-O0でコンパイルしているならなおさら性能を生かしていないと考えた方が良いでしょう。
ベンチマークはもう少し巧妙に作らないとちゃんとした正確な性能は測れませんよ。

この回答への補足

回答ありがとうございます。
実は私としてはdoubleやfloatにはあまり興味がありません。
私の興味は整数型の計算にあります。例えば2つのchar配列の内容が
等しいかどうか調べるときに8ビットずつ調べるより64ビットづつ調べられる
としたらそっちの方が8倍速そうな気がしませんか。それをちょっと実験して
見たかったのですが、どうも本当に64ビットづつネイティブに調べられるか
怪しくなってしまったのでこうして質問したわけです。

＞CPUのビット数によってその大きさの変数の処理能力が速くなるとは
＞一概には言えないのでは?

私がいいたいのは32ビットのCPUで64ビットのデータを扱うのと64ビットの
CPUで64ビットのデータを扱うのではどう考えたって64ビットのCPUの方が速いだろう、
と言うことです。もちろん周波数とかは同じとして。それを期待していたのに
64ビットCPUでもlonglongの計算にかかるコストがintの倍というのはおかしいと
言っているわけです。この際浮動小数点のことは忘れてください。

補足日時：2001/06/03 00:11

No.1 回答者： ametsuchi 回答日時： 2001/06/02 21:22

不動少数点：double, floatでは如何でしょうか？差が出ますか？

三角関数やsqrtなどの関数だと、doubleになってしまうので、四則演算で比較するのがよいと思います。

この回答への補足

回答ありがとうございます。
次のプログラムを走らせたところT=double 3.7秒 T=float 5.0秒
となりました。floatの方がかえって遅いとは、、、
ちなみに-O0をつけて最適化を明示的にしませんでした。

typedef T double;

main()
{
T a,b;
for(a=1.0;a<10000.0;a+=1.0)
for(b=1.0;b<10000.0;b+=1.0)
{
a+b;
a-b;
a*b;
a/b;
}
}

補足日時：2001/06/02 21:57