「プログラミングの常識」を時々見直す必要性について｜Rui Ueyama

自分の中のプログラミングの常識というものは、ときどき現実のハードウェアに合わせて調節しないといけない。ハードウェアが進歩し続けているので、コンピュータで簡単にできることと相対的に難しいことのバランスが変化し続けているからだ。ここでは特にストレージにフォーカスして書こうと思う。 昔はメモリが相対的にとても貴重な資源だったので多くのプログラマがメモリを節約することに血道を上げていた。例えばWindowsの初期の頃に設計されたデータ構造には、メモリをバイト単位ででもいいから節約したいという意図の痕跡がいまでも多く見受けられる。DRAMの次に速い記憶装置はHDDだったので、メモリが足りなくなればHDDにデータを保存せざるを得ないのだが、DRAMとHDDのランダムアクセスの速度差は、机の上の本の開いているページを見るのと、その本をAmazonで注文して到着するのを待つのと同じくらいのスケールで違うの

[nakag0711]

エンジニアは猫に釣られやすいという常識は見直す必要がない

[sds-page]

「Variant型多用とかダサすぎ」って言われてたかと思えば「型宣言要らないPythonちょうクール！」って言われたり「型宣言必須だし暗黙の型変換は悪」みたいな言語がまた出てきたりよくわからん

[matsumoto_r]

過去には筋が悪いと言われたアプローチでも時代背景を通してこういう考察をしていくべきであることに完全に同意だし、ムーアの法則の限界や電力効率についても今後気にしていくべきだなと思っている

[sonots]

例えが良いけど、この amazon の配達にかかる時間も時代背景によって認識が変わっていきそう

[shioken]

2009年のnaoyaさんのブログでも似たような話があったことを思い出した。 http://d.hatena.ne.jp/naoya/20090412/btree

[YaSuYuKi]

逆に、これからどんなリソースが安くなるか考えるのもいい。たとえば、マルチスレッド性能は(これまで以上のペースで)安くなりそうだ

[t-murachi]

常識っつーか、思いこみで判断しないで必要に応じて設計見直し＆ベンチマークとって確認しろって話であって、理論的に正しいとしてもこうした方がパフォーマンス高いはずっつっていきなり困難な設計選ぶのが一番危険

[kazutomo]

その結果、1タブ1GB食うブラウザが誕生したのであった。

[Dolpen]

見直すんじゃなくて、常に計測ベースで始めるようにすれば落とし穴は回避できそうな気がする。

[jaguarsan]

最近の話だと月末は通信量制限でキャリアがパケット捨てるから負荷が超高いとか出てたな

[massa142]

“多くの場合、凝ったアルゴリズムは局所性が悪いので、理論的には速い凝ったアルゴリズムを考案してみても、配列などを使った単純だが効率の悪そうなアルゴリズムに勝つことは結構難しい”

[Carimatics]

ハードウェアを気にせずアプリケーションを開発できるのが理想ではあるけど、現実はそう上手くいかないよなぁ、という話

[at_yasu]

ストレージたくさんあるからなんでもログに残したろ、と残したら一日1G〜2Gのテキストファイルが出来上がっていく日々になるので、バランス大事。

[natroun]

自分とは直接無縁の話だけどかなり面白かった。貧乏プログラミングと富豪プログラミングのその先、みたいな感じか。

[Iridium]

ArrayListに対してHashMapってどのくらい遅いんだろう…。ってそれを気にするようなコード書いてなかったや。

[jumperson]

ハードウェアに合わせてプログラミング設計しなければいけない話。

[Kirche]

"パフォーマンスに関する意見は短命なものです。パフォーマンスに関する助言に出くわしたときは、それを事実として受け入れる前に、それが時代遅れではないかという疑問を持ってください。" https://goo.gl/R1AFNi

[you21979]

「JavaでArrayListを使うほうがLinkedListを使うより大抵ずっと速いのはこのためだ」メニーコアが当たり前になったころからlinkedlistは目に見えて効率が悪くなったから小さいメモリではもうやらないようにしている

[ooblog]

「凝ったアルゴリズムは局所性が~HDD~本をAmazonで注文~SSD~隣の部屋の本棚~DRAM~机の上の本の開いているページ~キャッシュ~覚えている~昔はメモリ~貴重な資源~現代では~メモリに読めばいい」

[kiyo_hiko]

"現代のプロセッサはメモリの局所性が悪いプログラムに対しては本来の性能が全然発揮できない…ArrayListを使うほうがLinkedListを使うより大抵ずっと速い" ArrayListって実体部分が確か配列だったからデータ固まってて有利と

[masakih]

時代が富豪プログラミングに追いついてきた

[takatama]

大事な視点。ハードウェアの縛りで、凝ったアルゴリズムが速くならないことはざら

[mohri]

おもしろい

[pmint]

これは仕事を遅らせるタイプの発想。素直な設計が先。/ 1メソッドあたりの行数制限やシステムハンガリアン、Java使いがよくやる「privateなオブジェクト変数をpublicなアクセサーで読み書きする」といった話かと思った。

[snowlong]

“不必要に苦労しているケースがいまでも多いような気がするが（一気にメモリに読めばいいのにわざわざデータベースを使っているとか）”

[sisimaru_440]

例えが上手

[kompiro]

コンピュータアーキテクチャの話で面白かった

[stilo]

『昔の常識は今の常識ではないし、今の常識は未来の常識でもない。常にどういうバランスでプログラムを書くのがよいのか自分の中で調整していくことが大切だ。』

[inazakira]

組み込みで未だC言語の職場だけど、ここ10年でARM系に統一されRAMとROMサイズは増えかなり制約は緩くなったね。そろそろLINUX行っちゃう？って雰囲気で、最近のC++わっかんねーってなってる。

[light940]

“HDDがAmazonに本を注文するくらいの遅さだとしたら、SSDは隣の部屋の本棚から本を探してくるくらいのスケールで速い”

[komo-z]

ハードウェアが変わると、ハードウェアに最適なソフトウェアも変わる。時代が変われば、常識も変わる。言われてみれば当たり前だけど、常識と思い込んでる部分は、意識して見直さないと常識外れになっちゃうね。

[ardarim]

最近はXOR eax, eaxみたいな小技覚えなくてもいいんだよとかそういうやつ？

[mumumu-tan]

多くの場合、凝ったアルゴリズムは局所性が悪いので、理論的には速い凝ったアルゴリズムを考案してみても、配列などを使った単純だが効率の悪そうなアルゴリズムに勝つことは結構難しい。

[yumu19]

うむ。

[slash_01]

とても良い教訓。

[lbtmplz]

楽しいね

[sgo2]

実際に2Gbyteの壁にぶち当たるまで、メモリが足りなくなる事態なんぞ起こり得ないと思っていました。(高解像度化等でデータが増えた反面、32bit環境が健在だから案外簡単に突破する)

[zu2]

“多くの場合、凝ったアルゴリズムは局所性が悪いので、理論的には速い凝ったアルゴリズムを考案してみても、配列などを使った単純だが効率の悪そうなアルゴリズムに勝つことは結構難しい”

[shotazc]

L1キャッシュは覚えているくらい。例え話が楽しかった。

[mohno]

そりゃそうだろうな。とりあえず計測せずに感覚でパフォーマンス向上させようとするのはよくない（というのは割と普遍的な常識だと思う）