やっぱりというべきか、ミスを発見したので訂正。 int _strncmp(void *buf, void *str, size_t size){ int *b = (int *)buf; int *s = (int *)str; unsigned int k = size >> 2; for(unsigned int i=0;i

x86はLittleEndianなのでintやshortで比較すると4Byte目の大小から優先されて戻り値の正負がstrncmpと異なりうるという問題が・・・。 Endian変換にはbswap命令を使えばいいわけですが、Cから直接扱う方法を知らないので保留。元々等しいかどうかの確認のた…

いいかげんやめたらいいのに、と自分でも思うのですが、改善すべき点があるとなるともう少し粘りたくなるので。 上で"ntohl(b[i]) - ntohl(s[i])"を返すようにしたのですが、どうせなら減算までを1つの関数として実行すれば関数呼び出しの手間が少なくなって…

strncmp()とおそらく同等の動作をするもの。というかmemcmp()か？ int _strncmp(void *buf, void *str, size_t size){ int *b = (int *)buf; int *s = (int *)str; unsigned int k = size >> 2; for(unsigned int i=0;i

3つ目の引数、sizeの指定において0でないという仮定ができるとすれば、for文ではなくdo〜while文を用いることでもう少し削れそうです。 上のintncmp()では dec eax @2: mov ebx,dword ptr [ecx+4*eax] xor ebx,dword ptr [edx+4*eax] je short @3 mov eax,1 …

先日のintncmp()だのintcmp()だのは何がしたかったかというと、x86+Windowsを前提に考えると現状では32bitレジスタを使うわけで、char(8bit)同士の比較ではせっかくの32bitレジスタも下位8bitのみしか使わないので効率が悪いではないか、ということが言いた…

int _strncmp(void *buf, void *str, size_t size){ int *b = (int *)buf; int *s = (int *)str; unsigned int k = size >> 2; for(unsigned int i=0;i

Javaをやらないとと思いつつもC言語にて生きるおみ。 今日は文字列において比較する長さが既に16/32bitの整数倍であると分かっている場合、char *を用いたstrcmp()/strncmp()とint *あるいはshort *にキャストしたものはどちらが高速であるかという虚無をし…

ろぎ氏に指摘されたようにビット演算で比較してみた。 if(b[i]-s[i]){ return 1; } ↓誤 この行を if(b[i]&s[i]){ return 1; } こう変えただけでかなりの高速化。↓正 if(b[i]^s[i]){ return 1; } 4文字の場合、先に挙げたintcmp()において同様のビット演算を…