ClangがC++11を完全実装！ 繰り返す、C++11を完全実装
[Phoronix] LLVM's Clang Compiler Is Now C++11 Feature Complete C++11 support is now feature-complete. · e6e68b5 · llvm-mirror/clang · GitHub 3時間前のコミットにより、Clangは晴れてC++11規格を完全に実装した。その通り、完全にすべて実装した。 コミットは、Inheriting Constructorsとthread_localの機能を有効にする変更だ。 もちろん、まだ実装にバグは残っているだろうし、規格上のバグもあるので、開発に終わりはない。ただし、今日は記念すべき日である。 static_puts said... そうすると、ますますC++１１本の重要性が高まってきますね！ 「寄付のお願い」の方にも書かせていただいたのですが、書籍の執筆への寄
MultiPath TCPのLinuxカーネル実装
MultiPath TCP - Linux Kernel implementation : Main - Home Page browse 複数のIPアドレス、インターフェースをまとめてひとつにして扱えるTCP、MultiPath TCPのLinuxカーネルによる実装だそうだ。これにより、完全に別系統のネットワークをまとめて使うことができ、スループットと冗長性の向上が図れる。 デモでは、イーサネットとWifiと3GをひとまとめにしたMPTCP上にsshセッションでXを通している。冗長性があるので、複数のインターフェースの一部が切断されても、Xは問題なく使える。 FreeBSDでMultiPath TCPを実装するパッチもあるそうだ。 mptcp このWebサイトは、Hacker Newsからリンクされたことにより、一時期閲覧者の増加により閲覧困難な状況に陥ったそうだ。「このサイトにもMul
LLVM/Clangがぜってーサポートしねーと宣言しているLinuxカーネルに多用されているGCC拡張
[Phoronix] LLVM/Clang 3.3 Should Be Close To Building Linux Kernel LLVMLinux Bug 9254 – clang can't build iptables in Linux kernel: error: fields must have a constant size: 'variable length array in structure' extension will never be supported ClangでLinuxカーネルをビルドできる状況は、多くの勢力に望まれてきた。理由は様々だ。Clangはビルド時間が短い。静的解析による警告も優れている。ソースコードも綺麗だ。複数の独立した実装でコンパイルできるコードは、誤りを静的に発見しやすい移植性にも優れる。より優れたコピーレフトなライセンスであるGPLv
LLVMに電力効率を最適化するコンパイルオプションの議論
[Phoronix] Making A Code Compiler Energy-Aware LLVMで、電力効率を最適化するコードを生成するコンパイルオプションの可否について議論されているようだ。 コードの最適化というのは、単に実行速度の最適化だけではない。、コードサイズや最適化もある。デバッグモードでのコンパイルも、デバッグに対する最適化と言える。その様々な目的に特化した最適化に、電力効率を加えようという提案だ。 電力効率最適化のコンパイルオプションを加えようという提案は、3年前に出されたが、当時は却下されている。 Bug 6210 – -O3, -Os, -Oe: optimize for running time, binary size, or energy というのも、ほとんどの場合、電力効率が最大になるコードは、実行速度が最短となるコードである。処理を速く終えることができれば
LLVMによる自動C++11移行ツール
LLVM Project Blog: Status of the C++11 Migrator 先月のRSSフィードに一瞬だけ現れたのだが、すぐ消えてしまった記事が復活した。 cpp11-migrateは、LLVMのツールに含まれる、既存のコードをC++11に変換する移行ツールである。 現在のところ、四種類の変換が可能だ。 STLコンテナーや配列の要素をループでなめるコードをRange-based forに変換する。 こんないけてないコードが、 std::vector<int> myVec; for (std::vector<int>::iterator I = myVec.begin(), E = myVec.end(); I != E; ++I) llvm::outs() << *I; こんなに格好良くなる。 std::vector<int> myVec; for (auto & el
現在のアセンブリの利用例
LEG/Engineering/OPTIM/Assembly - Linaro Wiki Linux用のソフトウェアをARMアーキテクチャでサポートする目的で設立された非営利団体、Liaro.orgが、ソフトウェアパッケージのARM移植の調査のために、UbuntuとFedoraのレポジトリの全パッケージに検索をかけて、アセンブリの利用例を抽出した結果がまとめられている。 アセンブリの利用は、アセンブリのソースコードによくある拡張子と、その他のソースコードのインラインアセンブリを探すことで抽出された。さらに、抽出されたアセンブリ利用例に対して手動でその利用目的を調べてまとめている。 それによれば、アセンブリが使われているパッケージは1435件あったそうだ。 Ubuntuのパッケージだけで考えると、2万以上のソースパッケージの中の1200超のパッケージでアセンブリが使われており、利用率は約6%
GCC 4.8でぶっ壊れるSPECのお粗末なコード
本の虫: GCC 4.8のリリースノートとC++関連の変更で、GCC 4.8は464.h264ref: SPEC CPU2006 Benchmarkを壊してしまう。これはSPECベンチマークの規格違反によるものであると書いた。では、具体的に何なのか。それを解説している記事を発見したのでかいつまんで紹介。 Embedded in Academia : GCC pre-4.8 Breaks Broken SPEC 2006 Benchmarks Regehr: GCC 4.8 Breaks Broken SPEC 2006 Benchmarks [LWN.net] どうやら、SPECベンチマークは以下のようなコードを含むそうだ。 int d[16]; int SATD (void) { int satd = 0, dd, k; for (dd=d[k=0]; k<16; dd=d[++k])
GCC 4.8のリリースノートとC++関連の変更
GCC 4.8 Release Series — Changes, New Features, and Fixes - GNU Project - Free Software Foundation (FSF) GCC 4.8のリリースノートから興味深い点を紹介する。 まず、GCC 4.8は、C++で書かれるようになった。これはつまり、GCC 4.8のビルドには、C++03に準拠したコンパイラーが必要になる。 GCC 4.8は、ループ最適化の方法として、ループ回数の上限をaggressiveに解析するようになった。これは言語規格で許されている範囲の実装である。これにより、既存の規格違反のプログラムが正しく動かなくなる。たとえば、SPEC CPU 2006の464.h264ref （H.264のリファレンスエンコーダーを流用したSPECのベンチマーク）や、同じくSPECのベンチマークである41
Emacs上でのVim実装であるEvilのバージョンが1.0に達した
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
GoogleがB-tree実装のSTLコンテナを公開
C++ containers that save memory and time cpp-btree - C++ B-tree - Google Project Hosting Googleが、B-tree実装のSTLコンテナー(map, set, multimap, multiset)を発表した。 多くのSTLの実装では、map, set, multimap, multisetは、Red-Black treeで実装されている。Googleの発表によれば、B-tree実装のコンテナーは、赤黒木実装に比べて、速度が上がり、しかもメモリ消費量も削減できるとしている。 紹介まで。 B木は一つのノードに複数の要素を格納する。これにより、ポインターなどのオーバーヘッドを低減でき、メモリ消費量の削減につながる。また、複数の要素を一括してノードに詰め込むため、速度向上もあるのかもしれないが、そのへんはよ
OS XでFile:///と入力するとクラッシュするそうだ
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
GoogleのNative ClientチームがLLVMにx32を所望
[Phoronix] Google Wants LLVM To Mainline x32 ABI Support [LLVMdev] Upstreaming x32 ABI support なんでも、Native ClientのABIはx86-64環境において32bitアドレスなんだそうで、これはx32の方向性と一致する。したがって、GoogleのNative Clientチームは、LLVMにx32が入って欲しいのだとか。 Native Clientは、ブラウザー上でネイティブコード(x86かARM)を安全に実行するための仕組みである。x32は、x86-64の命令セットの拡張や増加した汎用レジスターの恩恵を受けつつ、アドレスだけは32bitに保ち節約するという、いいとこ取りを狙ったABIで、現在、Linuxカーネル、glibc、gdb、gccといった環境でサポートされている。 アドレス長を
コンピューターのハードウェアの不具合は、案外多い
Whose bug is this anyway?!? - Code Of Honor Guild Warsという不自由なソフトウェアのゲームの開発者である Patrick Wyattが、今までに出くわしたバグについて語っている。中でも興味深いのは、ハードウェアの不具合、つまりソフトウェアの責任ではない不具合だ。 ユーザーから上がってくるバグ報告のうちのいくつかは、本来起こり得ないようなバグであった。もちろん、バグであるからには、何だって起こりえるのだが、それにしても、まずありえないバグが報告されていた。共同出資社にして凄腕プログラマーのMike O’Brienは、これがユーザーのハードウェアに起因する問題ではないかと推測した。そこで、彼はテストのためのコードを書いた。 Mike O’BrienはOsStressと名付けたモジュールを書いた。これは、メモリブロックを確保し、そのメモリブロッ
Mac OS XのバイナリをGNU/Linuxで実行するソフトウェア
[Phoronix] A New Project To Run Mac OS X Binaries On Linux Mac OS X用のバイナリをGNU/Linuxで実行するソフトウェアが開発されているらしい。その名をDarlingという。 Darling - The Darling Project 名前についてだが、Mac OS XのカーネルであるDarwin用のソフトウェアを実行するので、Darlingという名前らしい。 Darlingは、Windows用のバイナリをGNU/Linuxで実行するソフトウェアであるWineと同じ仕組みで、Mac OS X用のバイナリを実行する。 すなわち、バイナリを読み込んでLinuxカーネル用に適切にメモリ上にマップし、Mac OS Xが提供しているAPIとABI互換の実装を用意し、バイナリ互換を実現するものである。Mac OS XのObjectiv
バージョン管理ソフトウェアの寿命は10年？
Gitが10年後存続してるとは思えないけど、Excelが10年後に消えてる筈がないだろ！！と熱弁してる — （あんちべ 心はS式とともにあります） (@AntiBayes) December 5, 2012 言うまでもなく、gitは今をときめく流行のバージョン管理システムである。たったの10年後に存続していないのだろうか。 gitが登場したのは2005年だ。githubが登場したのは2008年だ。githubは直接関係がないが、gitの価値を押し上げたといえる。それ以前、自由なソフトウェア実装によるバージョン管理システムといえば、Subversionが有名だった。Subversionは、2000年に登場している。2010年、gitは流行していた。いま、SVNがgitの流行に押されているのを考えると、たったの10年でよく変わったものだ。 Subversion以前、自由なソフトウェア実装で有名
EXT4のバグが修正された
江添亮 自由ソフトウェア主義者 C++ Evangelist C++標準化委員会の委員 ドワンゴ社員 C++11本を執筆した。 株式会社ドワンゴで働いている。 Mail:boostcpp@gmail.com Twitter:@EzoeRyou GitHub: https://github.com/EzoeRyou 江添亮のマストドン@EzoeRyou 筆者にブログのネタを提供するために、品物をアマゾンお気に入りリスト経由で送りたい場合： Amazon.co.jp: 江添亮: 江添のほしい物リスト 筆者にブログのネタを提供するために、直接に品物を送りたい場合、住所をメールで質問してください。 View my complete profile ► 2020 (31) ► December (2) ► November (2) ► September (2) ► August (4) ► Jul
リーナス曰く「2560x1600がラップトップの標準になってるべきだろボケ」
Linus Torvalds - Google+ - So with even a $399 tablet doing 2560x1600 pixel displays,… リーナス・トーバルズがGoogle+で、ラップトップの解像度だけが全然向上していない現状に吠えてる。 399ドルのタブレットですら2560x1600ピクセルのディスプレイなんだぜ。ラップトップの解像度の標準もそれぐらいにしてくれよマジで頼むし。もちろん11インチでもだ。頼むし、"retina"とかいうクソな名前で呼ぶのはやめれ。単に、「まともな解像度」と呼べ。ラップトップがここ10年ほど、あんまり進化してないのは残念すぎるだろ。 俺は弁当箱みたいなラップトップは欲しくないが、1366x768とかいうのは旧世紀の遺物だろ。マジで、じきに携帯電話すらラップトップのクソな解像度を笑うようになるぜ。 もし自称技術ジャーナリスト
非同期入出力の残念な現状
asynchronous disk I/O | libtorrent blog Libtorrent experience - the poor state of async disk IO | Hacker News libtorrentの作者が、ディスクI/Oをパフォーマンスを向上させるために非同期I/Oを試した結果、どの環境でも残念なので、ブロックI/Oをスレッドプールで行う擬似非同期I/Oで実装したとブログを書いている。その問題について、Hacker Newsでも議論されている。 非同期I/Oは、話を聞くとたのもしい機能に思える。読み書きが完了するまでブロックせずに、完了したらOSが通知するという仕組みだ。 問題は、その実装がどの環境でも貧弱だという事だ。 環境というのは、主にOS側のことだ。多くのモダンなOSは非同期I/Oを提供している。特に著名なのがみっつある。 Linux A
ext4の変更を辞めて新しくext5を作ったらどうかという意見に対するTheodore Ts'oの回答
EXT4 Data Corruption Bug Hits Stable Linux Kernels - Page 5 つい先日、ext4をぶっ壊すバグが発見されたことを報じたPhoronixの記事に対するフォーラムで、「もうこれ以上ext4を変更するのを辞めて、新しくext5を作ってはどうか」という意見があり、それに対してTheodore Ts'oが回答している。 それは検討したことがある。現在、新機能は実験的機能フラグやマウントオプションで追加されている。そういうデフォルトで有効になっていない実験的な新機能を使う利用者は問題に出くわしやすい。デフォルトで有効になっていない新機能を試したがる利用者を止めることなどできやしない。本番サーバーでext4のかわりにext5を使うことを止めることができないのと同じだ。メタデータチェックサムのようなものがデフォルトで有効になっていないのは、まだ使う
Linuxのstableカーネルにext4をぶっ壊すバグが発見される
[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels このバグは、3.6.2でもたらされ、以前の安定版カーネルにもback-portされているので、3.4の最新の安定版カーネルにまで影響が及ぶらしい。 Theodore Ts'oによれば、この問題は、カーネルを短期間で二度正常にリブートすることで起こるのだそうだ。そのため、一般の普通のディストロを使っている利用者は、まずこのバグに出くわすことはない。しかし、サスペンドやハイバネートのかわりにリブートを使うラップトップ利用者や、カーネル開発者には、容易に問題が起こりうるのだとか。 なんだかだいぶ反響があるので追記。Theodore Ts'oのメールより LKML: Theodore Ts'o: Re: Apparent serious progressive ext4 da
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
