今どきの名前設定方法

質問

昔は、いかに高速化するために、文字を少なくしよう、という方法とかもあったのですが・・・
Windows NT あたりから
Administrator
という長いユーザー名
Windows 95あたりから
Program Files

Windows 2000あたりから
Documents and Settings

とかいう長いフォルダ名が使われています。

LFNとかいうのは別としても

Admin
Program
Home

とかいう名前にしたほうのが、特にディレクトリのアクセスがちょっとでも（数ステートでも）高速化するのに
なぜ、しないのでしょうか？

宜しくお願いします。

回答No.10

wormhole

>あまり多く文字列比較系のアルゴリズムは、実際にOSのソースを見ても
>あんまり変わってないな・・という気もしますが
>どうでしょうか？

どのOSのソースを見られてるのかわかりませんが文字列比較のアルゴリズは変わりようがありません。

ですが特定のファイルやディレクトリにたどり着く分には、その文字列比較そのものの回数を減らすような仕組みになっています(先にも書きましたがstrstrなんかではありません)。

回答No.9

Tacosan

strlen の「アルゴリズム」に, そんなに「素晴らしすぎる」ものってありましたっけ? しょせん「'\0' まで 1個ずつ数える」しか方法はないはずなんだけど.

あと, 文字列探索についていえば「効率的なアルゴリズム」はあるものの現実的にはあまり性能向上に寄与しません. 普通にありそうな状況では, 単純なアルゴリズムで十分だったりします.

お礼

本当に単純なアルゴリズムだけで、いいのか？という前に
普通に、L1キャッシュにヒットしやすくするために
短い名前にしたほうが、良いとも考えてしまいます。

回答No.8

久保 泰臣（@omi3_）

8ビット、クロック 2MHz、論理演算のみ、変数は A-Z、
この時代は、機械語でないと満足な速度が出ませんでした。

そのプログラマが上司になって、昔の苦労は不要だった。
ソフト開発は、バグ退治に明け暮れるようになって、
バグが出ないようにする工夫が優先されました。
メモリ量や速さは、ハード任せにしたのです。

お礼

再びですが・・・

いくら、L1キャッシュの中で動いているであろうとも、
ノイマン型のCPUは、1つの命令を順番に実行していくに
過ぎないはずです。

CPUの高速化は、それらの制限の中から、より高速に動作させるために
キャッシュを付けてみたり、パイプラインにしてみたり、分岐予測を
（HWかSoftwareで）つけてみたりと、いろいろあるはずですが、

今回の質問で、Z80の命令で言えば
LDI
を例に出してしまいましたが
LDI
LDI
LDI

と、

:label
LDI
JR label
jr label
のどっちが速いかという問いに対して、
想定外の答えがでてきました。

LDIR です。（無論知ってますが）

