ksメモ

私が学んだことを記載したメモです。あとポエム。

Macを修理に出した

背景

2ヶ月くらい前からキーボードの挙動がおかしくなってました。保証期間の内だったので修理を出して無事に戻ってきました。最新MacBook Proはキーボードの耐久性に問題があるみたいなので、ブログにて情報共有しておきます。

不具合の内容

私が使っているのはMacBook Pro 15インチ 2017年モデルです。Touch Barを搭載した2世代目のモデルですね。このパカパカするバタフライキーボードは気に入っているのですが、一方で耐久性に問題があるとよくネットで噂されているのは知っていました。

ある日、いつも通りMacを起動してプログラミングをしていると、入力の挙動がおかしいことがわかりました。JavaScriptで最初の一行を書いたらなんと以下のように。

immport React fromm 'react'

「"m"が2回入力になっている。。。こんなミスほとんどしないし、もしかしてチャタリングか?!」

不安は見事に的中し、キーボード入力を確認すると"m"と"n"で稀にチャタリングが発生してました。とりあえず他に同様の事象が報告されていないかぐぐってみました。

MacBook Pro 2016 (15インチ)のバタフライキーボードが購入後わずか1ヶ月で故障した件 - なすぶろぐ、弱火でじっくり。

MacBook Pro 2017モデルではキーボードが改良され、2016モデルで発生していたキー音の問題などが修正されているもよう。 - AAPL Ch.

↑2016年モデルでも同じ不具合が発生したというブログポストを見つけました。一方で、"2017年モデルはキーボードも少し改善されている"という記事も。たまたま運が悪いだけかな?

MacBook、MacBook Proのキーボード、一部が反応しない問題が多発か - iPhone Mania

↑いやいや、やっぱり問題は残っている様子。。いちおうエアダスターを購入してキーボードの掃除をしてみたのですが、あまり効果が見られなかったです。

Genius Barに行く

渋谷のApple Storeを予約して、さっそくGenius Barへ。予約していたのですぐに診てもらうことができました。5回中1回ほどの確率でチャタリングが発生するという再現性が怪しい不具合だったのですが、快く対応してもらえました。

店員さん「ちょっとおかしい感じですね。問題のキー2つのキートップを交換してみてもいいですか?」

私「お願いします」

待つこと15分くらい・・・

店員さん「交換しました。その際に掃除もしておきました。しばらくこれで様子を見てもらえませんか?」

私(お、確かに直ってる!)

というわけで、またしばらく使ってみることにしました。

しかし、また不具合が発生する

発生頻度は減少したのですが、やはり稀に"m"と"n"でチャタリングが発生しました。

「我慢できなくはないけど…。またGenius Barに持っていくか?めんどくさいなー」とちょっと渋っていました。

ところが、他のキーにも不具合が出始めました。具体的には"b"と"k"が反応したりしなかったり。不具合が発生するたびにエアダスターで掃除するのを繰り返していましたが、さすがに嫌気が差してきました。

そしてある日、またキーが反応しなくなったためエアダスターで掃除しようとOSを終了したら、終了時にOSがクラッシュ。ぼくのSierraはOS再インストールを要求してくるようになりました。High Sierraへ強制的に新陳代謝をさせられました。\(^o^)/

今度は修理に出す

渋谷のApple Storeは休業中のようで、Appleサポートに電話してビックカメラ渋谷東口の正規プロバイダーを案内されました。そこで修理に出し、5日で無事に戻ってきました。よかったよかった。もちろん保証期間内なので無償でした。

ただ、ちょっと気になった、というかショックだったのが「万が一、水濡れだったりすると修理の値段が上がりますので」と念を押されたことですかね。店員さんは説明しないといけない立場だと思うので、仕方ないとは思うのですが。。こっちは30万円も出した高級ラップトップが壊れてすごくがっかりしているのに。Genius Barで対応してもらったときは水濡れとかの話は出なかったし、キートップを変更してもらったときもそんな話題は出なかったし。

MacBook Pro 15inch 2017

