許される配列の限度[雑談?]

[ゆーずぃ]

例えば1Gのメモリ,200GのHDDを積んだパソコンで実行するのが前提だとして、プログラムを組む際に皆さんならどの程度の配列までなら許せますか？

もしくはプログラム中で使用するのはメモリの何％以内とかでもいいです。

(別にbyte数を直接言ってもらってもいいのですが、)とりあえず計算のしやすいchar型を前提でお願いします(人'д｀o)

[Dixq (管理人)]

何をするソフトかによると思うので一概には言えないと思います。
例えば本格的な3Dゲームやモデリングソフト、レイヤーを沢山使う画像処理ソフトなら1G食うこともあるでしょうし
反対に簡単な計算をするツールで1G取られたらたまりません。
使う側も行いたい事に応じてPCを用意するでしょうし、逆にロースペックなら例えば本格3Dゲーなんてしようと思わないでしょう。

まず、ソフトの仕様を示されてはいかがでしょう？

[softya]

メモリ１ＧＢだとＯＳが５１２ＭＢとして、キャッシュや他のアプリとの共存を考えて３００ＭＢぐらいは残したい。ってことで２００ＭＢぐらいが限度。まぁ、メモリ２００ＭＢ使ってるフリーソフトがあったらよほど有用じゃない限り使いません。ゲームなら、３００～４００ＭＢぐらいが上限ですかね。
前提として仮想記憶によるメモリスワップが発生すると重く・遅く・不安定になるので発生させてないって事を第一目的にメモリを決めます。

[へろりくしょん]

配列というのがよく解りませんが、要するにヒープのお話ですよね。

パソコン用のプログラムで、正直なところ意識したことはありません。
必要ならば１Ｇでも２Ｇでも使います。

それで不都合があるのなら、ちょっと考え直します。　その程度です。

以前過去１０年間の為替のチャートデータの分析ソフトを作った際には、軽く１Ｇ程度は確保してましたね。
１分毎のデータを１０年間分となるとそれぐらいは軽くいくのですよ。
必要なところを必要な分だけ、読んでは破棄、読んでは破棄なんてするより一気にどぱっとやってしまった方が、どう考えても楽です。

ケースバイケースだとは思いますが、必要な時に必要なとこだけ効率化を行い、効率化を行わなくても十分なパフォーマンスが得られるのであれば、富豪的プログラミングを行うべきだと考えます。

プログラムコードは短くなり、バグも入りにくくなる。　いいことずくめです。


メモ帳を作った時は、処理速度にこそとても気を使いましたが、メモリに関しては何も考えませんでした。

typedef struct{
    char buf[1024];
    char *sp;
    char *ep;
}LINE;

typedef struct tagPAGE{
    LINE *line[100];
    int sp;
    int ep;
    int useLine;
    struct tagPAGE *next;
    struct tagPAGE *prev;
}PAGE;

typedef PAGE* TEXTBUFFER;

メモ帳のテキストデータを保持する構造体ですが、とても富豪的です。

[ゆーずぃ]

>管理人さん

これから先色々な物を作っていく上での指針＆参考にしたいので、とくにこれといって仕様はないのです(；＾ω＾)例をいくつか挙げてもよかったのですが、それだと自分の知らない分野の話が出なくなってしまうので、出来れば自由に語ってもらいたかったのです。

＞softyaさん

確かに、OSの確保領域位は決めておいてもよかったかもしれませんね。ではOSは512MBを目安にしましょ(o´・∀・｀o)

なるほど、メモリスワップまで考慮したことはなかったですね。勉強になります！

＞へろりさん

＞必要ならば１Ｇでも２Ｇでも使います。
富豪的ですねｗ小心者な自分では、メモリでも”もったいない病”が出てしまうのでうらやましいですｗ


＞必要なところを必要な分だけ、読んでは破棄、読んでは破棄なんてするより一気にどぱっとやってしまった方が、どう考えても楽です。

確かにそっちの方が楽なんですよねー。でも速度を考えるとどうなんでしょう？確かに一気に読んで一気に出した方が早い感じはあるのですが、実際の　メモリ：速度比　ってどんな感じなんでしょうね？

[へろりくしょん]

>確かにそっちの方が楽なんですよねー。でも速度を考えるとどうなんでしょう？確かに一気に読んで一気に出した方が早い感じはあるのですが、実際の　メモリ：速度比　ってどんな感じなんでしょうね？

規格やハードによってまちまちなので具体的な数値は控えますが、私の環境では以下のコードを走らせた結果は

HDD : 10530
MEM : 63

となりました。　圧倒的な速度差です。

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <memory.h>

int main(void)
{
    clock_t start, end;
    int i;
    char buf[1024] = {0}, *tmp;

    //ＨＤＤへ読み書き共に５万回
    start = clock();
    for(i = 0;i<50000;i++){
        FILE *fp = fopen("hoge.txt", "wb");
        fwrite(buf, 1, 1024, fp);
        fclose(fp);

        fp = fopen("hoge.txt", "rb");
        fread(buf, 1, 1024, fp);
        fclose(fp);
    }
    end = clock();
    printf("HDD : %d\n", end - start);

    //メモリコピーを１０万回
    start = clock();
    for(i = 0;i<100000;i++){
        tmp = malloc(1024);
        memcpy(tmp, buf, 1024);
        free(tmp);
    }
    end = clock();
    printf("MEM : %d\n", end - start);

    return 0;
}

この検証でいいのかわかりませんが。


より低コストで、コストパフォーマンスの高いプログラムを書くのは、腕の見せ所で楽しいところの一つだと言うのは解りますが、そのためにトリッキーな手法を用いたり、泥臭いコードを書いたりするのは可能な限り避けるべきだと思いますよ。　大変だし、バグも入りやすくなりますし。

[softya]

１ＧＢを前提にメモリ量の目安をもう幾つか書いておきます。
常駐するソフトの場合は、上限は２０ＭＢ程度だと自分で決めています。これでも大きい方ですけどね。大半の常駐ソフトは１０ＭＢ未満です。

FireFoxとかは２００ＭＢぐらいを平気に使いますが、結構ほかのソフトを事を考えると厳しいです。これでVisualStudioを起動した場合にはセットで合わせて３００～４００ＭＢぐらい持って行かれますよね。
そこに５００ＭＢもあるようなソフトをデバッグしたら確実にメモリスワップします。なのでデバック中大容量メモリを使うとデバッグが困難になりますね。

へろりさんの言うことは一理あるというか使い方を間違えなければ正しいです。確保した大量のメモリ空間に対してシーケンシャルにアクセスする場合や単位時間あたりにアクセするメモリ量が少ない場合には、メモリスワップが発生していても大した速度低下は発生しません。逆にデータベースの様にランダムに大量のメモリにアクセスをする場合は、省メモリを考えないとメモリスワップの悪影響をもろに受けます。

フリーソフトでの配布を考えた場合は、使う人がメモリが足らなくなるような状況は避けるべきだと思います。ビデオ圧縮ソフトとか速度優先の場合は別ですよ。それ以外の場合はメモリを食うソフトは嫌われますからね。
使う人の事を考えて、ほかのソフトと共存共栄できるメモリ量を目指してソフトを作ったほうが良いというのがわたしの考えです。

[へろりくしょん]

softyaさんの意見には大いに賛成します。

>ケースバイケースだとは思いますが、必要な時に必要なとこだけ効率化を行い、効率化を行わなくても十分なパフォーマンスが得られるのであれば、富豪的プログラミングを行うべきだと考えます。

と、先のレスで申し上げた通り、ただ闇雲にメモリ効率を求めるべきではなく、メモリの効率化を図る事で、実行速度や可読性、プログラムの保守性や堅牢性など、トレードオフ的に潤沢な資源に頼れるところは頼ってしまっていいじゃないか。　ということです。

無駄遣いはよくありませんが、必要ならば１Ｇでも２Ｇでも使うべきだと考えます。


追記です。

No:56570 で書いたテキストデータを保持する構造体ですが、このデータ構造ではファイルサイズで大体数十ｋｂ程度のテキストファイルを読み込むと、１ＭＢほどのメモリを必要とします。
ファイルサイズの実にン十倍ものメモリ量です。　これを無駄遣いと感じるかどうかは人それぞれだとは思いますが、テキストデータですから、編集作業を考慮した結果のデータ構造がこの形です。
その結果、要求メモリがファイルサイズのン十倍になろうがそれは必要なことだと考えます。

そもそも、プログラムが使うメモリは、搭載されているであろうメモリ量から決めるのではなく、
プログラムが扱うデータ量から決めるべきものではありませんか。　いかがでしょう。

[ゆーずぃ]

>へろりさん

実際に検証して頂いてありがとうございます！色々な検証方法があるとは思いますが、これだけの違いが出るというのは肝に銘じておかなければなりませんね。
トリッキーすぎると可読性も悪くなりますしね、反省することしきりです(；＾ω＾)

＞そもそも、プログラムが使うメモリは、搭載されているであろうメモリ量から決めるのではなく、
　プログラムが扱うデータ量から決めるべきものではありませんか。　いかがでしょう。

賛否両論でしょうが、

>ケースバイケースだとは思いますが、必要な時に必要なとこだけ効率化を行い、効率化を行わなくても十分なパフォーマンスが得られるのであれば、富豪的プログラミングを行うべきだと考えます。

との言葉と合わせると、真を得た言葉だと思います。


＞softyaさん

＞１ＧＢを前提にメモリ量の目安をもう幾つか書いておきます。
　常駐するソフトの場合は、上限は２０ＭＢ程度だと自分で決めています。これでも大きい方ですけどね。大半の常駐ソフトは１０ＭＢ未満です。


常駐ソフトは作ったことが無かったので、そーゆーお話をして頂けるとありがたいです＾＾

＞確保した大量のメモリ空間に対してシーケンシャルにアクセスする場合や単位時間あたりにアクセスするメモリ量が少ない場合には、メモリスワップが発生していても大した速度低下は発生しません。逆にデータベースの様にランダムに大量のメモリにアクセスをする場合は、省メモリを考えないとメモリスワップの悪影響をもろに受けます。


速度については常々悩んでいますが、そこを考えたことはなかったです。自分もすぐにそこまで考えつくように精進したいです！


＞使う人の事を考えて、ほかのソフトと共存共栄できるメモリ量を目指してソフトを作ったほうが良いというのがわたしの考えです。

そうですね、使い手はそのソフトだけを起動させるわけじゃないですもんね。とても含蓄のある言葉です。