Python 3.11の新機能(その3）関数呼び出しのインライン化 - python.jp
Python 3.11では、パフォーマンスチューニングの一環として、Python関数呼び出しのインライン化 が行われました。既存のPythonインタープリタのしくみを大きく変更する変更ですので、簡単に解説しておきます。 先に書いておきますが、今回行われた「関数呼び出しのインライン化」は、C/C++などの inline のように、ユーザ定義関数を呼び出し元で展開してオーバヘッドを削減するものではありません。また、Schemeなどにある末尾再帰の最適化でもありません。 cevalループ¶Pythonインタープリタは、Python 3.11の新機能(その2） 特殊化適応的インタープリタ で解説したように、Pythonのソースコードをバイトコードへ変換し、順次実行します。このバイトコードを実行する関数はPythonインタープリタの心臓部であり、CPythonソースツリーのファイル Python/c
入門ガイド — Google Test ドキュメント日本語訳
はじめに：なぜ Google C++ Testing Frameworkを使うのか¶ Google C++ Testing Framework を上手に活用すれば，より良い C++ のテストを書くことができます． Linux，Windows，そして Mac，あなたが C++ のコードを書いているこれらの環境に関係なく Google Test を利用できます． では，優れたテストを書くにはどうすればよいのでしょうか？Google C++ Testing Framework は，どのように役立つのでしょうか？我々は次のように考えています： テストには， 独立性 と 再現性 が必要です．別のテストの結果に依存して成功したり失敗したりするテスト，をデバッグするのは非常に面倒な作業です．Google C++ Testing Framework は，各テストを異なるオブジェクト上で実行することによって
Solving PDEs in Julia
div.ProseMirrorSolving PDEs in JuliaJuliaCon 2018 workshopChris Rackauckas How are finite elements, multigrid methods, ODE solvers, etc. all the same topic? Teach a man to fish: we won't be going over pre-built domain specific PDE solvers, instead we will be going over the tools which are used to build PDE solvers. While the basics of numerically solving PDEs is usually taught in mathematics cours
並行プログラミング入門
複数のプログラムを同時に実行する「並行プログラミング」は、処理速度を飛躍的に向上させる手法で、タスク管理、プロセス管理、スレッド管理をはじめ、複雑な仕組みについての幅広い知識とテクニックが必要となります。本書はRustとアセンブリ、そして一部Cを用い、CPUのアトミック命令、グリーンスレッド、アクターモデル、π計算、ソフトウェア・トランザクショナルメモリ、async/awaitなど、並行プログラミングに関する理論的な背景から実装までをカバー。さらに、アセンブリ実装の理解を深めるため、AArch64とx86-64アーキテクチャの説明も付録として収録。一歩一歩、着実に理解できるように、その仕組みから順を追って詳しく説明します。GitHub上で公開されているソースコードを実際に動かしながら、並行プログラミングの知識と理解を深めることができます。 関連ファイル サンプルコード 正誤表 ここで紹介す
ジェネリクス引数の構文的曖昧性まとめ
ジェネリクスを持つ多くの言語では括弧の種類が足りなかったり、既存の文法との互換性を保つために <> をジェネリクス引数に使っている。この文字は比較演算子やシフト演算子にも使われるため、多くの場合は構文的曖昧性の問題がある。 // ジェネリクス引数 (convert<int, string>(number)) // 比較演算子 (score < MAX_SCORE, score > (MIN_SCORE)) 各言語でこの問題をどのように解決しているか調べる。 関連する問題として < > を含むトークン (<<, >> など) をどう分割するかという問題があるが、こちらは本スクラップでは扱わない。
noexcept - cpprefjp C++日本語リファレンス
概要 C++11で導入されたnoexceptキーワードには、以下の2つの意味がある： ひとつは、throwキーワードによる例外仕様の代替。関数がどの例外を送出する可能性があるかを列挙するのではなく、例外を送出する可能性があるかないかのみを指定する。例外を送出する可能性がある関数にはnoexcept(false)を指定し、例外を送出する可能性がない関数にはnoexcept(true)もしくはnoexceptを指定する： class Integer { int value_ = 0; public: // getValue()メンバ関数は、例外を送出しない int getValue() const noexcept { return value_; } }; noexceptキーワードのもうひとつの意味は、式が例外を送出する可能性があるかどうかを判定する演算子である。noexcept(f(ar
Rustで数値計算してみた話 - Qiita
修士・博士課程時代 流体の直接数値計算 C++でシミュレーションを実装 Pythonで可視化＋統計量の解析(on Jupyter) データはmsgpackで保存 データ同化の研究を始める 既存のコードベースを廃棄 Pythonで実装を始める NumPy/SciPy使用 Python遅い(´・ω・｀) Pythonでは関数の呼び出しがインライン展開できない 汎用性高く実装できない でも、もうC++は書きたくない コンパイルに１分かかるのはちょっと・・・ 何で書く？ Haskellで書いてみた ものすごく遅いコードが出来上がった（涙） 配列を部分的に書き換えていくコードが書きづらい コンパイル遅い GoかRustか Goが流行ってるのでRustにした Rustを覚える C++の不満点が解消されている ビルドシステム(cargo) moveが自然に導入 template -> traits (c
Katsurada Labo. Text
桂田研卒研ノート 主に数値計算法を中心に、 過去の卒研や院生ゼミで扱った題材についてまとめた (寄せ集めた) ものです。 (こんなの書きたくないのですが、 数値計算関係は学生が迷子になってしまう本が多くて…) プログラムについては、 「公開プログラムのページ」 を探した方がよいかも。 また、コンピューターの使いこなしについては、 「桂田研KnowHowページ」が参考になるかも。 最近は内輪向けのノートが多くなって、それらは毛色が違うので、 ここには載せていません (卒研資料室というところに置いてあります)。 新し目の更新 『定数係数線形常微分方程式の解の漸近挙動』 (2022/3/2) 「常微分方程式の初期値問題を解くプログラムの書き方」(2021 April) 「Julia メモ」 (2019/12/2) 「乱数とつきあう」 (2019/6/22) 「Eigen を使って常微分方程式の初
valgrindでC/C++のメモリリークを発見する - Qiita
==23525== Invalid free() / delete / delete[] / realloc() ==23525== at 0x1000089DF: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so) ==23525== by 0x100000F4F: main (sample.c:8) ==23525== Address 0x10081f510 is 0 bytes inside a block of size 4 free'd ==23525== at 0x1000089DF: free (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwi
C言語のinline - 簡潔なQ
C/C++のinlineで間違いやすい3つのポイントがある。 1つは、GCCは3種類の異なるinline仕様を使い分けているという点である。3種類とは、「C++のinline」「C90用のGCC拡張inline」「C99以降のinline」である。 2つ目は、inlineを使っても、コンパイラが必ずインライン化を行うとは限らないという点である。 3つ目は、inlineを使うときは、プログラマは必ず、コンパイラがインライン化を行えるように特定の配慮をしなければいけないという点である。 つまり、inline関数は、「実体がどこにあるか」「inline化のための情報が足りているか」という2つの状態を同時に制御する必要がある。この細かい扱いの違いがバージョンにより異なるということになる。 以下バージョンごとの解説。おそらく歴史的な導入順序とは逆になっている。 C99以降のinline C99以降の
デジタル・フロンティア-Digital Frontier | DF TALK | 画質評価アラカルト ～SSIMってすごい！～
2015/8/10 Tag: C++,jpg,画像処理,画質評価 こんにちは。開発部の高山です。 明日(8月11日)は山の日ですね！と書こうと思いましたが、実際に施行されるのは2016年からなんですね。最近知りました。 今回も業務とはあまり関係ない画像処理系のネタをやっていきますよ。 画質評価とは？ 画像を適当な形式で保存したり、拡大縮小等の画像処理を繰り返していると元の画像とは異なる、劣化したようなものになってしまうことがあると思います。 では、実際どの程度異なるのか？というのを数値化するのが今回のテーマです。 画質評価や画像評価などと呼ばれています。 これが使われる例としてはjpgなどで画像圧縮をした場合、圧縮前の画像からどの程度劣化しているかを計りたい時ですね。 画像や動画は圧縮して容量を減らす場合も多いと思われますが、圧縮すればするほど基本的には劣化が激しくなってしまいます。 では
C++ is faster and safer than Rust: benchmarked by Yandex
To get the licence for your open-source project, please fill out this form
貪欲ライフゲーム - Qiita
（4x4の探索の様子） 長寿命パターンを探ろうのコーナーです 総当たりするのですが計算量が2^nになるので終わりが遠いです subsequencesが全パターン列挙を担っています それをevalが寿命を計算し、searchが寿命を比較してより長寿命のパターンを保持します use std::time; use std::thread; type Cells = Vec<Vec<bool>>; // コンウェイさんのルール fn rule(c: bool, n: u8) -> bool { match (c, n) { (true, 2) => true, (true, 3) => true, (false, 3) => true, _ => false } } // 年齢を重ねる fn next(cells: &Cells) -> Cells { let mut new = cells.cl
Rust でグラフ構造や木構造を作る - 右上➚
プログラムを書いていると何かしら木構造っぽいものやグラフっぽいものを作りたい場面が多々あると思います． Rust は所有権や Size の都合で，これらを作ろうと思うと地味にハマるのでまとめておきます． Rust で木構造 最も単純な木構造は Rust だと enum Tree<T> { Leaf(T), Node(Box<Tree<T>>, Box<Tree<T>>), } といった形で表せます． Rust では明示的に boxing してあげないと再帰的なデータ構造は作れないのでちょっと複雑に見えるかもしれませんが，まぁ単純です． この木構造を書き換えたい場合は，ownership をとって書き換えた値を返すこともできますし，&mut Tree<T> をとって in-place に書き換えることもできます． fn inc(&mut self) { match *self { Tree:
Static Analysis at Scale: An Instagram Story
Instagram Server is entirely Python powered. Well, mostly. There’s also some Cython, and our dependencies include a fair amount of C++ code exposed to Python as C extensions. Our server app is a monolith, one big codebase of several million lines and a few thousand Django endpoints [1], all loaded up and served together. A few services have been split out of the monolith, but we don’t have any pla
過去のブーム（並列プログラム）の現状を考える
みんな割と未来の予言はよくするが、あんまりその結果を振り返らんよなぁ。 現在のディープラーニングのブームをどう捉えるか、というか、 プログラマのキャリアという点でどう接していくか、を考えるにあたり、 過去のブームを考えてみるのは良いんじゃないか、という気がした。 最近並列GCや並行GCの章を読んでいて、 一昔前の大きなブームとしてはParallel computingがあったなぁ、と思い出した。 ということでこの事について、専門にしてなかった部外者プログラマの目にどう映ったかを記しておきたい。 なお、「XXXだと言われていた」はあんまりソースとかを確認したりはしてません。 なんとなく自分はそう聞いていた気がしたしそう思ってた、程度のものです。 かつて思っていたことと当時の状況 Parallel computingはだいたい10年くらい前の時点ではその後の大きなトレンドとして明らかに存在して
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
FUNCTIONAL PEARLS Monadic Parsing in Haskell
Towards Verified Stochastic Variational Inference for Probabilistic Programs
Making Your Code Faster by Taming Branches
Autotools Mythbuster