コグノスケ


link 未来から過去へ表示(*)  link 過去から未来へ表示

link もっと前
2014年8月26日 >>> 2014年8月17日
link もっと後

2014年8月26日

hprofプロファイラ

Javaのhprofというプロファイラは、準備を必要とせず(JDK標準だから)に、CPU、ヒープ、モニタの衝突など、一通り測れる便利なプロファイラです。

特に各メソッドのカウントを「全て取る」モード(-Xrunhprof:cpu=times)は、明らかに呼び過ぎのメソッドが一発で分かるため、大変に便利です。

しかし便利な反面、実行速度が下がりすぎて使い物にならなくなる場合があります。

今日遭遇したケースは、7MBのファイルをDataInputStreamからreadByte() するプログラムです。通常のデバッグ実行であれば、ほんの一瞬で終わりますが、cpu=timesでプロファイリングすると10分経っても終わりません…。

どうも、細かいメソッドが頻繁に呼ばれすぎるせいで、メソッド呼び出しのカウントを行う部分がパンクしているようです。

思い出してみればInputStream系はInputStream -> BufferedInputStream -> DataInputStreamなどのように連鎖させるのでメソッド呼び出しが深く、データをロードするという処理はループ回数が多くなりがちなので、深さ×ループ回数の掛け算に比例してどんどん遅くなってしまいます。

これはよろしくありません。

頑張って軽くするには

待てるくらいの時間に収まるように、何とか軽くしてみましょう。

まず目を付けたのはreadByte() です。readByte() で1バイトつずつ読むから呼び出しカウントが多くなるわけです。ならばreadLong() で8バイトずつ読めばカウントは1/8です。

コードもちょい変えで済むし、お手軽高速化としては、プロファイリング時の実行速度もほぼ8倍になる、という中々の効果です。

しかしreadLong() を持ってしても100MBオーバーとなると厳しいでしょう。もし本当にそこまで必要なら、根底から覆す(InputStreamを使わないとか)別の手立てを考える必要がありそうです。

編集者:すずき(2014/08/26 03:15)

コメント一覧

  • IKeJIさん(2014/08/26 17:13)
    BufferedInputStreamのうしろは何回もは呼ばれないのでは?
  • すずきさん(2014/08/26 21:43)
    >IKeJI さん
    そうか、確かに BufferedInputStream 以降はあまり呼ばれないから、BufferedInputStream のバックエンドは呼び出し回数にほとんど関係無いですね。すみません、間違ってました。

    ただ BufferedInputStream 自体が結構遅くて、readByte() だとつらいという点は変わりません。
    試しに DataInputStream(new BufferedInputStream(new FileInputStream())) に対して、readLong() で 30万回読みだしてみますと、

    count : method
    307547 : java.io.BufferedInputStream.read
    307547 : java.io.DataInputStream.readLong
    307547 : java.io.DataInputStream.readFully
    307567 : java.io.BufferedInputStream.read1
    307568 : java.io.BufferedInputStream.getBufIfOpen
    307894 : java.io.BufferedInputStream.getBufIfOpen
    301 : java.io.FileInputStream.read
    3584 : java.io.BufferedInputStream.read
    301 : java.io.BufferedInputStream.fill

    こんな感じになっていて、getBufIfOpen がプロファイリングを激しく邪魔します。
  • IKeJIさん(2014/08/27 00:42)
    なるほど。
    その辺のprivateなメソッドはインライン展開できそうなもんですが、何かできない理由があるんですかね?
    BufferedInputStream.readをfinalにしたら早くなるんだろうか?
  • すずきさん(2014/08/27 02:09)
    >IKeJI さん
    BufferedInputStream をコピーした OreBufferedInputStream を作って、read を final にして試してみました。

    (final にする前)
    count method
    616787 net.katsuster.semu.arm.OreBufferedInputStream.read
    616787 java.io.DataInputStream.readFully
    616787 java.io.DataInputStream.readLong
    616787 net.katsuster.semu.arm.OreBufferedInputStream.read1
    616787 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
    617390 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
    603 java.io.FileInputStream.read
    2 java.io.FileInputStream.<init>
    3584 java.io.BufferedInputStream.read
    896 java.io.DataInputStream.readInt
    3584 java.io.BufferedInputStream.getBufIfOpen

    (final にした後)
    616787 net.katsuster.semu.arm.OreBufferedInputStream.read
    616787 java.io.DataInputStream.readFully
    616787 java.io.DataInputStream.readLong
    616787 net.katsuster.semu.arm.OreBufferedInputStream.read1
    617390 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
    616787 net.katsuster.semu.arm.OreBufferedInputStream.getBufIfOpen
    603 java.io.FileInputStream.read
    3584 java.io.BufferedInputStream.getBufIfOpen
    2 java.io.FileInputStream.<init>
    896 java.io.DataInputStream.readInt

    速度も変わらないですね。
  • IKeJIさん(2014/08/27 13:32)
    DataInputStreamがOreBufferedInputStreamをInputStreamとして扱っているからでしょうか?
  • すずきさん(2014/08/28 10:11)
    >IKeJI さん
    もしかして JIT でインライン展開されようとされまいと、関数呼び出しカウントは行われるんじゃないですかね?
    BufferedInputStream.read が遅いわけではないので、単にカウントが遅いのでは。
  • IKeJIさん(2014/08/28 14:26)
    そうですが、プロファイルしない時の実行速度はあがるのでは? > 関数呼び出しカウントは行われる
  • すずきさん(2014/08/29 17:02)
    >IKeJI さん
    プロファイルするときと、しないときとで、JIT の動作が変われば、インライン展開されそうなメソッドなのに、プロファイラにカウントされる理由が付きますかね…?
    うーむ、でも自分で書いておいてなんですが、そこまでやらないよな…さすがに…。
