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
Pythonによる反応拡散シミュレーションをJITで高速化 - Qiita
TL;DR numpy配列にfor文使うと遅い ラプラシアンの計算にscipy.signal.convolve2d使うと早い でもfor文回すコードにnumba.jitでJITをかけるともっと早い はじめに プログラムで何か数値シミュレーションをやることを考える。できるだけ簡単で、かつそれなりに結果が面白いものが良い。わりと簡単なのは熱拡散方程式で、これは定常状態が非常に簡単に求まるのでデバッグがしやすく、かつ非定常状態もフーリエ変換で求まるため、大学生の課題としてはとても良いのだが、何しろ結果が地味なのが泣き所である。 次に面白いのは力学系、特にローレンツ・アトラクタなどが簡単で面白い。しかし、シミュレーションをするので、何かアニメーションを表示させたい。カオスでアニメーションというと二重振り子などがあり、これはこれで面白いのだが、もう一声派手さが欲しい。 というわけで、拡散方程式の次の
コンパイラは関数のインライン展開を☓☓段で力尽きる - Qiita
はじめに 「コンパイラって、関数のインライン展開を何段までやってくれるんでしょうか？これってトリビアになりませんか？」 このトリビアの種、つまりこういうことになります。 「コンパイラに多段呼び出しの関数を食わせてインライン展開させた時、☓☓段で力尽きる」 実際に調べてみた。 ソース 関数の多段呼び出しをするコードを吐くRubyコードを書いた。 num = ARGV[0].to_i puts <<EOS #include <stdio.h> int func0(int a){ return a + 1; } EOS num.times do |i| puts "int func#{i+1}(int a){return func#{i}(a);}" end puts <<EOS int main(void){ int a = 0; printf("%d\\n",func#{num}(a));
構造体のコピーとmemcpyとgdbのウォッチポイント - Qiita
はじめに 構造体のサイズがある程度大きくなると代入にmemcpyが呼ばれてgdbのウォッチポイントでソースの行数がわからなくなる話と、どのくらいのサイズでmemcpyを呼ぶかは処理系依存な話。 gdbのウォッチポイントとmemcpy そういうことはおきて欲しくないものだが、クソコードをデバッグしなければならないこともある。グローバル変数バリバリで、構造体とか定義しまくっていて、なおかつそのポインタを別のポインタに代入しまくってるからどこで変数が修正を受けているかコードを見ているだけじゃわからないというコード。 で、不幸にしてそういうコードをいじることになった場合、強力な味方になるのがgdbのウォッチポイント。これで変数を監視すれば、ポインタとかを経由して変数の名前が変わっても変更を検知できる。 ところが、ある程度以上大きな構造体の代入はmemcpyが呼ばれるが、処理系によってはmemcpy
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
