卜部昌平のあまりreblogしないtumblr - 最速の memset64 を求めて 今回のお題は char 幅じゃなくて word 幅の...
今回のお題は char 幅じゃなくて word 幅の memset 、つまりプロトタイプだと void* memset64(void* destination, uint64_t image, int num_words); をどれだけ高速に行うかという話。なぜ高速化するかというと、塗りつぶす領域がけっこうでかいから。 候補 1: REP STOSvoid* memset64(void* d, uint64_t i, int n) { asm("cld; rep stosq;" :: "D"(d), "a"(i), "c"(n) : "memory"); return d; } 最近の CPU はクソ賢い。そのため、下手に手で loop unrolling するよりも、逆に CPU に「ここはループなんだぞおおお～」というのを明示的に指示してあげたほうが CPU 側が勝手かつ不気味に最適な
卜部昌平のあまりreblogしないtumblr
前回の続き。 前回の時点では「git blameが密になっているところはきっと活発に編集されていたに違いない」という仮説があったわけですが、これは本当のところは、よくわからない。なぜかというと、blameというのは地層のように降り積もったコミットの表面に露頭してるところしか見せてくれないわけです。本当に活発に更新されていたかを知るには、ようするに地質平面図じゃなくて地質断面図が必要なわけ。分かりますよね。 で、それはどうやって作ればいいかというと、gitには便利なgit log -pという、こういうとき便利だけど普段は使い道のなさそーなコマンドがあって、これは生のdiffをすべてだらだらと表示してくれるわけですよ。で、diffからblameを再構成するにはdiffの+行をひたすら集めてくればいいわけだけど、その時-行も一緒に覚えておいて、あるコミットでどのコミットが上書きされたかを覚えてお
卜部昌平のあまりreblogしないtumblr
どうも。グリーのアカウントは持ってる1けどモバゲーのアカウントは持ってない卜部です。 ところでPerlリスクですか。まあ、あるんじゃないですか。ぶっちゃけ。でもさあ、さすがにPerlしか書けない人たちは転職先の選択肢のなさくらい自覚してると思う。なのでPerlがどうとかいう話はしないです。各自でどうぞ。 でね、ポイントはそこじゃないだろうと思うわけですよ。どんな選択をしても同様のリスクはあるんですよ。たとえばMacromedia ShockwaveでLingoで作ってたソフトとかさあ。今ではだれもメンテできないでしょう? だから今隆盛をきわめてる技術で作ったものが、何年か後にリスクになるってのは、それはそういうものなんですよ。べつにPerlに限らん。Perlはたまたま今そういうフェーズってだけで、明日は我が身ですよ。hamlとかsassとか。 だからまあ、こう言ってしまうと身も蓋もないかも
DeNAに転職します
宮川達彦さんがCOOKPADでRuby書いてるなら俺がDeNAでPerl書くのもまあありなんじゃないかと思ったので。 よくある質問とその答えQ. 一時金もらえるんでしょ? 200万? やったー! ごちそうさまです A. ねーよ。おまえはいつの話をしてるんだ。そのキャンペーンはずいぶん前に終わりました。 Q. ベイスターズファンだったの? A. 好きでも嫌いでもねーよ。野球の趣味を理由に転職するの必ずしもダメとは申しませんが、俺はそういう類の輩ではございません。 Q. モゲマス作るの? A. 作らねーよ。Mobageだからといって全部のゲームをDeNAが作っているわけでは、実はないのです。モゲマスは違います。 Q. Rubyやめちゃうの? A. やめねーよ。コミュニティ活動に関しましては、むしろ推奨されていると聞き及んでおります。あと当然、素性を隠しておりませんので、俺が何者かは分かった上で
どうも周知徹底が不足しているようなので再度のお願いとなりますが、C死ね。
確かにCでしか書けない類のプログラムは存在する(例を挙げるならKernel)が、それはCの存在を赦す理由にはならない。確かにCに輪をかけてさらにダメな類のプログラミング言語は存在する(例を挙げるならC++)が、それはCの存在を赦す理由にはならない。確かにCでしか書けないダメプログラマは存在する(例を挙げてほしければここにおまえの名前を入れろ)が、それはCの存在を赦す理由にはならない。結論:C死ね。 そもそも計算機にできて算盤にできないことなど存在しない。存在しないんだぞ。なのに何故人はプログラムを書くのか。それはオートメーションのためなのであり、奴隷的使役から人類の尊厳を開放して、この地上に楽園を築くためである。まあそこまで大上段に振りかぶって普段から書いてる輩はいないにせよ、プログラミングとは楽をするため、豊かな人生を実現するため、誰かの幸福のために行うものだ。違うか?じゃあなぜプログラ
Rubyがそろそろ一回終わってみるべき10の理由
いや、Rubyを取り巻く皆さんの生活まで終われとは言ってないですからね。終わってみるべきなのはRubyのコア部分の開発。 1) 百年の大計の欠如 https://twitter.com/yukihiro_matz/status/25168548474 によると、100年や200年続けるべきなんだそうだ。ふーん。100年って言ってみたいだけちゃうんか。200年後といえば本人はおろかまつもとゆきひろと面識のある人間すら死に絶えている時期なんだけどな。そこまで続けたきゃどうするればいいか真面目に考えたことあんのかね。日本国ですらこの120年で2回も憲法変わってんだぞ。惰性で200年もつわけがないだろ。 2) まつもとゆきひろがスケールしない 御存知の通りまつもとゆきひろのRuby開発に対するコミットペース(ここでいうコミットってのはソースコードをチェックインすることだけではなくて広く「関与」の意
卜部昌平のあまりreblogしないtumblr
Rubyには公式のものだけでも30本のブランチに29,385個のチェンジセットがある(執筆時点)。ブランチの1,000倍程度のチェンジセットがあるということは、実際にはブランチとチェンジセットの関係は偏りがあるから、ともかく長いブランチは超長いということがいえる。ちなみに一番長いのはもちろんtrunkで、この枝の長さは20,992リビジョンだ。次点がruby_1_8で、3,328リビジョンある(執筆時点)。 さてこのくらいの規模になってくると、もはや全容を把握するというのは困難である。特にどのブランチがどのチェンジセットから派生したかという情報は、もちろん個別には取り出すことは可能だが、俯瞰するのが困難になってくる。実際、今回ちょっとしたことでgit rebaseしようとしたらrebase先を間違えてしまい、ものすごく太古の昔からrebaseされてしまいげんなりするという体験をした(俺が本
超俺専用メモ「rubyのsvn->git gateway再構築方法」
一般化すれば他者にも有益な話題と思われるがとりあえずめどい。 方針 ありものをつかう回線に優しくてっとりばやくデータロスしないsetup OpenSSH multiple connection sharing以下の方式ではsvnサーバにつなぎに行っては「あ、やっぱ手元にあったわ」でコネクション切るというのを繰り返す感じなる。git-svn(1)頭悪いな。で、普通にそのままやるとSSHのセッションハンドシェイクが全体の時間に対して支配的になる上に、どう考えても回線の無駄なので、一旦作ったコネクションを使いまわすことで対応する。これはOpenSSHには普通に備わっている機能だ。~/.ssh/configに以下のように書いておく。 Host ci.ruby-lang.org User svn Hostname ci.ruby-lang.org IdentityFile ~/.ssh/id_rsa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