今年の7月にMacBook Pro 2017の15インチを購入しました。SSDだけ256GB→512GBにして30万円。「高っ!」と思いながらも、新しいプライベート開発マシンがほしくて買いました。その感想を適当に書いていこうと思います。

サマリ

  • 結論
    • やっぱりMacは良い
  • 良かった点
    • TouchBarは割と使いやすい
    • キーボードは軽くて打ちやすい
    • 15インチでもすごく軽いので持ち運びもOK
  • 気に入らない点
    • 耐久性に欠けるキーボード?
    • バッテリーは持ちが良くない

筆者の使い方

  • 仕事はLet's Note
  • 自宅ではこのMacBook Pro
  • 主に休日に趣味のプログラミングで利用
    • 1日に3-4時間はタイピングしていると思う
  • Macを触るのは4年ぶり

久々にMacを触って

私はMacを使っていたのはSnow Leopardの頃なので、実に4年ぶりにMacを使いました。その4年間はずっとWin7, Win8, Win10, Ubuntuなどを使っていました。 久々にMacを触った感想ですが、 ”めちゃくちゃ良いOSだな” という感じです!いや、最近のWin10も頑張っててすごく使いやすいのはもちろんわかってます。ですが、環境設定のやりやすさ、ソフトウェアの入れ方、細かい美しさなどは、さすがMacという感じです。

また、これは開発者の意見ではありますが、ターミナルが使えるのはすごくいいですね。Win10もBash on Windowsが使えるようになっているのですが、やはりMacのターミナルの方が使いやすいですね。zsh入れて、いい感じな開発環境にしちゃってます!

TouchBar

かなり気にって使っています。同僚から「使いにくい、あんなのいらないよ」と聞いていたので不安だったのですが、私はいいなーというポジティブな印象です。

  • 音量や輝度を指でアナログ的に調整できるのはすごく便利
  • Safariを使えばYoutubeのシークバーがTouchBarに表示されて、これも便利
  • TouchIDが使えると、パスワードをいちいち入力しなくて良い
  • ESC、ファンクションキーの入力はそんなに気にならない
    • 普段からあまり使ってないから
    • vimでもESC使わないし

キーボード

これは良い点と悪い点がある感じですね。まず良いのは、非常に入力が軽くなったと思います。最初はなかなか慣れませんが、慣れてくると”あまり手のパワーを使わなくても入力できるんだなー”と実感できました。

一方で、バタフライキーボードは繊細な構造をしているらしく、ちょっと壊れやすい印象です。と言いますのも、どうもチャタリングをよく起こしているように感じています。実はnとmのキーが、ときどき1回のタイプで2回入力になって困った時期がありました。これがプログラミングしているときに発生するとすごくイライラするんですよね…

import React from 'react' // 正しい入力
immport React fromm 'react' // チャタリングが発生して、こんな感じになっていることも…

Genius Barに言って、キートップの入れ替えと掃除をしてもらいました。そうすると発生頻度はかなり減少しました。それでもときどき発生します。保証期間はまだあるので、もう少し様子を見てみることにしてます。

軽い

これは本当にびっくりしてます。以前はSnow Leopard時代の15インチを使っていたのですが、すごく重くて持ち運びがけっこう億劫になっていました。でも今の15インチは すごく軽くて、持ち運びもできちゃいます。これはかなりサイコーです。

ただ、バッテリーの持ちはあまりよくない気がしていています。バッテリーの大きさを少なくして、その分が軽くなったという具合みたいですね。私は軽いという方が体験として大きい気がしているので満足しています。

USB Type C

これはよくわからないです。充電で使うだけで、外部ディスプレイにつなげる事などがないので。

最後に

久々にMacを使っているので、やっぱりMacは良いなという感じがしています。 周囲では”Macは面白みがなくなった”と言っている人がいますが、それはMacに慣れすぎちゃっただけじゃないかなーと思いっています。

鉄血のオルフェンズから学んだリーダーシップ

