本の虫: GCCのgit移行が難航中
GCCはgitへの移行を計画しているが、GCCの既存のsubversionレポジトリをgitレポジトリに変換する作業が難航している。 GCCの移行作業を検証しているのは他ならぬEric S. Raymond(ESR)だ。 ESRお手製の変換ツール、reposurgeonはsubversionからgitへの変換ができる。 Resource page for reposurgeon 3.44 しかしGCCは30年もの歴史を持ち、そのsubversionレポジトリも複雑だ。 ESRはGCCのためにreposurgeonのバグを潰し、勢い変換しようと試みたが、意外な障害に出くわした。メモリ不足だ。 GCC's Conversion To Git Is Being Held Up By RAM, a.k.a. Crazy DDR4 Prices - Phoronix ESRの所有する64GBのメモリ
C++入門書で再帰について解説しようとしたら思わぬ最適化できないコードに出くわした
C++入門書を書き始めて早数カ月、すでに文章量が「江添亮の詳説C++17」の半分近くに達しているが、まだようやくループを説明したところだ。 ループの章を一通り書き終えて、ついでに再帰によってループを実現する方法について軽く触れて章を閉じようと、以下のようなコードを書いた。 void hello() { std::cout << "hello\n"s ; hello() ; } すると何故かsegmentation faultを起こすではないか。GCCでもClangでも同じ挙動になる。なぜC++コンパイラーはこの程度の末尾再帰を最適化できないのだろうか。 不思議に思って以下のコードも試すと、こちらは問題なく末尾再帰の最適化が行われる。 void hello() { std::cout << "hello\n" ; hello() ; } 違いは文字列だ。今回の入門書では、初心者に簡単にするた
ループカウンタを64bitにしたり、 バッファのサイズを定数にしたらパフォーマンス激落ちなんだけど何で？
ループカウンタを64bitにしたり、 バッファのサイズを定数にしたらパフォーマンス激落ちなんだけど何で？ c++ - Replacing 32bit loop count variable with 64bit introduces crazy performance deviations - Stack Overflow stackoverflowで、興味深い質問が行われている。 簡単にまとめるとこうだ。std::uint64_t型の配列の各要素にx86-64のpopcnt(1になっているビット数を数える命令)を適用したい。 コードの肝心の部分を書くと、以下のようになる。 for (unsigned i=0;i<size/8;i+=4) { count+=_mm_popcnt_u64(buffer[i]); count+=_mm_popcnt_u64(buffer[i+1]); coun
rm -rfしちゃったけどどうする
rm -rf remains rm -rfの後に残りしもの 遊びのために、筆者は新しいLinuxサーバーを立ち上げて、rootでrm -rf /を実行して、何が残るかをみてみた。どうやら、今のrmというのは筆者のようなアホを相手にしなければならない未来に生きているようなので、実際に実行するには、--no-preserve-rootをつける必要があった。 # rm -rf --no-preserve-root / かかるおろかなる行為の後では、 /bin/ls /bin/cat /bin/chmod /usr/bin/file のような、偉大なるツールのたぐいはみな消え失せてしまった。まだ、ssh接続とbashセッションは生きているはずだ。つまり、bashの組み込みコマンドであるechoとかは残っているということだ。 Bashマクガイバーたれ root@rmrf:/# ls -bash: /
みなさんスラッシュドットから出てこないほうがいいですよ。
Objective-Cという汚らしい言語を長年強制し、プログラマーを絶望の淵に叩き込んでいたAppleが、とうとう新言語を発表した。名前はSwiftという。 iTunes - Books - The Swift Programming Language by Apple Inc. ただし、現時点で、Swift言語仕様書のダウンロードと閲覧に、Appleの独自仕様満載の不自由なデバイス、の上で動く不自由なOS、の上で動く不自由な閲覧ソフトウェアが必要だ。そのため、筆者は未だに言語仕様書を読めずにいる。これをもってこれをみると、Appleの新言語にかける姿勢が如実に現れていると言えよう。すなわち、Appleの不自由なシステム以外は、市場として考慮する必要がないということに違いない。事実、Objective-Cは、Appleの不自由なシステムでプログラミングするにあたって、仕方なく使わなければな
プログラミングを学ぶ方法がわからない
最近、プログラミングをどうやって学べばいいのかわからなくなってしまった。 筆者はドワンゴに雇われている。ドワンゴに入社して早4ヶ月になろうとしている。ドワンゴに雇われている名目は、C++の啓蒙である。C++の啓蒙にはC++の教育も含まれる。したがって、筆者はそろそろC++の教育をしなければならない。 筆者は、プログラミングを教育する最良の方法は、参考書を執筆することだと考えている。直接対面して教えるのは非効率的だ。文章を書いておけば、大勢が学べる。では、どのような参考書を執筆すればいいのか。すでにC++11のコア言語の参考書は書いた。 EzoeRyou/cpp-book C++14対応も、正式なC++14規格制定後に行わなければならない。そしてライブラリは、もし他にやる人がいないのであれば、やらなければならないだろう。 しかし、これらの本は、C++をこれから学び始める人向けではない。C++
Vim vs Emacs
世間では、VimとEmacsと、どちらが優れたテキストエディターであるかという論争があるらしい。そこで私も考えてみることにした。 Vimは純然たるテキストエディターである。その本文であるテキストの編集のための機能は豊富にある。 一方、Emacsはテキストエディター以上のプラットフォームになろうとしている。メール、IRCクライアント、ブラウザー、画像表示などなど。これがために、「Emacsは悪くないOSである。ただし良きテキストエディターを欠く」とまで言われている。 vimは操作性に優れている。vimのほとんどの機能は、文字を連続して入力することで使うことができる。操作を複数行にわたって適用したい場合は、操作の文字に先立って数字を入力するとか、後にカーソル移動を入力するなどすれば、非常に素早く入力できるので、操作の妨げにならない。 一方、Emacsは操作しづらい。Emacsの操作は、単一のキ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