open/close この記事にコメントする



2014年8月24日

壊れないとしか言ってない

私のスマホは防水だけど、その意味は雨でも壊れない、であって、雨でも使える、って意味ではないんだなあ。

なぜなら、タッチパネルに水滴が着くとまともに動かないからです…。

メモ: 技術系の話はFacebookから転記しておくことにした。

編集者:すずき(2015/11/29 06:08)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2014年8月22日

ARMv5とARMv7アーキテクチャの名前について

ARMアーキテクチャを表すときARMv5Tがあって、ARMv6Tがないのはなぜでしょう?

ARMv5TのTの部分は「バリアント」と呼ばれ、TバリアントであればTHUMB命令セットに対応したARMアーキテクチャである、ことを示します。他にもエンハンストDSP命令のEとか、Jazzele命令のJがあります。

ARMv5まではTHUMB命令セットへの対応はオプションでした。このため、ARMv5世代のARMアーキテクチャはTHUMB非対応のARMv5とTHUMB対応のARMv5Tの2種類が存在し得ました。実際にTHUMB未対応のARMv5プロセッサを作った会社があるか、まではわかりませんが。そういうプロセッサを「作っても良い」ことにはなっていました。

例えば、携帯でよく使われていたARM926EJ-SプロセッサのアーキテクチャはARMv5TEJ、つまりTHUMBとエンハンストDSPとJazzeleに対応したアーキテクチャ、という意味です。

しかしARMv6からはTHUMB対応が必須となり、THUMBの有り/無しを区別する必要がなくなり、名前もARMv6のみとなりました。ARMv6はTHUMB命令セットに対応していてもARMv6Tとは呼びません。対応している機能を全部並べ始めると、冗長になるためでしょう、たぶん。

なお、エンハンストDSP命令もv6でARM命令セットに取り込まれたため、Tと同時にEバリアントも消滅しています。

ARMv7以降

さらに、最近のARMv7アーキテクチャでは、バリアントの考えが変わったようで、ARMv7の後ろに対応機能を意味するアルファベットは付かなくなりました。

種類もARMv7-AとARMv7-RとARMv7-Mの3つです。それぞれ「アプリケーション」「リアルタイム」「マイクロコントローラ」プロファイルの意味だそうです。対応する機能は下記の通り。

  • A: MMU、ARM、Thumb、Thumb-2、Thumb-2EE、NEON、32ビットSIMD
  • R: ARM、Thumb、Thumb-2(オプション)、VFP、32ビットSIMD、ハードウェア除算
  • M: Thumb-2、ハードウェア除算

アーキテクチャが対応する命令セットの規模順に並べたとき、ARMとなるところもまたニクいですね。イギリス人はこういうシャレが好きなのでしょうか?

これ以上の詳細情報はARMのサイト(ARMのサイトへのリンクを張っておきます)をご覧ください。

ARM命令セットとTHUMB命令セットの関係

余談ですが、ARM命令セットやTHUMB命令セットにもバージョンがあります。下記の通りです。

  • ARMv6 : THUMBv3
  • ARMv5 : THUMBv2
  • ARMv4 : THUMBv1

