64bits

46 owa 2007/11/07 21:58 id: mJs8kxp1Zus prob: 0.0%: SSE にはビットシフト命令が無い;;
http://web.mit.edu/nasm_v0.98/doc/nasm/html/nasmdoc0.html
あるのはバイト単位のシフト演算のみ。

とりあえず SSE 128bit レジスタに入れて出すだけのコード。(信用しないで!)
void test2()
{
    typedef struct {ULong lo; ULong hi;} U128;
    U128 m, n;
    m.hi = 0x1111111111111111;
    m.lo = 0x2222222222222222;
    n.hi = 0;
    n.lo = 0;
    __asm__ __volatile__ (
        "movq %2, %%xmm0;"
        "movq %3, %%xmm1;"
        "pslldq $8, %%xmm0;"
        "orps %%xmm0, %%xmm1;"
        "movq %%xmm1, %1;"
        "psrldq $8, %%xmm1;"
        "movq %%xmm1, %0;"
        : "=m"(n.hi), "=m"(n.lo)    // n is output operand (%0, %1)
        : "m"(m.hi), "m"(m.lo)      // m is input operand (%2, %3)
        : "%xmm0", "%xmm1"          // clobbered register
        );
    fprintf(stderr, "m=0x%016llx%016llx, n=0x%016llx%016llx\n", m.hi, m.lo, n.hi, n.lo);
}
実行結果は
m=0x11111111111111112222222222222222, n=0x11111111111111112222222222222222

128ビット空間を自由に使えるものだと思ってた。馬鹿ですね。
シフト演算はたし算 (とバイト単位のシフトも使う?) に置き換えればできるけど、どうなんだろう?
C/C++ の 64ビットx2 のデータではシフト演算のロジックが汚くなるので SSE まで逃げてきたんだけど、
GPU と連立組むのもアイディアのうちか。

参考サイト:
Optimizing MILC Math Routines with SSE
http://lqcd.fnal.gov/sse/
SSE2を用いたRC5-64クライアントの最適化に関する考察
http://www.katto.comm.waseda.ac.jp/~matsui/rc5/index.html
続 GeForce8800GTX と SM4.0 の整数演算
http://wlog.flatlib.jp/item/911/catid/6
NVIDIA CUDA Homepage
http://developer.nvidia.com/object/cuda.html

45 owa 2007/11/06 22:44 id: mJs8kxp1Zus prob: 0.0%: インラインアセンブラの勉強
GCC Inline Assembler
http://caspar.hazymoon.jp/OpenBSD/annex/gcc_inline_asm.html
http://caspar.hazymoon.jp/OpenBSD/annex/gas.html
http://www.mars.sannet.ne.jp/sci10/on_gcc_asm.html

void test1()
{
    typedef unsigned long long ULong;
    ULong m = 0x1000100010001000;
    ULong n = 0x0111011101110111;
    ULong out = 0;
    __asm__ __volatile__ (
        "movq %1, %%rax;"
        "addq %2, %%rax;"
        "movq %%rax, %0;"
        : "=r"(out)         // 出力 (%0)
        : "r"(m), "r"(n)    // 入力 (%1, %2)
        : "%rax"            // 破壊されるレジスタ
        );
    fprintf(stderr, "m=0x%016llx, n=0x%016llx, out=0x%016llx\n", m, n, out);
}

コンパイル (gcc -m64) 後の実行結果は
m=0x1000100010001000, n=0x0111011101110111, out=0x1111111111111111

44 owa 2007/11/03 22:44 id: mJs8kxp1Zus prob: 0.4%: ビット位置の計算
0.0065秒/100万 (gcc -O3 Athlon64x2 3800+ x86_64 vine seed)
0.0146秒/100万 (gcc -O3 Athlon64x2 3800+ i386 vine 4.1)

ただ1ビットだけ立ってる場合のオフセットを求める方法。
---
int offset_of_onebit1(unsigned long long x)
{
    int n = 0;
    if (x & 0xffffffff00000000LL) {
        n += 32;
        x >>= 32;
    }
    if (x & 0xffff0000) n += 16;
    if (x & 0xff00ff00) n += 8;
    if (x & 0xf0f0f0f0) n += 4;
    if (x & 0xcccccccc) n += 2;
    if (x & 0xaaaaaaaa) n += 1;
    return n;
}
---
n += 16 は n |= 16 でも同じ。むしろ若干遅くなる。
また以下のように if 文を無くしても処理速度は変わらない
---
int offset_of_onebit2(ULong x)
{
    int n = 0;
    (x & 0xffffffff00000000LL) && (n += 32) && (x >>= 32);
    (x & 0xffff0000) && (n += 16);
    (x & 0xff00ff00) && (n += 8);
    (x & 0xf0f0f0f0) && (n += 4);
    (x & 0xcccccccc) && (n += 2);
    (x & 0xaaaaaaaa) && (n++);
    return n;
}
---
環境によって違いはあるかも。

