タグ

performanceとprogrammingに関するhonamisのブックマーク (5)

  • 先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか?

    回答 (25件中の1件目) 令和だろうがなんだろうが意識はしてないとダメだと思いますよ。 ハードウェア資源の限られた組み込み系やゲーム系は別として、業務系でもWeb 系でも 1バイトでも少なくなるように無駄を削るみたいなことはしなくてもいいでしょうし、たいていは解放漏れも意識しなくて良くなってます。 昭和〜平成初期のハードウェア/ ソフトウェア事情から考えれば、およそ足りなくなることが考えられないような大量のメモリーを使えはしますが、無限ではありません。 メモリー搭載量は予算次第で増減しますしね。 そして使えるメモリーの量よりも知識や想像力の欠如、考えなしのプログラミングからくる...

    先輩エンジニアから「メモリを意識してプログラムを書かないやつは三流だ」と言われたのですが、今は令和ですよと言いたかったです。メモリを意識してプログラムを書く必要性を分かりやすく教えて頂けませんか?
  • Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ

    こんにちは。アプリケーション基盤チームの横田です。 Javaの謎のパフォーマンス劣化にまつわる調査をしていたのですが、1ヶ月の苦労の末に原因がわかりましたので、報告させていただきます! 公開後に頂いたはてなブックマークでのご指摘・社内でのタイポ・読みにくいなどの指摘を受けてたので、謹んで修正させいただきます。 修正した内容につきましては、記事の最後を参照してください。 忙しい人のためのまとめ jdk-7u4以降のjdk-7 *1 でJavaのパフォーマンスが劣化する謎の現象 CodeCacheの容量限界に近づくとJITコンパイラを停止してコンパイルしたコードを捨てる機能が原因だった 起動オプションで回避できるので、長期運用するときは -XX:-UseCodeCacheFlushing, -XX:ReservedCodeCacheSize=128m をつける 上のオプションを設定した時に、C

    Javaの謎のパフォーマンス劣化現象との戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
  • Javaのパフォーマンスについての9つの誤信

    JVMはプロファイリングを利用してコードの最適化を行います。対象は頻繁に利用されるコードパスのみですが,徹底的に行うことで大きな効果を上げています。JITコンパイルされたコードに関しては,現在では多くの場面において (その割合も増えつつあります) C++の実行速度を凌駕しています。 このような事実にも関わらずJavaが今でも低速なプラットフォームとして認識されているのは,おそらくは初期バージョンのJavaプラットフォームでの経験が,歴史的な負のバイアスとして働いているためでしょう。 早まった結論を出す前に,客観的な見地に立って,最新のパフォーマンス結果を評価するようにお勧めします。 2. Java コードの1行にはそれ自体で意味がある 次の短いコード行を考えてみてください: MyObject obj = new MyObject(); Java開発者ならば誰でも分かるように,このコードはオ

    Javaのパフォーマンスについての9つの誤信
  • C#とCGアプリの相性について - カタチづくり

    etopirika5 さんが下記のように書かれているので、http://www.quatouch.com/products/hisui/index.html を作っている者として、ちょっと反応してみるよ。 C#は業務用の小さなアプリケーションをちょこっと作るには最適だと思うのですが,一年間かなり使ってみた結果CGアプリや数値計算アプリを作るには全く適していないことがはっきり分かりました. http://d.hatena.ne.jp/etopirika5/20100612/1276299740 僕としては「全く適していない」とは思ってないのだけれど、でも etopirika5 さんがそう思われるのもよく理解できる。 氏は研究者。研究者というのはとても厳しい職業だなあと以前から畏敬の念をもって見上げているのだけれど、彼らは「世界一じゃないと存在意義が示せない」人達なのだ。たとえ狭い分野であろう

    C#とCGアプリの相性について - カタチづくり
  • Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのか

    多数のTCP接続をハンドリングするサーバを書くなら、1コネクション1スレッドのモデルではなく、epollやkqueueのようなイベント駆動型のI/O多重化を行うべきだ、と言われます。だが、そのような主張は、「C10K問題」が書かれた2002年から7年経過した今でも有効なのでしょうか? echoサーバを書いて、ベンチマークを取ってみることにしました。 ふたつのグラフは、いずれも接続数とスループットの関係を表しています。最初のグラフは、全接続がアクティブに通信した場合、あとのグラフは、全接続のうち小数のコネクションが順次アクティブになっていく、というモデルです。これらのグラフから、以下ようなことが読み取れます。 epoll も per-thread モデルも、良くスケールする epoll は、ワークセットが小さい場合に (最大50%) per-thread モデルよりも高速 少なくとも、1コネ

  • 1