機動戦士ガンダム 鉄血のオルフェンズが完結してから約半年といったところでしょうか。最終回に近づくに連れてハラハラしながら視聴していたのを覚えています。自分の中では、歴代で見たアニメの中でトップ5に入るくらいの評価をしています。ただ、会社の後輩たちに評価を聞いてみると「いまいちでしたよね」と辛口なコメントでした。まぁ評価は人それぞれだからなー、と思ったら、Amazon Primeでの評価も散々なことになっていてビックリしました。

なぜ自分は鉄血のオルフェンズという作品に対してここまで熱い思い入れがあるのか、ちょっと考えてみて文字に起こしてみることにします。

まだ鉄血のオルフェンズを視聴されていない方は、ネタバレ注意です

サマリ

  • 作品で描かれているリーダーシップに共感した
  • オルガはリーダーとして選択を誤ってしまった
  • それでも自分はオルガのようなリーダーを望むし、自分もそうありたいと思った

なぜここまで感動したのか

結論を先に書くと、自分が現実で置かれていた状況とすごくリンクするものがあったからです。ちょうどオルフェンズを視聴していた時期、自分はあるエンジニアリングチームのマネジャーになったばかりでした。

どのようにマネジャーとして振る舞うべきか考えていたときに、オルフェンズを視聴していると「このアニメはリーダーシップをテーマにしているのではないか?」と思い始めました。今までの自分のガンダムシリーズの視聴と違う見方が出てきました。特に鉄華団オルガ・イツカのリーダーシップにはすごく共感してしまい、自分のエンジニアのマネジメントと照らし合わせて見ていると、震えが出ました。

ちなみに、鉄血のオルフェンズとリーダーシップの関連性をすでに先行して書いてらっしゃる方がいましたので、そちらのリンクも貼らせていただきます。

鉄血のオルフェンズと適応のリーダーシップ

登場するリーダーシップ

リーダーポジションの人物は何名か登場するのですが、物語のメインキャラクターである以下の2人について書いてみることにします。

私が物語を見ていて思った2人の違いは、問題の解決方法の違いです。

  • オルガ
    • 物事をやり遂げるという強い意志を持っている
    • その障害となるものは排除するという気が強い
  • クーデリア
    • 物事をやり遂げるという強い意志を持っている
    • ときには妥協もする、調和を大切にしながら目的を達成するという考え

両者、強い信念を持っていて、自らの考えを曲げようとはしない。これはリーダーに必要な要素です。違いポイントは、壁にぶつかったときの対処方法が違うというところです。

オルガは非常にアグレッシブなタイプのリーダーです。常に上を目指し続けますし、その障害となる問題は排除する(武力でなんとかする)傾向があります。実際、鉄華団はそうやって大きくなった組織であり、その成功体験が彼にはあったからです。 しかし、その方法では上手く行かなくなってくる時期が突然に訪れます。物語が最後になるにつれて、彼は自らの選択が本当に正しかったのかというプレッシャーにひどく悩まされてしまいます。彼の決断の結果、鉄華団はとてつもない強大な敵を作ってしまい、チームは破滅に追い込まれてしまいます。

一方のクーデリアですが、彼女も大きな野望を持っています。野望を達成するためには、彼女がいま持っている地位や権力など、圧倒的に足りない状況でした。なので彼女は、最初は鉄華団という武力に頼り目的を達成しようとします。鉄華団とはウィン・ウィンの関係にあり、これは上手くことを運びました。 最初は武力を許容していた彼女ですが、ある程度の権力を持つと、武力以外のやり方で物事を成し遂げようと様々な施策を試みていきます。なるべく争いは避け、なるべく敵を作らず(誰からも嫌われず)に事業の拡大を目指しました。

クーデリアが理想のリーダー

間違いなくクーデリアは理想的なリーダーだったと思います。彼女の行動は周りから支持され、最終的に目的を達成できたのはオルガではなくクーデリアでした(※)。彼女が目的を達成できたのは以下のリーダーとしての素養があったからだと考えています。

  • 周りの状況に合わせて柔軟に行動を変える
  • 相手に共感する
  • そのため、たくさんの人が協力をしてくれる