バージョンは1:1に対応しており、異なる世代を組み合わせること、たとえばARMv6とTHUMBv2を組み合わせることはできません。

メモ: 技術系?の話はFacebookから転記しておくことにした。なおARMv7の節は8/25に加筆。

編集者:すずき(2014/08/26 01:12)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2014年8月21日

マウス壊れた

一昨年買った(2012年4月5日の日記参照)、Logicool Perfomance MX M950が壊れました。マウスの左ボタンがバカになって、全部ダブルクリックになってしまう、良くある壊れ方です。

形あるもの、いつか壊れるとは思っていますが、1万以上したマウスが2年で壊れるのはちょっと悲しい。

Newマウス2号

存外に早く壊れた以外、使い勝手は最高に気に入っていたので、もう一個M950を買いました。アマゾンで8,226円でした。前回は12,000円したので、3割近く安くなっていますね。

しかし2年前のフラッグシップモデルだったM950が、未だにフラッグシップモデルとして君臨しているのはちょっと意外でした。余程の人気なのか、それとも新製品開発をあまりしていないのでしょうか。

Logicoolマウス愛好者としては、後者でないことを祈るばかりです。

保証期間

新たにやってきたM950の保証書を見てびっくり。保証期間「ご購入日から3年間」の文字が輝いています。

さ、3年…だと…?ということは、壊れたマウスは保証期間内?無料で直せちゃう感じ?マジで…?

普通のメーカー保証は1年で速攻切れる役立たずなイメージですが、3年ってすごいですね。さすがだなLogicoolさん。でも、もう保証書がどっか行ってしまったから、何年でも意味なかったりするのだけど…。今度は大事に取っておきます。

編集者:すずき(2014/08/21 23:24)

コメント一覧

  • hdkさん(2014/08/22 01:11)
    ロジクールの 1,500 円もしないマウスがなぜか 5 年保証で、1 年ちょっとでボタンのチャタリングが出たことがあったんですが、購入店で修理に出したら 1 か月かかって新品交換されてきました。交換後 5 年以上たっていますがチャタリングはもう出ていないので、個体差があるんですかねぇ。
  • すずきさん(2014/08/23 01:42)
    >hdk さん
    今まで使ってきたマウスも長持ちが多かったので、偶然外れを引いたのだと思います。
    しかし 5年は長すぎではなかろうかw
open/close この記事にコメントする



2014年8月20日

ファイルシステム対決

CentOS7 EXT4 vs XFS vs Btrfs vs ZFS on vda - Qiita を読んで。

参考になります(※1)。ZFSはFUSE経由じゃないNative実装があるのか…知らなんだ。

(※1)補足。この手のベンチマークはたくさんあるように見えて、ファイルシステム側の進化が早いため、すぐに陳腐化します。なので、新しいベンチマークは常にありがたいものです。

XFSは1MB overのデカいファイルは速いけど、1KBくらいの細かいファイルのcreate/deleteをぶちかます(カーネルのtarballを展開しながら、古いカーネルソースをrm -rするとか)と、すっごい遅くて嫌になって使うの辞めた記憶があるのだけど…改善されたのだろうか?

メモ: 技術系?の話はFacebookから転記(※2)しておくことにした。

(※2)本来8月14日のエントリです。8月14日辺りでエミュレータが動いたのが嬉しくて、浮かれてFacebookに書きまくったら、このサイトに転記しきれなくなったため、未来のエントリに移動させています。

編集者:すずき(2014/08/16 16:40)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



2014年8月19日

C言語はいくらでもメチャクチャに書ける

目次: C言語とlibc

switch文を使ってはいけないを読んで。

PHPはさておいて。私もswitchよりStateパターンを選びますが、C言語の関数ポインタでStateパターンを実現するのは、今も迷います。言語仕様上、悪い方に倒れるのを阻止できないためです。

ハッカーが明確で読みやすいコードを書いてくれるうちは良いですが、頭のおかしい人がdoという関数ポインタに全関数を入れるクソコードを書き始めたらもう全部パアです。

いやまさかそんなこと、と思うかもしれませんが、どこの会社とは言いませんがそんなクソコードが実在してるんですよ、世の中って怖いですよね…。

ワルいコード

この記事(コードのネストを深くするな)を読んでいたら、会社のクソコード山脈を思い出しました。

7段ifなんて序の口。世の中の悪手とされる書き方は、大概やってるワルい奴です。バグも多い…。

