[ruby-list:19825] Re: build on alpha (1/2)

えぐち＠エスアンドイー です。

＃引用元のマルチパートのエンコードに失敗してしまったので、
＃御見苦しいかも知れませんが、御勘弁を。
>>> In message [ruby-list:19817] Re: build on alpha (1/2)
    On Wed, 22 Dec 1999 02:49:34 +0900, [e-mail] (中川 誠) said:

> --pgp-sign-Multipart_Wed_Dec_22_02:42:58_1999-1
> Content-Type: multipart/mixed;
>  boundary="Multipart_Wed_Dec_22_02:42:58_1999-1"
> 
> --Multipart_Wed_Dec_22_02:42:58_1999-1
> Content-Type: text/plain; charset=ISO-2022-JP
> 
> 中川です。
> 
> 64 bit 化、けっこう大変ですね。他にも顕在化してない問題がありそうですね。

今回の、sizeof(int) != sizeof(long) の問題は、
今後いろいろなプログラムで対応を迫られると思います。

Bignum の digits のサイズの拡張は余計だった様にも思えますが、
ここが一番 64 化の効果がありそうなので、、、

> ところでこんなでかい整数演算の必要な人っているのでしょうか。64 bit 化に
> よる高速化の度合はどの程度なのかな。(この努力は報わるのか、とちょっと疑
> 問になったりして．．．)

 + 語長の拡張で従来 Bignum になっていたものが、Fixnum で済む
   (GC も少なくなる可能性がある)

 + Bignum の計算単位が大きくなり桁上がり回数が半減する
   また積除算ではさらに顕著な速度向上が期待できる

の２点は予想できます。逆に整数演算以外では
特に 32 bit 環境との語長による差異はないと思います。
＃アドレス空間が広大になるメリットは元段階では 4G 超の
＃メモリが入手困難なので甘受出来ないと思う。

> In message "[ruby-list:19771] Re: build on alpha"
>     on 99/12/21, EGUCHI Osamu <[e-mail]> wrote:
> 
>   >   #include <stdio.h>
>   >   #include <limits.h>
>   >   long func(int a)
>   >   {
>   >      return a * 2;
>   >   }
> 
>   >   main()
>   >   {
>   >       printf ("%ld\n", func(INT_MAX) / 2);  
>   >   }
> 
> nakagawa@z$ ./a.out
> 2147483647
> 
> となります。

ありがとうございます。
これだけみると、a * 2 の a が自動的に long に拡張されている気配ですね。
＃最適化された影響かも、、

>   > --- bignum.c-bug	Mon Dec 20 22:08:44 1999
>   > +++ bignum.c	Tue Dec 21 09:54:34 1999
>   > @@ -681,8 +681,8 @@
>   >  	for (j = 0; j < RBIGNUM(y)->len; j++) {
>   >  	    long ee = n + dd * BDIGITS(y)[j];
>   >  	    if (ee) {
>   > -		zds[i + j] = BIGLO(n);
>   >  		n = zds[i + j] + ee;
>   > +		zds[i + j] = BIGLO(n);
>   >  	    }
>   >  	    n = BIGDN(n);
>   >  	}
> 
> fact(40) の結果は問題なくなったようですが、相変わらず 0除算でコアダンプ
> します。それと、== の判定が効かなくなっているみたいです。バックトレース
> は意味が無さそうなので特に添付しません。

とりあえず、掛算のバグは直ったようですね。

> nakagawa@z$ diff -c sample/test.rb.orig sample/test.rb
> *** sample/test.rb.orig	1999年12月21日 20時49分46秒
> --- sample/test.rb	1999年12月21日 14時54分05秒
> ***************
> *** 563,568 ****
> --- 563,569 ----
>   ok($x == fact(40))
>   ok($x < $x+2)
>   ok($x > $x-2)
> + p $x
>   ok($x == 815915283247897734345611269596115894272000000000)
>   ok($x != 815915283247897734345611269596115894272000000001)
>   ok($x+1 == 815915283247897734345611269596115894272000000001)
> ***************
> *** 597,603 ****
> --- 598,606 ----
>   
>   $good = true;
>   for i in 4000..4096
> +   print i, "\n"
>     n1 = 1 << i;
> +   print n1**2-1, "\n", n1+1, "\n", n1-1, "\n"
>     if (n1**2-1) / (n1+1) != (n1-1)
>       $good = false
>     end
> 
> 上記のようなデバッグメッセージを入れた結果は次のようになります。多分今回
> のパッチを当てる前も同じところで落ちていたんだと思います。

＃添付頂いた、実行結果のデコードには失敗してしまったのですが..

  if (n1**2-1) / (n1+1) != (n1-1)

の / が事故現場だと思います。
とすると、 n1 + 1 が 0 になっているのかなぁ？

	えぐち