大きな目標は、1人では達成できません。彼女は周りからの支持を得られる行動をしていました。そこがオルガとは違ったポイントでした。

※オルガは「すでに目的は達成していた」と気づいて亡くなります。しかし鉄華団の最も危ういタイミングで逝ってしまった彼は、その問題を解決することができなかったので、私は彼の目的は達成できなかったと解釈しています。

それでもオルガの方がいい

アニメを見ていて思っていたことがあります。

  • オルガのやり方は良くないよな…
  • これ絶対にあとで失敗しそう…
  • クーデリアは皆が望むリーダーシップを発揮している
  • 彼女は成功するかも?

実際に上記の予想は当たってしまい、なんとも切ない最終回を迎えてしまいます。オルガの行動は攻撃的だったし、多くの敵を作ってしまったのは間違いありません。反して、クーデリアは理想的なリーダーシップを貫き、夢を実現しました。しかし、かといってクーデリアのようなリーダーが本当に良いかと言うと、私は以下のように思うのです。

クーデリアのように周りに気を使って自らが犠牲になる。好きな男性も譲ってしまう。 そんなリーダーに誰がなりたいんだろう?

リーダーも1人の人間だし、個人としてやりたいこと、達成したい幸せもあると思います。 エンジニアリングのマネジメントに関してもそうです。自分よりコードが書けないメンバーのマネジメントをして、自分は技術から遠ざかっていく日々。チームのために自らを犠牲にして仕事をやるのは本当に正しいのかと。

オルガは結果として失敗しますが、彼の行動は多くの人を惹きつけ、鉄華団の結成という大きい成果をもたらしました。周りを気にせず自分のために行動する、その姿はマネジャーとして大きく憧れるところがありました。

以上、鉄血のオルフェンズを見て思った次第でした。

1-on-1を半年くらいやったので、振り返ってみる

今年の初めに5人ほどのチームのマネジャーになりました。その時、1-on-1というマネジメント術があることを知ったばかりで、すごく試してみたいというモチベーションがあり、やってみることにしました。その知見などを共有できればと思います。

1-on-1とは?

私がやってきた1-on-1は以下のとおりです。

  • 隔週(ときどき毎週)で部下と1対1で面談を実施する
  • 1回の面談は30分〜1時間くらいの長さ
  • 対話するより、話を聞いてあげる

いろんなブログポストや書籍を読んだのですが、それぞれで1-on-1の定義が微妙に違ったりします。そのあたりはマネジャーの好みや、使える時間もあるので、自分にあった1-on-1をすればいいんじゃないかなーと思っています。毎週or隔週は、その部下のモチベーションなどによって、「あ、この人とは来週もやったほうがいいな」みたいな感じで決めていました。

ちなみに、1-on-1について参考にしたのは以下です。

具体的な手法の参考

”ヤフーの1on1”は詳細な手法を取り扱っている数少ない書籍だと思います。すごくおすすめです。もっとこの本が早く発売されてたら、最初から上手くやれてたのかなーと思ったり。

その他、ちょろっと触れられているもの

1-on-1のために読む書籍ではないが、マネジメント観点だと面白いので共有。

メリットとデメリット

いきなり本題ですが、メリットとデメリットを記載します。正直、メリットのほうが多い気がしていて、デメリットはさほど気にならないです。

メリット

大きく3つのメリットがあったので、それぞれをかんたんに説明します。

  1. チームの問題がわかる
  2. 自分のマネジメントのフィードバックをもらえる
  3. 飲みに行かなくてもコミュニケーションが活発になる

1.チームの問題がわかる

一番のメリットはこれです。話を聞いていると、「何を不安に思っているのか」「なんでやる気をなくしているのか」そういったマネジメント的に重要なことが手に取るようにわかるようになってきます。

任天堂岩田聡さんが以下の発言をされていますが、まさにこの通りだなと思っています。

「人は逆さにして振らないと
 こんなにもモノをいえないのか」