メモ: 技術系?の話はFacebookから転記(※)しておくことにした。

(※)本来8月14日のエントリです。8月14日辺りでエミュレータが動いたのが嬉しくて、浮かれてFacebookに書きまくったら、このサイトに転記しきれなくなったため、未来のエントリに移動させています。

編集者:すずき(2023/04/29 21:49)

コメント一覧

  • すずきさん(2014/08/18 11:44)
    C 言語だと do はキーワードなので、変数名としては使えないので、exec ですかね…。文意に変わりはありませんけど。
  • IKeJIさん(2014/08/26 17:08)
    main = 195;
    みたいなもんですか?
  • すずきさん(2014/08/26 21:20)
    >IKeJI さん
    コードゴルフなら超短い、その手があったか!など発見や感動がありますが、クソコードは無駄に長いし、発見もないです。
    まあ、良くこんなのメンテナンスできますわねー、って違う意味での感動はありますけど…。
open/close この記事にコメントする



2014年8月18日

私の常識はあなたの非常識

【レビュー】超小型PC「Raspberry Pi」で夏休み自由課題・第1回 - Raspberry Piとは? 入手とセットアップ (1) Raspberry Piでコンピューターを学ぼう を読んで。

"Raspberry Piは少々とっつきにくい。買ってくると基板が入っているだけで、電源をつないでも動かないのだ。"(引用)

え!そうなの?

SDカードにtarball一個解凍するだけで使えるようになるので、一番とっつきやすい部類だと思ってました。

いつの間にか一般的な理解と乖離していたみたいです。うーん、認識を改めなければいかんなー…。

メモ: 技術系?の話はFacebookから転記(※)しておくことにした。

(※)本来8月13日のエントリです。8月14日辺りでエミュレータが動いたのが嬉しくて、浮かれてFacebookに書きまくったら、このサイトに転記しきれなくなったため、未来のエントリに移動させています。

編集者:すずき(2014/08/16 16:38)

コメント一覧

  • コメントはありません。
open/close この記事にコメントする



link もっと前
2014年8月26日 >>> 2014年8月17日
link もっと後

管理用メニュー

link 記事を新規作成

<2014>
<<<08>>>
-----12
3456789
10111213141516
17181920212223
24252627282930
31------

最近のコメント5件

  • link 24年4月22日
    hdkさん (04/24 08:36)
    「うちのHHFZ4310は15年突破しまし...」
  • link 24年4月22日
    すずきさん (04/24 00:37)
    「ちゃんと数えてないですけど蛍光管が10年...」
  • link 24年4月22日
    hdkさん (04/23 20:52)
    「おお... うちのHHFZ4310より後...」
  • link 20年6月19日
    すずきさん (04/06 22:54)
    「ディレクトリを予め作成しておけば良いです...」
  • link 20年6月19日
    斎藤さん (04/06 16:25)
    「「Preferencesというメニューか...」

最近の記事3件

  • link 24年2月7日
    すずき (04/24 02:52)
    「[複数の音声ファイルのラウドネスを統一したい] PCやデジタル音楽プレーヤーで音楽を聞いていると、曲によって音量の大小が激しく...」
  • link 24年4月22日
    すずき (04/23 20:13)
    「[仕事部屋の照明が壊れた] いきなり仕事部屋のシーリングライトが消えました。蛍光管の寿命にしては去年(2022年10月19日の...」
  • link 24年4月17日
    すずき (04/18 22:44)
    「[VSCodeとMarkdownとPlantUMLのローカルサーバー] 目次: LinuxVSCodeのPlantUML Ex...」
link もっとみる

こんてんつ

open/close wiki
open/close Linux JM
open/close Java API

過去の日記

open/close 2002年
open/close 2003年
open/close 2004年
open/close 2005年
open/close 2006年
open/close 2007年
open/close 2008年
open/close 2009年
open/close 2010年
open/close 2011年
open/close 2012年
open/close 2013年
open/close 2014年
open/close 2015年
open/close 2016年
open/close 2017年
open/close 2018年
open/close 2019年
open/close 2020年
open/close 2021年
open/close 2022年
open/close 2023年
open/close 2024年
open/close 過去日記について

その他の情報

open/close アクセス統計
open/close サーバ一覧
open/close サイトの情報

合計:  counter total
本日:  counter today

link About www.katsuster.net
RDFファイル RSS 1.0

最終更新: 04/24 08:36