コンパイラによるリンク時最適化(Link Time Optimization) - Qiita
はじめに 一般に、コンパイラによる最適化は局所的であればあるほど効きやすい。例えば同じ関数内ならできる最適化が、グローバル変数がからむとできなくなったり、ファイルをまたぐとできなくなったりする。しかし、最近はリンク時最適化(Link Time Optimization, LTO)と呼ばれる、異なるオブジェクトファイル間にまたがる最適化ができるようになってきた。 ここではいくつかの例で、リンク時最適化として何ができるか紹介してみたいと思う。使うコンパイラは以下の通り。 g++ (Homebrew GCC 7.3.0_1) 7.3.0 clang++ Apple LLVM version 9.1.0 (clang-902.0.39.2) リンク時最適化の例 簡単なサンプルを示そう。 こんなコードを考える。 #include <cstdio> int func() { return 1; } i
大名行列を特異値分解してみる - Qiita
はじめに 線形代数には、特異値分解という操作があります。行列を特異値と、それをくくりだす行列に分解する処理です。この分解は可逆処理ですが、特異値の大きいところだけを取り、小さいところを無視することで元の行列を近似することができます。近年、この性質を利用した情報圧縮が様々な場所で積極的に利用されています。筆者の身近なところでは、量子状態をテンソルネットワークで近似する際、特異値分解が中心的な役割を果たします。 本稿では、特異値分解がどういう処理なのか、実際に簡単な行列で試してみて、「なるほど情報圧縮だなぁ」というのを実感することを目的とします。 コードは以下においておきます。 https://github.com/kaityo256/daimyo_svd Google ColabでJupyter Notebookを開きたい場合はこちらをクリックしてください。 まず細かいことはさておき、特異値
printfに4285個アスタリスクをつけるとclang++が死ぬ - Qiita
def check(n) s = "*"*n f = open("test.cpp","w") f.puts <<EOS #include <cstdio> int main(){ (#{s}printf)("Hello World\\n"); } EOS f.close() return system("clang++ test.cpp") end check(ARGV[0].to_i) $ ruby check.rb 10000 clang: error: unable to execute command: Illegal instruction: 4 clang: error: clang frontend command failed due to signal (use -v to see invocation) Apple LLVM version 10.0.1 (clang
格子計算プログラム生成言語Formuraを使ってみる その4 - Qiita
はじめに 格子計算プログラム生成言語Formuraを使ってみる。 その3では、二次元熱伝導方程式(拡散方程式)を解いてみた。拡散方程式まで来たら、ちょっと修正するだけで反応拡散方程式を解くことができる。さっそく試してみよう。 ソースは以下においてある。 github.com/kaityo256/fmtest その1 インストールとコンパイルまで その2 一次元熱伝導方程式 その3 二次元熱伝導方程式 その4 反応拡散方程式(Gray-Scott系) ←イマココ Gray-Scott方程式 反応拡散方程式には様々なものがあるが、比較的式が簡単で結果が面白いGray-Scott系を使う。その方程式は以下の通りだ。 \begin{align} \frac{\partial u}{\partial t} &= D_u \Delta u - uv^2 + F(1-u) \\ \frac{\parti
格子計算プログラム生成言語Formuraを使ってみる その2 - Qiita
はじめに 格子計算プログラム生成言語Formuraを使ってみる。 その1では、とりあえずFormuraのインストールと、Formuraが吐いたソースを読み込むmain関数を書いた。本稿では、簡単なシミュレーション例として一次元熱伝導方程式を解いてみる。前回と同じyamlとfmrを使い回すので、まだ読んでいない人は先にその1を参照してほしい。 その1 インストールとコンパイルまで その2 一次元熱伝導方程式 ←イマココ その3 二次元熱伝導方程式 その4 反応拡散方程式(Gray-Scott系) 初期条件の作成 初期条件として、中央に非ゼロの部分、あとは全部ゼロ、といったステップ関数的な温度を与える。そのために、gs.fmrに、「中央かどうか？」を判定する関数isCenterを定義しよう。
C++でアスタリスクをつけすぎると端末が落ちる - Qiita
ならint *型へのポインタになります。 これ、int *****pといくらでも付けられるわけですが、いったいいくつまでつけられるんでしょうか。これってトリビアになりませんかね。 実際に調べてみた。 スクリプト こんな適当なスクリプトを書く。 n = 100 if ARGV.size > 0 n = ARGV[0].to_i end puts "#include <cstdio>" puts "int main(void){" puts "int #{"*"*n}a;" n.times do |i| puts "#{"*"*i}a = new (int#{"*"*(n-i-1)});" end puts <<EOS printf("%x\\n",a); } EOS
SVN脳患者から見たGit - Qiita
はじめに 僕はSVN脳患者である。SVN脳とは、SubversionのポリシーでGitを理解しようとしたり、使おうとしたりする病気で、中年プログラマに発症例が多い(気がする)。それまでSubversionを使ったことがない人がGitを使う場合には問題にならなかったことが、SVN脳患者がGitを使おうとすると問題になることが多い。特に、SVN脳を発症したプログラマは、そうでない人に比べてGit学習コストが爆発的に増大する。最初からGitに触れた人は、なぜSVN脳患者がGitを理解できないのかを理解できないだろう。 これは、SVN脳患者である僕1が、なぜGitを長いこと理解できなかったかをつらつら書くポエムである。病人の書いたポエムであるからして、所謂マサカリの類はほどほどにしていただきたい。 以下、「SVN脳患者」という大きな主語を多用するが、要するにこれは僕のことであり、言うまでもなくSu
Wordさんは今日もおつかれです - Qiita
TL;DR Wordは箇条書きを作る度に膨大な情報がコピーされ、それは元の箇条書きを消しても残る(Windows/Mac共通) Wordは文章を編集するたびに、中身が断片化する。一度断片化したら元には戻らない(Mac版のみ) 断片化、参照されていない箇条書き情報については「名前をつけて保存」しても解消しないが、「全て選択してコピー、新規作成したファイルに貼り付け」で解消する。 2018年9月19日追記 本稿にはもともと「Windowsで作成したWordファイルをMacで修正すると断片化する？」という仮説が追記として掲載されていましたが、実際には「作成環境に関係なく、Mac版Wordで編集すると断片化する」ことがわかりましたので、後で読む方の混乱を避けるためにその追記を削除しました。 はじめに Wordファイルを扱っていて「だんだん重くなっていく」と感じたことはないだろうか。特に、代々引き継
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
格子計算プログラム生成言語Formuraを使ってみる その3 - Qiita