-PR-
解決
済み

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

  • 暇なときにでも
  • 質問No.84614
  • 閲覧数217
  • ありがとう数4
  • 気になる数0
  • 回答数6
  • コメント数0

お礼率 44% (11/25)

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はソラリスです。
通報する
  • 回答数6
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

質問者が選んだベストアンサー

  • 回答No.6
レベル13

ベストアンサー率 37% (570/1525)

#3です。

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

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

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

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

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

お礼率 44% (11/25)

gccではダメだということが分かったのでこの辺で閉めさせて頂きます。
ありがとうございました。
投稿日時 - 2001-06-05 18:11:07
お礼コメント
nagata

お礼率 44% (11/25)

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

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

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

その他の回答 (全5件)

  • 回答No.1
レベル11

ベストアンサー率 31% (81/257)

不動少数点:double, floatでは如何でしょうか?差が出ますか? 三角関数やsqrtなどの関数だと、doubleになってしまうので、四則演算で比較するのがよいと思います。 ...続きを読む
不動少数点:double, floatでは如何でしょうか?差が出ますか?

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

お礼率 44% (11/25)

回答ありがとうございます。
次のプログラムを走らせたところ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:32


  • 回答No.2
レベル14

ベストアンサー率 47% (11786/24626)

CPUのビット数によってその大きさの変数の処理能力が早くなるとは一概には言えないのでは? Spcarc3はriscチップだったと思いますが それを考えればdoubleの方がfloatより早いというのももちろん納得できることです。 またコンパイラの能力によってもかなり左右される物です。 時間測定のために -O0でコンパイルしているならなおさら性能を生かしていないと考えた方が良いでしょう。 ベン ...続きを読む
CPUのビット数によってその大きさの変数の処理能力が早くなるとは一概には言えないのでは?
Spcarc3はriscチップだったと思いますが
それを考えればdoubleの方がfloatより早いというのももちろん納得できることです。

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

お礼率 44% (11/25)

回答ありがとうございます。
実は私としては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:08
  • 回答No.3
レベル13

ベストアンサー率 37% (570/1525)

単純にCPU能力だけでは計れないと思います。 ・BUS、メモリコントローラが64bitに最適化されている ・OSが64Bitに最適化されている ・コンパイラが64bitコードを生成できる 最低でも以上がクリアされていないと32bit計算のほうが速くなる可能性が残ります。 ちなみに、質問文のコードでは(64bitコードを生成しているとして)int,long longの結果は同一になるべきですね ...続きを読む
単純にCPU能力だけでは計れないと思います。
・BUS、メモリコントローラが64bitに最適化されている
・OSが64Bitに最適化されている
・コンパイラが64bitコードを生成できる
最低でも以上がクリアされていないと32bit計算のほうが速くなる可能性が残ります。

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

iがintの時とlong longの時のアセンブラ展開(-Sオプション)を比較してみたらいかがでしょう?
補足コメント
nagata

お礼率 44% (11/25)

回答ありがとうございます。
sizeofでintやポインタのサイズを表示させたところ4バイトでした。
つまり64ビットのコードを生成してなかったみたいです。すいません。
とりあえず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/documentation/readmes/64bit_Compilers.html
のところをみました。
投稿日時 - 2001-06-03 01:37:26
  • 回答No.4
レベル11

ベストアンサー率 31% (81/257)

No.1の者です。 1)1.0や2.0だと、doubleになっちゃうんでタイプを合わせるために遅くなったのでしょう。ですから、floatの場合は「1.0f」のように書かなくてはなりません。 2)私がfloat, doubleのことを持ち出したのは、昔のスパコンのことを思い出したからです。私は、Cray-1以降は使ってないのですが、同じセイモア・クレイ博士の設計した、 ・CDC-6600 ・ ...続きを読む
No.1の者です。

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

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

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

因みにSunは、Ultraまでしか使ったことないです。
お礼コメント
nagata

お礼率 44% (11/25)

回答ありがとうございます。
fをつけたところめでたくdoubleとfloatの計算時間はほぼ同じになりました。
しかし32ビットCPUのathlonでもdoubleとfloatの計算時間はほぼ同じでした。
これはどういうことでしょう。athlonはdoubleの計算を特に強化しているんでしょうか。
投稿日時 - 2001-06-04 23:42:31
  • 回答No.5
レベル14

ベストアンサー率 50% (1122/2211)

> -xarch=v9bとかやるといいらしいのですが、コンパイルできません。 あなたが使っているのは gcc ではなかったのですか? あなたが参考にしたという Sun のページは Sun WorkShop という 純正のコンパイラのページです。 違うコンパイラのオプションを与えても、 > cc: language arch=v9 not recognized 「no ...続きを読む
> -xarch=v9bとかやるといいらしいのですが、コンパイルできません。

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

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

> cc: language arch=v9 not recognized

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

# gcc のマニュアルや info をみましょう
お礼コメント
nagata

お礼率 44% (11/25)

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

-m64と-mcpu=v9やってみましたがダメみたいでした。
gccのinfoには確かに-m64とか-mcpu=v9とかがあったんですけど、
実際にコンパイラにそのオプションを渡すとエラーが出てしまいます。
投稿日時 - 2001-06-05 00:10:24
このQ&Aで解決しましたか?
関連するQ&A
-PR-
-PR-
こんな書き方もあるよ!この情報は知ってる?あなたの知識を教えて!
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-
-PR-
-PR-

特集


いま みんなが気になるQ&A

-PR-

ピックアップ

-PR-
ページ先頭へ