タグ

2013年6月15日のブックマーク (5件)

  • Amazon RDSでできないかも知れないことメモ

    Amazon RDSのrootユーザーからは SHUTDOWN, FILE, SUPER, REPLICATION SLAVE, CREATE TABLESPACEが 取り上げられているので、これでできなくなるであろうことのメモ。 Shutdown_priv mysqladmin shutdownでmysqldをシャットダウンできない。 File_priv LOAD DATA INFILEステートメントが使えない。 SELECT .. INTO OUTFILEステートメントが使えない。 LOAD_FILE関数が使えない。 このページを見ていて知ったんだけれど、mysqldに--secure-file-privというオプションがあって、 これにディレクトリ名を渡すと、 そのディレクトリ{から|に}だけ{LOAD DATA|SELECT .. INTO OUTFILE|LOAD_FILE}でき

  • 第5章 ガ-ベージコレクション

    プログラムの実行時イメージ 突然だが、章を始めるに先立ち、プログラム実行時のメモリ空間の状態につ いて予習をしておこうと思う。この章ではコンピュータの低レベルな部分にか なり踏み込んでいくことになるので、あらかじめある程度の知識を仕入れてお かないと太刀打ちできないのだ。それにこの後の章になればいずれ必要になっ てくる。ここで一回やってしまえば後が楽だ。 セグメント 一般的なCプログラムではメモリ空間の中に以下の部分を持つ。 テキスト領域 スタティック変数やグローバル変数の置場 マシンスタック ヒープ テキスト領域はコードが置いてあるところ。二番目は見ての通り。マシンスタッ クには関数の引数やローカル変数が積まれる。ヒープはmalloc()で割り当てて もらうところだ。 三つめのマシンスタックについてもう少し話そう。マシン「スタック」と言う くらいだから当然スタック構造をしている。つまり

    yass
    yass 2013/06/15
  • 21 メモリ階層

    メモリ階層 RAM(Random Access Memory):理想的には整数(address)で添え字が付けられたN語の記憶領域。取り出しと格納は添え字で指定された語に対してのみ行われ、どちらも同様に早い。 しかし、格納できる語数(大きさ) ←トレードオフ→ アクセスの早さ ⇒ 小さな高速メモリ(高頻度アクセス)と大きな低速(安価)メモリ(その他のデータ)の組み合わせ しかし、この使い分け、管理をプログラマが行うのは大変。⇒ キャッシュ機構 キャッシュ機構の下でプロセッサがアドレスxの値にアクセスする際には: キャッシュをアクセス。 キャッシュになければ(cash miss)主記憶をアクセス。 主記憶の内容をキャッシュにコピー。これで次回からはキャッシュで見つかる(キャッシュ・ヒット、cash hit)。 場所を空ける必要があれば古いものを主記憶に掃き出す。 キャッシュ機構 直接マップ方

    yass
    yass 2013/06/15
    " 世代別コピー・コレクタを用いる際には最若世代を二次キャッシュに収めるようにすべき。(一次キャッシュは狭すぎる。)"
  • プログラミング :: 高速なプログラムを書く為に :: メモリ

    3. メモリ さて、プログラムの最適化で一番重要になってくるのは、メモリです。 はっきり言って、数値計算をするプログラムの一番のボトルネックはメモリアクセスです。 下手なプログラムを書くと、計算時間の殆どがメモリアクセスの時間という事になりかねません。 昔は、メモリの動作速度は高速でその様な事はなかったのですが、 最近では CPU の性能向上が激しく、メモリに追いつき追い越し物凄い差を付けてしまいました。 CPU の動作について行ける様な速さで動作するメインメモリは高価になってしまい作れません。 まあ、値段の問題は抜きにしたとしても、CPU の動作は速すぎます。 これは、少し計算してみれば直ぐに分かります。 今売られている CPU では、コアのクロック周波数が高い物では 4GHz になります。 例えば 4GHz の CPU で 1 clock の間に光が進む距離を考えると、 3×1010

    yass
    yass 2013/06/15
    " 例えば 4GHz の CPU で 1 clock の間に光が進む距離を考えると、 3×1010 [cm/s] / 4×109[Hz] = 7.5 cm になります。 "
  • 普通のアプリケーションのコードに関数定義と関数適用とリテラル以外を書いてはいけない - 標高+1m

    underscore-fix とか Pastaとかを仕事で使ってみていたら、前から薄々感じていた事に確信を持った。 ライブラリが十分に強力なら、プログラム中に関数定義、関数適用とリテラル以外は出てこない。そして逆に、forやifやswitchやnewが必要になったら、その関数は一般化してライブラリに押しやらなくてはいけない。 On Lispだかなんだかのボトムアップデザインの説明で、「アプリケーションを書くための言語を作って、その言語でアプリケーションを書く」みたいな文章を読んだ記憶があるけど、この「言語」っていうのは、別にDSLである必要もLispマクロである必要もなくて、「ライブラリ」って意味と取って問題なくて、それならLisp以外の言語でもこの考え方は重要になる。自分のライブラリが十分に成熟するまでは、なにかアプリケーションを作る度にライブラリ関数を増やすつもりでやらなくちゃいけない

    普通のアプリケーションのコードに関数定義と関数適用とリテラル以外を書いてはいけない - 標高+1m