とあらためて思いました。
いろんな人に面談すればするほど、
わたしはいろんなことがわかりまして、
そのなかから
どういうふうに
組織を作りなおして、
どういう運営をしたらよくて、
なにがみんなのやる気を
ひきだすことに役にたっていて、
なにがみんなの
やる気を阻害しているのかとか……
すべて見えてくるんですね。

2.自分のマネジメントのフィードバックをもらえる

マネジャーというポジションにもなると、フィードバックを伝える機会はあるものの、逆にもらう機会は少なくなります。私は以下のように質問をして、部下からフィードバックをもらうようにしていました。

  • マネジャーとして、私ができることはある?
  • 私に対して何かフィードバックある?
  • 今のチームをどう思う?

ただし、後ほど記載するのですが、1-on-1をはじめたばかりの頃は、まだ部下は警戒をしている可能性があるので、率直なフィードバックはもらえていない可能性があります。

3.飲みに行かなくてもコミュニケーションが活発になる

今まで部下と仲良くなるためには「飲みに行って、腹を割って話すか」みたいに思っていたのですが、そんなことはなくなりました。むしろ今までの考えだと、お酒が苦手なメンバーとは仲良くなれてなかったんだなぁと、強く反省をする機会にもなれました。

デメリット

  1. 時間が必要になる
    • 部下の数によっては、1-on-1実施はそこそこの工数になってしまう
    • →あらかじめ1-on-1の時間を考慮して自身のタスク管理が必要です。
  2. 優しくあろうとしてしまう
    • 部下の率直な気持ちを聞けることで、部下に嫌われないように振る舞いがちになる
    • →優しくなりすぎて、マネジャー側がほいほい仕事を巻き取ることがないように注意
    • →部下がやりたい仕事と、チームとしてやらなきゃいけない仕事、あきらかに後者が優先なので

1-on-1体験記

実際に1-on-1をやってみてからの苦労話などを共有します。

最初の一歩

私の場合は、マネジャーを前任から引き継ぐ形だったので、そのタイミングで部下全員と面談を実施しました。そのときに、「この面談ですけど、隔週くらいでやらせてください」と伝えて1-on-1につなげました。なので、かなり違和感はなく1-on-1を導入できたのではないかと考えています。

最初の1-2ヶ月

マネジャーとして、精神的にぐっと耐える時期だと思います。なぜなら、1-on-1をしているからといって、すぐに部下がいろいろと話しをしてくれるわけではないからです。なかなか本音を言ってくれない部下も何人かいました。このときに「1-on-1やめようかな」と思ってしまうとダメだと思います。根気よく続けていくことが、マネジャーの仕事になります。個人的には3ヶ月を過ぎたあたりで、成果が出てきたように感じました。

話すことがない部下には?

適当に雑談をしていました。こちらも最初は相手の趣味や思考などがわからないため、雑談のテーマは何がいいかわからないと思います。しばらく1-on-1を続けると、どんなことに興味があるのかがわかってくるので、雑談はそう困らないです。

まとめ

1-on-1はチームを成長させるために非常によいマネジメント手法だと今では考えています。今後も続けていこうと思っています。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

つぶやき

新しいMacBook Proでこのブログを書いてますが、キーボードがカパカパして微妙だなぁ…

MNISTチュートリアルを実行するときにdateutilのバグを踏んだ

TensorflowのMNISTチュートリアルを実行しようとしたときにエラーで落ちた。 たぶん同じバグを踏む人は多いと思うので、メモがてら共有。

発生条件

どうやらチュートリアル用のMNISTサンプルをimportするときに発生しているみたい。

from tensorflow.examples.tutorials.mnist import input_data

自分のPython環境はAnacondaです。

$ python -V
Python 3.5.2 :: Anaconda custom (64-bit)

エラー内容

ちょっと長いので省略して書くが、以下のような内容で落ちる。

$ python main.py
I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcublas.so locally
I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcudnn.so locally
I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcufft.so locally
I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcuda.so.1 locally
I tensorflow/stream_executor/dso_loader.cc:128] successfully opened CUDA library libcurand.so locally
Traceback (most recent call last):
  File "main.py", line 2, in <module>
    from tensorflow.examples.tutorials.mnist import input_data
  File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/tensorflow/examples/tutorials/mnist/__init__.py", line 21, in <module>
    from tensorflow.examples.tutorials.mnist import input_data
  File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/tensorflow/examples/tutorials/mnist/input_data.py", line 29, in <module>

