サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
ブラックフライデー
gist.github.com/sile
main.md 2025年の趣味開発環境 2025年は趣味開発環境の変化が大きかったので備忘録として残しておく。 前提: 趣味開発はほぼ毎日している 開発するのはコマンドラインツールやライブラリが多い 言語はほぼRust 開発はほぼAndroid上 GUI 系ツールは基本使わない（GitHubをブラウザで見るくらい） 仕事の開発環境はまた別（このgistの対象外） ハイライト E Inkタブレットでの開発に移行 Emacsから自作エディタへの移行 2025/12/14時点での趣味開発環境 ハードウェア: Viwoods AI paper: Androidの10インチタブレット Voyager keyboard: 有線分割キーボード Androidアプリ: Termux: Linuxターミナルエミュレータ Unexpected Keyboard: プログラミング向けのソフトウェアキーボード
README.md 概要 Optunaというハイパーパラメータ最適化ツールを使って、RocksDB(組み込みDB・KVS)のパフォーマンスチューニングを試してみた際の結果メモ 対象となるワークロードに対して、最適な性能を発揮するパラメータ群を自動で見つけ出すのが目的 結果としては、デフォルトパラメータをそのまま使った場合に比べて、かなり良い性能が得られるパラメータ群を見つけることができた: デフォルトでのベンチマークの所要時間: 372秒 Optunaによる最適化後のパラメータでの所要時間: 30秒 モチベーション RocksDBには、カスタマイズできるパラメータ群が多数ある（数十～数百？） 自分の利用用途に最適なパラメータ群を人手で調べるのは結構大変 RocksDBは、チューニングガイドを含めて、かなりドキュメントが充実しているが、それでも不慣れな人には敷居が高い ↑のような状況は、Ro
README.md 概要 Optunaというハイパーパラメータ最適化ツールを使って、FFmpegでの動画エンコードパラメータの最適化を試してみた結果のメモ 具体的には、決められた制約(後述)下で、画質(SSIM)を最大化するようなパラメータ群を自動で見つけ出すのが目的 結果としては、 画質的には、FFmpegが提供しているプリセットの中で二番目に重いもの(slower)より若干良い程度のパラメータ群が見つかった また、Optunaが見つけたパラメータ群の方がslowerに比べて、CPU負荷が小さかった 方針 時間と計算資源はそこそこ潤沢にあるものと仮定し、その中で「各動画のエンコード」を最適化したいとする 各動画毎に、最適なエンコードパラメータ群を都度決定するようなユースケース 動画の種類毎(e.g., スポーツ、アニメ、ニュース、実況、3D)にパラメータを分けたい、的なものの発展形 問題
rfc_2113.md RFC 2113: dynトレイト構文 Start Date: 2017-08-17 RFC: http://rust-lang.github.io/rfcs/2113-dyn-trait-syntax.html PR: rust-lang/rfcs#2113 Issue: rust-lang/rust#44662 要約 トレイトオブジェクトのためにdyn Trait構文を導入 "bare trait"構文は非推奨扱い dynキーワード: 最初は文脈的(contextual) 将来的には真のキーワードにする 動機 現在の構文は、しばしば曖昧で紛らわしい 以下の例のように、トレイトとトレイトオブジェクトの見た目が区別できない: impl<T> SomeTrait for T where T: AnotherTraintとすべきところで、Impl SomeTrait f
rfc.md RFC 2033: experimental coroutines Start Date: 2017-06-15 RFC: https://github.com/rust-lang/rfcs/blob/master/text/2033-experimental-coroutines.md PR: rust-lang/rfcs#2033 Issue: rust-lang/rust#43122 関連: RFC 2394 要約 コルーチンをRustに導入するための実験的なRFC 正式なものはまた別のPRで コルーチンに対するアイディアの共有とnightlyで試せるようにするのが目的 動機 Rustの2017年のロードマップの中では頑強でスケーラブルなサーバを書けるべきという項目があった: ただ最近の調査では、非同期I/O処理(e.g., futures, tokio)の書き難さがネ
time-clocks.md Time, Clocks, and the Ordering of Events in a Distributed System http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf の要約。 著者はレスリー・ランポート (Leslie Lamport), 1978年。 分散アルゴリズムの書籍や論文でお馴染みの、分散システムにおけるイベント群の順序や時刻の概念を説明している論文。 ! が先頭についている箇所は、要約者による(いい加減な)注釈。 ! 資料作成の便宜上、記号や記法が、元論文と若干異なることがあるので注意。 ! 後半の要約はだいぶ怪しい... 導入 (Introduction) 時間の概念は、思考の際の基礎となるもの: これは「イベント群の発生順序」という
0_succ_bp.md 発表資料メモ: 簡潔データ構造について 主題 数千万オーダーの文字列集合(およびマップ)を如何にサイズ効率良く表現するか、の話 諸事情で集合をメモリ上に保持したいことがあるが、サイズは節約したい 実際にはサイズのみを追求するのではなく、諸々のトレードオフを加味しつつバランスを取る 今回はそれを実現するための方法の一つである 簡潔データ構造 について説明する: どういったデータ構造(のクラス)であるかの紹介 一言でいうなら「木構造を情報理論的な下界に近いサイズで表現するためのデータ構造」 性能特性の提示 簡潔データ構造の一つであるBalancedParenthesesについては、ある程度掘り下げて説明する 静的構築前提 亜種や類似手法の紹介(余裕があれば) ポインタの重さを知って貰う 注意 筆者はこの分野に特に精通している訳ではなく、用語や細部はいろいろと怪しいので
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
このページを最初にブックマークしてみませんか？
『sile’s gists』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