43 owa 2007/10/29 22:37 id: mJs8kxp1Zus prob: 1.5%: ビットの連続抽出
0.230秒/100万 (gcc -O3 Athlon64x2 3800+ x86_64 vine seed)
0.513秒/100万 (gcc -O3 Athlon64x2 3800+ i386 vine 4.1)

ビット位置を一個ずつ取り出すイテレータ。
肝は bits & (-bits) で LSB (Least Significant Bit) が求められること。
---
#if defined(__x86_64__)
typedef unsigned long ULong;
#elif defined(__i386__)
typedef unsigned long long ULong;
#endif

class CBitPos {
    ULong bits;
public:
    CBitPos(ULong x) : bits(x) {}
    ULong next() {
        ULong x = bits & (-bits);
        bits &= ~x;
        return x;
    }
};
---

一回あたり44ビットONのデータで測定。つまり一個のイテレータで44回ループ処理した。
for (long i = 0; i < 1000000L; i++) {
    CBitPos a(0x7777777777773333LL);
    int pos = a.next();
    while (pos)
        pos = a.next();
}

ちなみに MSB (Most Significant Bit) を求める方法を用いると三倍くらい遅くなる。
---
    x |= (x >> 1);
    x |= (x >> 2);
    x |= (x >> 4);
    x |= (x >> 8);
    x |= (x >> 16);
    x |= (x >> 32);
    x &= ~(x >> 1);
---

42 owa 2007/10/29 22:18 id: mJs8kxp1Zus prob: 12.4%: ビット数のカウント
0.0085秒/100万 (gcc -O3 Athlon64x2 3800+ x86_64 vine seed)
0.0251秒/100万 (gcc -O3 Athlon64x2 3800+ i386 vine 4.1)

立ってるビットを数えるには隣同士の和を求めることを繰り返す。
---
int bitcount(unsigned long long x)
{
    x -= ((x >> 1) & 0x5555555555555555LL);
    x = (((x >> 2) & 0x3333333333333333LL) + (x & 0x3333333333333333LL));
    x = (((x >> 4) + x) & 0x0f0f0f0f0f0f0f0fLL);
    x += (x >> 8);
    x += (x >> 16);
    x += (x >> 32);
    return x & 0x0000007f;
}
---
参考サイト:
http://www.nminoru.jp/~nminoru/programming/bitcount.html
http://aggregate.org/MAGIC/#Most%20Significant%201%20Bit
http://graphics.stanford.edu/~seander/bithacks.html

41 owa 2007/08/22 01:01 id: mJs8kxp1Zus prob: 2.0%: 80コアチップ
http://pc.watch.impress.co.jp/docs/2007/0215/kaigai337.htm
http://pc.watch.impress.co.jp/docs/2007/0214/isscc02.htm
8x10=80CPU だそうです。おしいな 9x9=81CPU だと面白いかも^^;

64コアCPU なんてのも
http://pc.watch.impress.co.jp/docs/2007/0821/tilera.htm
http://www.tilera.com/products/processors.php

40 owa 2007/03/14 15:92 id: mJs8kxp1Zus prob: 1.8%: 円周率 300 万桁の計算
http://www.h2np.net/pi/
これは hoihoi-p 氏のブログから
http://hoihoi-p.yosiki.org/blog/435

http://h2np.net/pi/pi_quick_start.tar.gz を試してみると
Pentium4 2.8E (32bit): 14.77 sec
Athlon64 3700+ (32bit): 10.15 sec
Athlon64 3700+ (64bit): 5.92 sec
予備マシンながら、なかなかの性能^^

39 owa 2006/07/26 23:27 id: mJs8kxp1Zus prob: 18.3%: Debian to Run on AMD64
http://linux.slashdot.org/linux/06/07/26/0057215.shtml
http://linux.slashdot.org/comments.pl?sid=192198&cid=1578253...
明日読もう。

38 owa 2006/07/06 01:12 id: mJs8kxp1Zus prob: 0.0%: マシンの起動時にエラーが出るので良く見たら which コマンドなどがセグメンテーションエラー。
リビルドしてみると /usr/lib/libiberty.a なんてゴミを拾ってた。
こいつは本来 binutils-*.x86_64.rpm 入れた時に削除されてるはずのもの。なんでだろう...
やっぱり大掃除しないといかんなー

追記: 一応 /lib, /usr/lib の下は掃除完了

37 owa 2006/05/29 23:57 id: mJs8kxp1Zus prob: 0.1%: >>36 util-linux-2.12p-0vl4 ... 大量に依存関係のエラー
古い i386 版が残っていたためでした。少し間隔が空いて惚けてますね;;
gtk2 関連が整備されて来たので、試しに Sylpheed をビルドしたら OK
これでセカンドマシンとして十分機能する状態になりました w(^o^)w

全52件 - 01 02 03 04 05 06