今のJVMに欠けている物
原文: チャールズ＝オリバー＝ナター 今日ツイッターで、「JVM及びJDKが、あらゆるプログラミングにおいて真にイケてるプラットフォームになる為には未だ幾つかの欠陥が有る」と呟きました。沢山の人から「もっと詳しく」とせっつかれたので、ここに短く書き起こしておきます。勿論、これで全部という訳ではないのでしょうが、今日思いついたのはこれだけです。 ゼロから起動する際のパフォーマンス現存するJVMの起動はかなり速いですが、Java 7でのHotSpot（訳注：Sun及びオラクルのJVM）にはこれをより良くする為の改良が盛り込まれています。普通、こういった改良は、バイトコードを予め検証したり（或いは検証の為のヒントを与えたり）、クラスデータを幾つかのプロセスで共有したり、在り来たりではありますがプログラムのロード時間やリンク時間を短縮する工夫を凝らす事で成し遂げられます。ところが、多くのアプリケー
140行で作る分散リアルタイム検索エンジン（Twitter Streaming API対応） - 古橋貞之の日記
マトモに使えるRPCライブラリ MessagePack-RPC for Ruby のバージョン 0.2.0 をリリースしました！ 新たにコネクションプーリングの機能を追加しました。一度接続したコネクションを共有して使い回すことができます。コネクションを何度も張り直す負荷と遅延を削減でき、リソースの消費も抑えられます。 また、不意に切断されたコネクションを自動的に再接続する機能を導入し、信頼性を向上させています。 これを使って何か作ってみようと言うことで、twitterのリアルタイム検索エンジンを作ってみました。日本語を検索できないなど機能は貧弱ですが、プログラム全体がわずか140行に収まっています（クローラ27行、インデクサ48行、クラスタ管理ノード37行、検索クライアント28行）。 新しいつぶやきを受信するたびに、リアルタイムで転置インデックスを作成していきます。インデックスを作成するノ
Unicorn!
AI & MLLearn about artificial intelligence and machine learning across the GitHub ecosystem and the wider industry. Generative AILearn how to build with generative AI. GitHub CopilotChange how you work with GitHub Copilot. LLMsEverything developers need to know about LLMs. Machine learningMachine learning tips, tricks, and best practices. How AI code generation worksExplore the capabilities and be
IPA、業務システムでRubyを用いるためのチューニング手法と課題を公表 | エンタープライズ | マイコミジャーナル
IPA(情報処理推進機構)は9月7日、「自治体・企業等の情報システムへのRuby適用可能性に関する調査」の報告書を公開した。同調査ではRubyについて、自治体や企業などの業務システムの開発といった分野を想定し、機能面・非機能面からその適用性の評価を行った。 調査を実施したのは、「Enterprise Ruby コンソーシアム(テクノプロジェクト、みずほ情報総研)」。検証環境は、富士通の「Platform Solution Center」に設けられた検証ルームと検証用機器が用いられた。 富士通「Platform Solution Center」のサーバルームと検証ルーム 同検証の目的は、Rubyを用いた「入出力処理」、入出力処理によって構成される「アプリケーションとしての処理プロセス」を想定したベンチマークを取得し、幅広いアプリケーション開発にRubyを用いる際に参考となる計測データやチュー
マルチコア時代の高速サーバーの実装 - Blog by Sadayuki Furuhashi
特にサーバー用途では、CPUがシングルコアに戻ってくることは考えにくい。 マルチコアCPUの性能を活かすにはマルチスレッドに対応したサーバーの実装が必要になるわけですが、マルチスレッドなプログラミングは往々にして「高負荷になると固まる」とか「たまに落ちる」といった悩ましいバグと戦わなければならず、イヤです。 かといってシングルスレッドでは、近い将来 32コアCPU! などが出てきたとき、たぶん性能を発揮できません。 そこで、そこそこデバッグしやすく、それでいて多コアCPUでもスケールするという落としどころを模索しているのですが、ボトルネックはネットワークIO周りにあるだろう*1という前提の元で、ネットワークIO部分だけをマルチスレッドで動かし、それ以外の部分をシングルスレッドで動かすというアーキテクチャを考えています。 ロジックの部分はマルチスレッドで書いても共有リソースにアクセスする度に
RubyにLazySweepのパッチを作った - I am Cruby!
Ruby, GCplanSweepをLazySweepにして、最大停止時間を改善するHeap内のオブジェクト数がある一定を超えてからLazySweepに切り替わる 通常のプログラムのスループットを落としたくないので今は一応100万にしているLazySweepフェイズではHeapの配列の数本を、オブジェクト数が一定になるように選んでSweepする 配列一本ずつのオブジェクト数が異なるため、Sweepの時間がばらつかないように調整したHeapの配列が1.8倍づつ増えるのがメモリ効率的にあんまりよくないので、LazySweepが始まってからは少し抑えるようにした。1.1倍くらい。 理想は「オブジェクトを何百万も作ってプログラムをぶんまわす時の最大停止を改善する。」です。その場合当然スループット性能が低下してしまうのはいかしかたなし。 patchgc_lazy_sweep_r15749_patch
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
