Pingプログラムの話
The Story of the PING Program そうだ。UNIXのpingを書いたのは俺さ。pingというものは誰でも知ってるだろうが、これはある夜、俺が千行程度で書いたハックだ。 名前の由来はソナーの音だ。俺は大学でソナーとレーダーシステムの設計をさんざんやっていたので、サイバースペース的なものとは親和性が高かった。新しい分野に既存の概念を適用したというわけだ。pingはIP/ICMP ECHO_REQUESTとECHO_REPLYパケットを使って時間を測り、ターゲットマシンへの「距離」を計測する。 4.2a BSD UNIX用のPINGを書いた着想は、1983年の7月に、ノルウェイでのDARPA会議で、Dave MIlls博士からきいた話が元だ。博士はFizzball LSI-11システムで、ICMP Echoパケットの時間を計測して、経路遅延を計測したと話していた。 19
cpで大量のファイルをコピーした（4億3200万件、39TB）
GNUのcpを使って大量のファイルをコピーしたところ、cpの設計上の問題で、極めてコピーが遅かったというお話。 My experience with using cp to copy a lot of files (432 millions, 39 TB) よう。俺は最近、大量のファイルをコピーする必要があったんだが、UNIXは20年もやってきた俺の経験からも、cpの挙動には驚かされたし、俺の意見はコミュニティに共有されるべきだと思う。 環境：古いDellのサーバー（2コア、初期メモリ2GB、追加して10GB、Ubuntu Trusty）と、新しいDellのストレージ格納機(MD 1200)にある、12個の4TBディスクでRAID 6が設定してあって、全体で40TBの要領を持ち、二つのドライブが同時に失敗しても問題ない環境。サーバーは遠隔地バックアップに使われていて、ディスクへの書き込みし
fork()は失敗するんだぜ、覚えときな
fork() can fail: this is important あー、fork()のことね。プロセスがもっとプロセス作るためのやつな。いや、他にもプロセス作る方法はあるけどな。ま、面白い話がもうひとつあるから聞かせてやるよ。 forkは失敗するんだぜ。分かってるか？ マジで分かってるか？ マジだぜ。forkは失敗するもんだ。mallocと同じさ。失敗することもある。そんなに頻繁にってわけじゃないけどさ、でも失敗したら、無視できっこないぜ。ちっとは脳みそ働かせなきゃならん。 forkが0を返したら、そいつは子プロセスで、親なら正数を返すってことは、みんな知ってるよな。その値は子のpidだ。こいつを保存しといて、あとで使うってわけだ。 失敗を確認しない場合どうなるか知ってるか？ そうだよ。お前多分、"-1"（forkのエラー通知）をpidとして扱ってるんだろ。 さて、問題の始まりだ。本当
ループカウンタを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
Linus Torvalds、 GCC 4.9.0のコード生成にブチ切れる
Phoronixで知ったが、Linus TorvaldsがGCC 4.9.0のコード生成にブチ切れている。 問題はLinuxカーネルのload_balance()がランダムにパニックを起こすというもので、その原因は、報告者の使っているコンパイラーであるGCC 4.9.0のコード生成がおかしかったという話だ。 Linus様は御自ら生成されたコードを読み給い、平生と変わらぬ調子で物事の道理を示された。 Linux-Kernel Archive: Re: Random panic in load_balance() with 3.16-rc From: Linus Torvalds Date: Thu Jul 24 2014 - 14:47:25 EST On Wed, Jul 23, 2014 at 6:43 PM, Michel DÃnzer <michel@xxxxxxxxxxx> wro
Debianがeglibcからglibcに戻る
Debianはしばらく、libcとして、glibcではなく、glibcと互換性を維持したforkであるeblicを使っていたが、このたび、glibcに戻る決定をしたそうだ。 glibcを使っていた理由はいろいろあるが、Debianにとって重要なパッチが、glibcでは開発体制の問題により受け入れられないという政治的な理由もあったそうだ。その問題が解決されたのと、eglibcがプロジェクトとして死んだので、戻るのだそうだ。 Debian is switching (back) to GLIBC | Aurelien's weblog 5年前、Debianと多くの派生ディストロは、標準であるGNU C Library (GLIBC)から、Embedded GLIBC (EGLIBC)に乗り換えた。Debianは、GLIBCに再び乗り換えることにする。EGLIBCの最後のリリースは2.19と、プ
Linux Torvalds、最近のCPUのPage Faultのコストにご不満の様子
Linus Torvalds - Google+ - One of the things I end up doing is do a lot of performance… Linus Torvaldsが、最近のIntelのCPUは、通常以外の処理のコスト、つまりPage faultのコストが上がっているので、問題であるとしている。 俺はよくカーネルコードのパフォーマンスプロファイリングをやる。特に、VMとかファイルシステム周りに対してだ。 俺がよくやるのは、「うまくいってるとき」に対する計測だ。つまり、だいたいほぼ完璧にキャッシュされてる状況だな。というのも、俺はもちろんIOのことは気にかけているが、俺の個人的なワークロードはたいてい、うまくキャッシュされてるからだ。たとえば、俺にとってよくあるロードは、pullした後のフルカーネルビルドだ。これにどのくらいの時間がかかるかが問題になる
表計算をマジなことに使わないほうがいいよ（マジで）
You shouldn’t use a spreadsheet for important work (I mean it) 経済学者はうらやましいね。コンピューター科学者とは違って、革新的な研究で、ベストセラー本をだせるときている。たとえば、 Capital in the Twenty-First Centuryだ。この本はマルクス経済を再認識させる本だ。本を読んでいない人のために要約すると、資本の増加は賃金の増加よりも高いので、資本を持つ者はますます富み、ますます強大になる。大多数は貧する。少数のエリート達が、富のすべてをかき集める。一般人には富は残らない。この見方は、彼の専売特許ではない。富の集中という概念には、富める者はますます富み、貧するものはますます貧すというキャッチフレーズまである。 同じ主張をするものはいくらでもいる。しかし、証明するのは難しいし、一部の経済学者は、反証すら
プログラミングを学ぶ方法がわからない
最近、プログラミングをどうやって学べばいいのかわからなくなってしまった。 筆者はドワンゴに雇われている。ドワンゴに入社して早4ヶ月になろうとしている。ドワンゴに雇われている名目は、C++の啓蒙である。C++の啓蒙にはC++の教育も含まれる。したがって、筆者はそろそろC++の教育をしなければならない。 筆者は、プログラミングを教育する最良の方法は、参考書を執筆することだと考えている。直接対面して教えるのは非効率的だ。文章を書いておけば、大勢が学べる。では、どのような参考書を執筆すればいいのか。すでにC++11のコア言語の参考書は書いた。 EzoeRyou/cpp-book C++14対応も、正式なC++14規格制定後に行わなければならない。そしてライブラリは、もし他にやる人がいないのであれば、やらなければならないだろう。 しかし、これらの本は、C++をこれから学び始める人向けではない。C++
Matthew Garrett、開発者にMacユーザーが多いことについて語る
mjg59 | The desktop and the developer Matthew GarrettがGNU/Linux上で動くソフトウェアの開発者であっても、不自由なOSであるMacユーザーが多いことについて記事を書いている。 Matthew Garrettは、今や開発者の作業環境は、ターミナルとWebブラウザーなので、作業環境という点で、GNU/LinuxがプロプライエタリなMacに対して十分な利点を提供できていないとしている。 開発には、単にコードを書く以外の作業も多い。Webブラウザーで複数のWebサービス間を行き来して情報をコピペしたりするのは、極めて非効率的であるし、開発者の好む作業ではない。とはいえ、開発者がやらなければならない作業であることには変わりない。 このため、デスクトップ環境に、一般的な開発ワークフローを支援する組み込み機能を増やすなどして、GNU/Linux
KADOKAWA・DWANGOについて
朝起きると、今朝の02:00に日経が興味深い記事を公開していたことに気がついた。 角川・ドワンゴ経営統合 アニメなど「ニコ動」で海外へ ：日本経済新聞 はて、どうせ日経のことだろうし、また飛ばし記事だろうかと読み飛ばして、10:45にドワンゴに出社した。ちなみに、この時間は、ドワンゴのエンジニア基準では、まだ出社している人もまばらな時間帯である。筆者はドワンゴ社員にしては珍しく、早寝早起きなのだ。 さて、ドワンゴ社内では、日経の報道する、角川との経営統合について知っている人間はいなかった。 さて、出社して、勤務時間中に、勝手にBoost.勉強会 #14 札幌で使うスライド資料を書いて公開してから、弁当を使った。今日の弁当は、五分づきご飯、グラタン、コンソメスープだ。グラタンは、昨日の夕食の残りである。筆者はしっかりとした弁当用の容器を持っているので、コンソメスープも温かいまま運搬可能なの
Google翻訳には秘密の特別版があるのか？
Does Google Have A Secret "Google Translate" Service? 公に公開されているGoogle翻訳と、GAndroidやChrome用のソフトウェア流通サイトに組み込まれているGoogle翻訳機能は、翻訳精度が違うというお話。 GoogleのGoogle翻訳は、おそらくオンライン翻訳サービスの最大手と言えるだろう。Googleは、このサービスを使って自動翻訳コンテンツを生成してオンライン上に公開するスパマーと戦っている。 このため、Google自身が自動翻訳コンテンツの利用者だというのは、驚きに値する。まず最初に気がついたのは、Google Playで、アプリ説明に自動翻訳を付けたことだ。後にChrome Web storeでも同様になった。 さらに興味深いことに、この翻訳はほぼ人間のように見えることだ。少なくとも、Google翻訳オンラインの結
JavaとJavaScriptの違い
JavaとJavaScriptには、Unicode escape sequenceというものがある。どちらも同じ文法で、\uに続いて4文字の16進数文字を指定することで、Unicode Code Pointを指定できる。あたかも、Unicode Code Pointを記述したかのように振る舞う。 ところで、JavaとJavaScriptは、このUnicodeエスケープシーケンスの使い方が異なる。例えば、行終端文字\u000Aを、以下のように書く。 // これは\u000Aコメント これは、JavaScriptで解釈すると、以下のようになる。 // これは\u000Aコメント 以下は、Javaによる解釈である。 // これは コメント Javaでは、Unicodeエスケープシーケンスが、実際に行終端文字として扱われてしまう。したがって、行終端文字以降が一行コメントからはみ出してしまう。 これ
なぜTheo de RaadtはIETFに激怒しているのか
本の虫: OpenBSD、怒りのコミットで、OpenBSDのTheo de RaadtがIETFに対して激怒している。 src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を本気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 なぜTheo de Raadtは、OpenSSLではなく、IETFに対して激怒しているのか。IETFというのは、インターネット上の規格制定の団体である。今回、世上を騒がせているHeartbeat問題は
OpenBSD、怒りのコミット
OpenSSLのheatbeatバグの対応のため、OpenBSDはOpenSSLのheatbeatを無効にするコミットをした。ただし・・・ src/lib/libssl/ssl/Makefile - view - 1.29 SegglemannのRFC520 heatbeatを無効化。 あのまともなプロトコルひとつ制定できないIETFの無能集団が、超重要なプロトコルで64Kの穴をこしらえるとか、マジであきれてものも言えねーわ。奴らはマジこの問題を本気で検証すべきだろ。なんでこんなことをしでかしたのか。こんな事態を承認した責任ある連中を全員、意思決定プロセスから取り除く必要がある。IETF、てめーは信用なんねぇ。 このコミットは、Makefileの中で、OpenSSLでheatbeatを無効にするマクロを定義するよう、コンパイラーオプションを指定するものだ。ただし、無効にするマクロは、OPE
Linus様がSystemdにぶちきれる
systemdは、/proc/cmdlineをパースして、もし、その中に"debug"という文字列を発見した場合、大量の冗長なデバッグメッセージをdmsegに出力する。これは様々な問題を引き起こす。まず、"debug"というあまりに一般的すぎる文字列に勝手に反応してしまうことがひとつ。dmseg、すなわちカーネルのリングバッファーをsystemdの冗長なデバッグメッセージだけで溢れ返させてしまうことがひとつ。そして、なぜかLinuxカーネルのブートに失敗してしまうことがひとつ。 Bug 76935 – Do not parse "debug" command line parameter カーネルコマンドラインに"debug"を与えると、systemdによりパースされる。適当なassertに引っかかると、こんな風にぶっ放される。 [ 150.308000] systemd-journald
ドワンゴの女子マネという過酷な訓練
ドワンゴ現在、ドワンゴでは「女子マネ弁当」という企画が復活している。 過去の女子マネ弁当の様子については、すでに社外にも相当の情報が出回っているので、例えば以下のような情報を参考にしてもらいたい。 【第1回】ドワンゴ大改革の鍵は、インフラと女子マネージャー。｜川上量生の胸のうち｜川上量生｜cakes（ケイクス） ドワンゴ「助けて！ エンジニアが朝出社しないの！」→ 女子マネージャーが弁当を手渡してくれる「女子マネ弁当」システム導入で生活習慣改善へ - ねとらぼ 今回は、その女子マネ弁当の実情に迫る、社内からのレポートをお届けする。 女子マネ弁当の概要とは以下の通りである。 3月17日から、4月25日までの一ヶ月間、午前10時30分までに出社すると、以下の特典がある 午前10時30分から、エンジ色のジャージを来た女子マネ人員（なぜか若い女性のみで構成されている男女比率の偏った集団）が、エンジ
MozillaがMetro版Firefox開発中止を発表
Update on Metro | Future Releases 今週のはじめ、筆者はリードエンジニアとリリースマネージャーに、Windows Metro版のFirefoxの開発中止を指示した。開発チームはよくやってくれたが、Metroプラットフォームを取り巻く環境を考慮すると、1.0をリリースするのは、間違いだった。 Mozillaは世界をより良くするためにソフトウェアを開発している。しかし、我々は戦いを選ばねばならない。今や我々は、Firefox 1.0をリリースした時ほどちっぽけな存在ではないが、我々の労力は、我々が誓った目標を達成するために、集中して振り向けねばならない。我々の競合相手の強大さと、労力の多大さにより、我々は労力を適切に集中させなければならないのだ。 2012年末、筆者がMetro用Firefox開発チームを立ち上げた時（もうMicrosoftは、Metroという名
2014-01-pre-Issaquah mailingの簡易レビュー Part 2
2014-01-pre-Issaquah mailingが公開された。 前回に引き続いて、C++WGの論文集を解説していく。 N3863: Private Extension Methods プライベート拡張メソッド(Private Extension Methods, PEM)は、privateな非virtualメンバー関数を、クラス定義の外で定義できる機能だ。 以下のようなコードを考える。 // Foo.h class Foo { public : int get_secret() ; private : void set_secret( int value ) ; int secret ; } ; 時に、このヘッダーファイルは、ユーザー側から利用される。そのようなヘッダーになぜ、privateなメンバーの情報を書いておく必要があるのか。よいクラスの条件とは、なるべく多くを隠匿すること
Debianの新しいinitにsystemdが採決された
江添亮 自由ソフトウェア主義者 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
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