#省略

  File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/pandas/__init__.py", line 22, in <module>
    from pandas.compat.numpy import *
  File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/pandas/compat/__init__.py", line 350, in <module>
    from dateutil import parser as _date_parser
  File "/home/hogehoge/.pyenv/versions/anaconda3-4.1.1/lib/python3.5/site-packages/dateutil/parser.py", line 158
    l.append("%s=%s" % (attr, `value`))

ググったらdateutilのバグみたい

ここに、「それはdateutilのバグだね」って書いてあった

Error when importing pandas in Python 3 · Issue #551 · hashdist/hashstack · GitHub

dateutilをアップグレードしたら直った

直し方は単純で、アップグレードしてやればよい。これで終了。

$ conda install -c conda-forge python-dateutil=2.6.0

Python Dateutil :: Anaconda Cloud

CUDAのサンプルで"cannot find -lGL"でハマった件

ちょっとハマった、というか「しょーもな」って感じのポイントなんだけど。いちおうメモしておく。

CUDAをインストールしたら、まずはsampleを動かしてみたくなるんだけど、nbodyをビルドしようとしたら以下のエラーが発生した。OSはUbuntu 14.04.5、CUDAは7.5。

$ cd /usr/local/cuda/samples/5_Simulations/nbody
$ make
>>> WARNING - libGLU.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
>>> WARNING - libX11.so not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
>>> WARNING - gl.h not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
>>> WARNING - glu.h not found, refer to CUDA Getting Started Guide for how to find and install them. <<<
>>> WARNING - Xlib.h not found, refer to CUDA Getting Started Guide for how to find and install them. <<<

はーん。OpenGL関連がないのかー。
なのでapt-getで必要そうなライブラリをインストールする。

$ sudo apt-get install freeglut3-dev libglu1-mesa-dev

これでmakeし直したらいいと思ったら、「libGLなんて見つからないよ」とエラーが出てきた。

$ sudo make
"/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -I../../common/inc  -m64    -ftz=true -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o bodysystemcuda.o -c bodysystemcuda.cu
"/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -I../../common/inc  -m64    -ftz=true -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o nbody.o -c nbody.cpp
"/usr/local/cuda-7.5"/bin/nvcc -ccbin g++ -I../../common/inc  -m64    -ftz=true -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o render_particles.o -c render_particles.cpp
"/usr/local/cuda-7.5"/bin/nvcc -ccbin g++   -m64      -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o nbody bodysystemcuda.o nbody.o render_particles.o  -L../../common/lib/linux/x86_64 -L/usr/lib/"nvidia-352" -lGL -lGLU -lX11 -lglut -lGLEW
/usr/bin/ld: cannot find -lGL
collect2: error: ld returned 1 exit status
make: *** [nbody] Error 1

いや、そんなはずはない。さっきインストールしたでしょ?
と思ってlocaleとか使って調べたら、なんか変なシンボリックリンクが貼ってあってあるだけだった。
ブログだと色がついてないからわかりにくいと思うけど、libGL.soの参照先が存在しないファイルを指定してる。
#同ディレクトリに「libGL.so.1.2.0」はない
#素のUbuntuターミナルだと赤色になっていると思う。

$ ll /usr/lib/x86_64-linux-gnu/mesa/
total 76
drwxr-xr-x  2 root root  4096  9月 25 00:16 ./
drwxr-xr-x 95 root root 69632  9月 25 00:16 ../
-rw-r--r--  1 root root    31  7月  1 05:45 ld.so.conf
lrwxrwxrwx  1 root root    14  1月 13  2016 libGL.so -> libGL.so.1.2.0

下記の方法がよいかわかんないけど、libGLがちゃんとある場所にシンボリックリンクを指定してあげることにした。

$ cd /usr/lib
$ sudo ln -s /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0 libGL.so