確かに、一気に比較する命令もありますが、
結局、文字列比較で、C言語が使っているのは
(FreeBSDのソースより抜粋）

今でも、大してアルゴリズムが変わっていない

#include <sys/cdefs.h>
__FBSDID("$FreeBSD: releng/10.0/lib/libc/string/strcmp.c 251069 2013-05-28 20:57:40Z emaste $");

#include <string.h>

/*
* Compare strings.
*/
int
strcmp(const char *s1, const char *s2)
{
while (*s1 == *s2++)
if (*s1++ == '\0')
return (0);
return (*(const unsigned char *)s1 - *(const unsigned char *)(s2 - 1));
}

に過ぎないのです (FreeBSDより抜粋）

CPUとの命令の組み合わせで、もっと確かに工夫できる部分はあるのですが、
現時点で、この関数を実行している以上、ディレクトリやファイル名は
（特にキャッシュにある情態で）アクセスが遅くなるとしか
うちとしては、これ以外に理解できません。

みなさんありがとうございました。

＃確かに、4GHzのCPUもってますが、オーバークロックしても、遅くて遅くて仕方ありません。。

回答No.7

久保 泰臣（@omi3_）

マイクロソフトなどの、プログラマー集団の中で、

自分のアーキテクチャを採用してもらうために、
少しでも早く、内容をイメージさせようとしたのでは？
また
コード量＝収入　みたいな風習があるので名前も長くしてしまえ、
と考えた愚か者がいたんでは？

補足

ありがとうございます。

(Vistaと比べたら別ですが）
Windows 8 にすれば、Windows 7 より高速化する！という
いわゆる宣伝みたいなことはありました。

実際、これは起動速度のみであって、
半ばチートしているようなものでしょう。

ですが、実際にWindows 8 にして、アプリケーションの実行速度は若干低下しています。
（ベンチマークをとれば、すぐに目にわかるぐらいです）

特に、XPから7あたり（8でも構いません）にアップロードすれば
7は速いんだな！って思われがちでしょう。

しかし、実際は、メモリを大食いして、実行速度はほとんどの環境で若干、または、メモリがぎりぎりであれば、めちゃくちゃ遅くなってしまうわけです。

こういうのは、陰謀になってしまうのでしょうか？

＃ただ、Win7 ProにあるVIrtual PCより、Win8にあるクライアントHyper-Vのが、格段に高速化しているのは認めます。。。

そういう意味では、SoftEtherってVPNは、とても素晴らしいとも、考えられてしまうんですよね。。

https://ja.softether.org/

回答No.6

kmee

> 実際に、C:\Users\(username) を D:\Home にしただけでも、
> ごくわずかに (FX-8350 + SSD)で、快適になったというぐらいのもあります。

これは、パスの長さよりも、 CとDにドライブを分けたことの方が効いています。
ドライブ毎にキャッシュがあれば、システムドライブは頻繁にアクセスがあるからキャッシュがあまり有効ではないのに比べて、必要なデータしか読み書きしないドライブではキャッシュが有効に働きますから。

> たとえ、1,000,000,000分の1秒・・であっても、それが
> 複数回あれば・・・
> 0.01秒にもなりえるわけです。

0.01秒=100分の1秒ですから、計算すれば 10,000,000 回比較したら、0.01秒の差として表われる、ということになります。
これを「複数回あれば」と言えるほどの数かどうか。
たとえば、1秒に1000回アクセスがあったとすると、10,000秒(≒2.78時間)で0.01秒の短縮です。
フィルダ名「Documents」を一文字減らすにはどうすればいいだろう?と1秒考えたら、その効果が出るのは278時間後です。

> 例えば、Z80命令でいってしまうと

Z80を持ち出してはいけません。CPUの作り方がまったく違います。
今どきのCPUでは「XXステートで総クロック数がXXだから実行時間はXX」などと簡単に机上の計算ができるようなものではありません。
今風にZ80を作ったのなら、LDIを100個並べるよりも、「速い」命令を組合せたプログラムを作るよりも、LDIR にする方が格段に速いでしょう。

あと。
文字列の比較、階層化されたデイレクトリへのアクセスなどは、アルゴリズムが研究されており、文字列の長さでアクセスが大きく違うようなことは無いように工夫されています。

お礼

ありがとうございます。

strlen のアルゴリズムは、素晴らしすぎるのもあるのですが、
あまり多く文字列比較系のアルゴリズムは、実際にOSのソースを見ても
あんまり変わってないな・・という気もしますが
どうでしょうか？

補足

再びですが・・・

いくら、L1キャッシュの中で動いているであろうとも、
ノイマン型のCPUは、1つの命令を順番に実行していくに
過ぎないはずです。

CPUの高速化は、それらの制限の中から、より高速に動作させるために
キャッシュを付けてみたり、パイプラインにしてみたり、分岐予測を
（HWかSoftwareで）つけてみたりと、いろいろあるはずですが、

今回の質問で、Z80の命令で言えば
LDI
を例に出してしまいましたが
LDI
LDI
LDI

と、

:label
LDI
JR label
jr label
のどっちが速いかという問いに対して、
想定外の答えがでてきました。

LDIR です。（無論知ってますが）

確かに、一気に比較する命令もありますが、
結局、文字列比較で、C言語が使っているのは
(FreeBSDのソースより抜粋）

今でも、大してアルゴリズムが変わっていない

#include <sys/cdefs.h>
__FBSDID("$FreeBSD: releng/10.0/lib/libc/string/strcmp.c 251069 2013-05-28 20:57:40Z emaste $");

#include <string.h>

/*
* Compare strings.
*/
int
strcmp(const char *s1, const char *s2)
{
while (*s1 == *s2++)
if (*s1++ == '\0')
return (0);
return (*(const unsigned char *)s1 - *(const unsigned char *)(s2 - 1));
}

に過ぎないのです (FreeBSDより抜粋）

CPUとの命令の組み合わせで、もっと確かに工夫できる部分はあるのですが、
現時点で、この関数を実行している以上、ディレクトリやファイル名は
（特にキャッシュにある情態で）アクセスが遅くなるとしか
うちとしては、これ以外に理解できません。

みなさんありがとうございました。

回答No.5

wormhole

>うーん、非常に多数のファイルをオープンすると、
>やはり変わるんですよね。（特にサーバーで）

どういうファイルのアクセスの仕方をされてるのかわかりませんが
一度オープンしてファイルハンドルを取得したファイルは、ファイルパスの操作をする事はないです。
オープン・クローズを繰り返してるとかいうなら話は変わりますが。

またWindowsNT系で採用されてるNTFSはB+Treeをベースとした木構造でファイルを管理してますので単純にstrstr相当でファイルを探してるとかではないです。

で・・・これいったいC,C++といったい何の関係が・・・

回答No.4

wormhole

>実際に、C:\Users\(username) を D:\Home にしただけでも、
>ごくわずかに (FX-8350 + SSD)で、快適になったというぐらいのもあります。

WindowsのCドライブはほっといても頻繁にアクセスされてるので、
CrystalDiskMarkなどのストレージベンチマークやってもふつうに遅いですよ。

回答No.3

wormhole

ファイル名が短くなって高速化するのって最初のファイルオープンぐらいしかないですけど。
それに文字数少なくは高速化というよりストレージやメモリの節約の側面の方が強かったような。

お礼

うーん、非常に多数のファイルをオープンすると、
やはり変わるんですよね。（特にサーバーで）

確かに、ストレージやメモリの節約もあるにはあるのですが、キャッシュに収まるだけでも、結構違いますからね。

memtest86+のインチキベンチでも、違いがあるぐらいですし

回答No.2

kmee

ディレクトリ名については、Windowsの文化とも言うべきものです。
UnixやLinuxでは、bin home 等の従来からの短めなディレクトリ名、アカウント名を使う文化を受け継いでいます。

ディスクアクセスは
・ある程度まとめたブロック単位でアクセスする
・途中にキャッシュ等が入る
等で、数バイト短くした程度では速度に影響ありません。

CPUは、いまや1GHz越えが普通です。
1文字比較に1命令として、1文字比較を減らしたら、短くなるのは 1,000,000,000分の1秒です。
数m秒オーダーのディスクアクセスに比べたら、無視できる時間です。

短くすることでほとんど効果が無いのなら、人間が解りやすいように長い名前を使う、というのも、思想としては有りなのではないでしょうか。

お礼

ありがとうございます。

たとえ、1,000,000,000分の1秒・・であっても、それが
複数回あれば・・・

0.01秒にもなりえるわけです。

ディスクアクセス自体は、ブロックで（厳密にはＤＭＡで）転送されていても
実際のディレクトリの比較は、strstr相当なはずです。

C:\Program = C:\Program であるか？ってのを
わずか1ステートで判別できる命令は、今でもないはずです。
(SSEで確かに速くはなりますが、限界はあります）

また、ディスクアクセスがなくても、メモリ上でディレクトリやファイル名の比較等はあるわけですのですので・・・

Windows の場合、レジストリのデータベースは、ある程度メモリにキャッシュされるはずです。

更にCPUにキャッシュされれば、更に高速化されるわけですので
キャッシュにヒットするだけでも、strstr をする時間が、短くなるはずです。

爆速なL1キャッシュなんて、未だに8kbytesだか16kbytesとか64kbytesとか （各コアあたり）しかないわけですしね。

補足

補足欄ですみません・・・

例えば、Z80命令でいってしまうと・・・・ですが

LDIR という、ブロック転送する命令があります。
しかし、これは、回数がわかっていれば

LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI
LDI

（荒らしみたくなってすみません）

のが、はやくなるはずです。

しかし、同じ、回数がわかっていたとしても
64kbytesのL1 Cキャッシュであれば
（LDIは2バイトですので）
LDI を32768回超えると、キャッシュミスが発生するはずです。

もし、それだけの回数をやるのであれば
普通に

XOR A
DEC A
:label1
EX AF,AF'
XOR A
DEC A
:label2
LDI
DEC A
JR Z,label2
EX AF,AF'
DEC A
JR Z,label1
....

とやれば、L1キャッシュに超余裕で収まるので、はやくなるとも考えられます

http://www.systemax.jp/doc/Z80_inst.html#inst_incdec

※Z80の場合、16bit加減算の場合、比較してもフラグが立たないので、こう組むはずです

※実際のZ80にはキャッシュがありませんが、R800には、メモリの256バイトの境界というものがありました。これだけで、結構動作速度が変わります。

回答No.1

hitomura

それが使い物にならないくらい遅くなるのならともかく、数ステート程度では利用者が認識できるレベルではなくなるくらいコンピューターの性能が上がったためでしょう。
そういう状態の現状では 高速化 ＜ 利用者に対しての分かりやすさ とするのは自然の流れでしょう。

お礼

ありがとうございます。

うちの場合、・・・うーん、頭の回転が速いせいでしょうか？

それでも遅く感じてしまいます。

実際に、C:\Users\(username) を D:\Home にしただけでも、
ごくわずかに (FX-8350 + SSD)で、快適になったというぐらいのもあります。