これでビルドしたら上手くいった。
やっぱりGPGPUと言えばこのsampleですよねー。

$ sudo make
"/usr/local/cuda-7.5"/bin/nvcc -ccbin g++   -m64      -gencode arch=compute_20,code=sm_20 -gencode arch=compute_30,code=sm_30 -gencode arch=compute_35,code=sm_35 -gencode arch=compute_37,code=sm_37 -gencode arch=compute_50,code=sm_50 -gencode arch=compute_52,code=sm_52 -gencode arch=compute_52,code=compute_52 -o nbody bodysystemcuda.o nbody.o render_particles.o  -L../../common/lib/linux/x86_64 -L/usr/lib/"nvidia-352" -lGL -lGLU -lX11 -lglut -lGLEW
mkdir -p ../../bin/x86_64/linux/release
cp nbody ../../bin/x86_64/linux/release

$ ./nbody 
Run "nbody -benchmark [-numbodies=<numBodies>]" to measure performance.
    -fullscreen       (run n-body simulation in fullscreen mode)
    -fp64             (use double precision floating point values for simulation)
    -hostmem          (stores simulation data in host memory)
    -benchmark        (run benchmark to measure performance) 
    -numbodies=<N>    (number of bodies (>= 1) to run in simulation) 
    -device=<d>       (where d=0,1,2.... for the CUDA device to use)
    -numdevices=<i>   (where i=(number of CUDA devices > 0) to use for simulation)
    -compare          (compares simulation results running once on the default GPU and once on the CPU)
    -cpu              (run n-body simulation on the CPU)
    -tipsy=<file.bin> (load a tipsy model file for simulation)

NOTE: The CUDA Samples are not meant for performance measurements. Results may vary when GPU Boost is enabled.

> Windowed mode
> Simulation data stored in video memory
> Single precision floating point simulation
> 1 Devices used for simulation
> Compute 5.2 CUDA device: [GeForce GTX 980 Ti]

f:id:ksakiyama134:20160925004830p:plain

LLVM3.9をインストールする

冬コミのネタなんかないかなーと思ってて、「そういえばLLVM3.9出たのかー」と思ってとりあえずインストールしてみた。ちなみにOSはUbuntu14.04を使ったよ。


LLVM Download Page
↑ここから「LLVM source code」をダウンロードしてくる。


いつも通りcmake使ってビルドするかー、と思ったら最新のcmakeが必要になってた。


$ mkdir build
$ cd build/
$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/llvm-3.9 ..
CMake Error at CMakeLists.txt:3 (cmake_minimum_required):
  CMake 3.4.3 or higher is required.  You are running version 2.8.12.2


-- Configuring incomplete, errors occurred!
$ cmake --version
cmake version 2.8.12.2


まぁ仕方ないのでcmakeの最新版を取得して、ビルドとインストールした。
#cmakeも今は最新が3.6.2とかなんだ。へぇ〜。

Download | CMake
↑ここから「cmake-3.6.2.tar.gz」をクリックして落とす。


$ cd cmake-3.6.2
$ ./configure
$ make -j4
$ sudo make install


割とすんなりインストールできた。で、LLVMのビルドに再チャレンジ。


$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local/llvm-3.9 ..
-- No build type selected, default to Debug
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- The ASM compiler identification is GNU
-- Found assembler: /usr/bin/cc


上手くいったみたい。あとはmakeするだけ。
#なんか最後の98%くらいで「やけにChrome重いなー」と思ったら、
#メモリ使用率が13GBとかなってビビった。


$ make -j4


make終わったしあとはinstallだけだなと思ったら、HDDの容量が少なくなっててインストールできないことに気づいた!!!
たぶんinstallしたら10GBくらい使うのかな?ビルドしたディレクトリも13GBになってた。1TBのHDDに交換したら再チャレンジするか。。。


$ du -d 1 --block-size=M .
263M    ./cmake-3.6.2
13875M  ./llvm-3.9.0.src


==
はてなダイアリーからはてなブログに移行しました。
#ダイアリーの方→ksメモ