chroot("/home/hibari")

備忘録とかに使えそうなノート

社会人博士としての博士課程を振り返り

タイトルの通り博士課程に進学しました。そして無事に博士(工学)の学位を取得することができました。
といってもストレートで進学した訳ではなく、社会人博士として通常課程で入学していました。
そして某氏に触発されて自分もこの手の怪文書を書こうかと思い始めました。思った以上は「鉄は熱いうちに打て」のごとく動いておいた方が身のためなので、頑張って小学生並みの感想文をふわっと書いていきます。

 

なぜ社会人博士をやろうと思ったのか

結論から言うと、いまだに謎です。
記憶しているのは、入学する前の12月になって急に「社会人博士やるか」と思ったことだけです。たまにあるじゃないですか、全ての論理をスキップして急に結論が頭に浮かぶこと。
そういうことで急遽研究室の指導教員に連絡し、社会人博士として受け入れていただけるかのご連絡・ミーティングを行い快諾していただけました。もとより「博士を取れると確信している人しか受け入れない」とおっしゃっていたため、取れるとのご判断をいただけたと思う。
そしてあれよあれよといううちに入試、合格、入学と駒を進めて社会人博士としての生活の準備が整いました。
入学金や授業料の振込登録のために訪れた場所が銀行ではなく系列の証券会社で、窓口で諸々を渡してから「あの、こちらは証券ですので場所をお間違えかと...」とスタッフ様を困らせてしまったのは良い思い出。

 

D1

社会人博士といえど、通常課程で入学しているため当然単位を取らなければなりません。とはいえ、学士・修士に比べれば必要な単位数はよっぽど軽量であるため、大きく苦労することはないです。

 

...と、最初は思っていました。

 

なにせ社会人であるため普段の業務があり、研究があり、その上で講義を受けてレポートを作成・提出しなければならないからです。このご時世となってオンライン化が進んでいることもあり、リモートでの受講が可能であったことが唯一の救いで、これがなければ最初から挫折の未来が待ち受けていたかもしれません。
このような背景から、仕事・研究・講義の3つを並行して進めるいきなりハードモードな生活での幕開けとなりました。「どうして私は今こんなことをしているのか」と思った回数、数知れず。

なんとかして講義を無事に乗り切るものの、その空いた時間分研究に流れ込むだけなので日々の大変さは全く変わらずでした。この時の自分の生活スタイルは非常にシンプルで、

平日:起きる→仕事する→研究する→寝る
休日:起きる→研究する→寝る

これを週7で繰り返す。これだけです。当時明確な自粛期間ということもあり、良くも悪くも引きこもりをせざるを得なかったのである意味ちょうどよかったです。書くのは簡単ですが実際はやはり大変で、日々の睡眠時間が2〜4時間程度だったと思います。
こんな生活をしているとガタがくるのは明白で、仕事中に体を壊してしまいました。熱が40度ほどに達しており人生初の救急車を呼びました。救急隊員がきてくださったものの、このご時世で発熱となると受け入れが難しいとのことでそのままお帰りになられました。当時は病院のスタッフもとても大変でしたでしょうから、致し方ないことです。
こんな目に遭っておきながら懲りてないのか、快復してからまた↑の生活に逆戻りしていました。一般にジャーナルに関しては投稿してから採択されるまでには大きく時間がかかるため、それに対しなんとなくで打ち立てたスケジュールに遅れが生じていることで焦っていたのだと思います。

研究実装自体はデバッグすることが多く、結構な時間数字の羅列を目grepしていました。この集中力がどこから出てきたのかは不明です。ところが長い期間かけて苦労して実装したものが上手く性能が出せず、仮に上手くいったとしてのシミュレーションをしても目標性能に到底及ばないことが判明し、これまでの苦労が水の泡と化す事態になりました。
苦労して実装したものが上手くいかないこと自体は誰しもあることですが、ちょうどこの頃仕事の方でも大変な事態になったこともあり、精神的に全く余裕のない期間となりました。ただでさえ短かった睡眠時間がゼロに等しくなることもありました。
急遽指導教員ともミーティングを行い、どのように「転進」するかということを話し合い、自分のメンタル状態でもできることからまた積み上げていく方針を取りました。このミーティングのおかげで失踪することなく持ち直すことが出来たと断言できます。

そこからなんとか持ち直し研究成果をまとめ上げたところでジャーナルに投稿フェーズとなりました。ジャーナル投稿にまつわるいろは(探し方やカバーレターなど)は、先に経験していた研究室の後輩から教えていただきました。とても詳しく教えてくださり本当に感謝しています。
ジャーナル投稿ではそもそも査読に回らないEditor's rejectがあるため、執筆時点でも精神的なハードルを感じつつ恐る恐る動いておりました。そしてそのEditor's rejectを受けてしまいました。
ですが、前述の水の泡案件に比べると精神的なダメージはあまりなく、無の状態で次の投稿先を探していました。
なんとか投稿先を見つけ出し、論文を修正した上で再投稿したところでD1の目ぼしいところは終わります。


見直したらものすごく地味な1年間ではありませんか....

 

D2

基本的な生活スタイルはほぼ変わっていないのでその辺は割愛。

 

先ほどのジャーナルからMajor Revisionの通知が来たのはGWの直前でした。少なくともEditor's rejectがなかったことに喜んだ記憶はあります。ですが蓋を開けてみると、ご指摘の量が結構な量で、対応しきれるかどうか正直不安でした。幸いなことにGW期間があったため、この期間は半日を除いてずっとこの対応をしてました。ご時世の規制が緩和されたこともあり、残りの半日は仲良くしていただいている友人とイベントでビールを飲みに行きました。ビールって美味しい。
そんなこんなで対応を完了させ、7月にはMinor Revisionの通知が来ました。ここまで来ればあと一押しだと慎重に事を運び再投稿しました。
acceptの通知が来たのは、友人の結婚式のために前泊していた時のことでした。友人と同室だったのですが、社会人博士をやっていることは誰にも言っておらず水面下のことでしたのでこの喜びを表に出す事はありませんでした。ですが代わりに妙にテンションが高かったと思います。ビュッフェ美味しかったし。宿泊部屋で行われた友人代表スピーチのリハーサルが面白すぎたし。

 

この時点でacceptをいただけたため、ここでふと妙な事を思いつきます。

「もしかして頑張れば今年度で修了出来る?出来たら色々と面白い?...うん、面白い!」

実のところジャーナルとは別で国際会議に向けた研究は裏で行なっており、これで上手く事が運べば可能なはずである。
この旨を指導教員に相談したところ「本当にやろうと思うなら今週中までなら学位論文のための手筈を取ることが出来る」とのことで、事務的には滑り込みセーフで可能とのことでした。

 

さて、自らの首を絞める回 〜第2期〜の開幕です。

 

そうと決まった途端にやることが急増しました。当然です。国際会議のための諸々に加えて予備審査のための書類準備や学位論文の概要作成などを仕事と並行しなければならないのです。
D1で散々大変な目に遭っているのだから、これくらい乗り越えられるはずだ!!!と、ノリと勢いを出していたのですが、案の定体を壊します。ただ前回のような酷いことにはならず、ちょうど土日安静で快復しました。全く学習していないようである、この人。
後でも触れますが、こんな中でも無事に国際会議論文を投稿し、予備審査のための準備も着々と進められたのはスケジューリング管理をちゃんと行なっていたからだと思います。あとは今は存在しない謎の体力。たぶん寿命を幾年か前借りしている。

 

時は進むこと予備審査。ある意味博士課程の中で最も重要である(と思っている)ため、生きるか死ぬかという考えがずっと頭の中を巡っていて、審査の部屋のセッティングをしている間緊張しっぱなしでした。指導教員が早めに来てくれて、私の雑談に付き合ってくれたおかげで少し気が楽になった記憶はあります。
ただいざ発表が始まると緊張は消えており、スクリプトを全く見ることなく主査・副査の先生方の顔、時折スライドの図を順々に見ながら50分程度喋れていました。
質疑応答ですが、終始穏やかに...なんてことはなく、少し波乱が起きました。質問に対する自分の応答能力が低かったことが最大の原因だと思います。思ったよりも質疑応答の時間が伸びました。発表中にはなかった緊張が輪廻の果てより舞い戻ってきた瞬間でもありました。最終的にはいただいたコメントをきちんと学位論文に反映させ、誤解のないようにスライド修正を行うということで、無事に合格をいただけました。質疑応答が終わってから審査のために部屋の外で待機する時間、恐ろしく長い。怖い。

こうなれば後は気合いで走り切れるはずだ!!(n回目)ということで、年明けに迎える本審査、ひいては学位論文の完成に向けて疾走感800%程度で臨みます。その最中で投稿していた国際会議論文のacceptの通知をいただきました。
学位論文作成、国際会議論文のcamera-ready版(実際に出版される論文)作成、本審査向けスライド修正、書類作成などまたしてもやることが急増しましたが、さすがに学習しました。体を壊さないように行動時間を制限することにしました。
制限したことによって得られた時間は友人たちとオンラインでわいわい通話しながらゲームしたりすることに多く割けました。結構至福のひと時でした。

 

年は明けること2023年、いよいよ本審査です。
といっても予備審査と大きくやる事は変わらないため、粛々と修正点などを交えつつプレゼンして質疑応答を行いました。Final defenceとはよく言ったもので、特に質疑応答では本当に防御している気持ちになってました。
ひと通りの事を終え、審査のために再度部屋から出て行きます。予備審査の時よりも長くとても緊張していました。長く感じていただけかもしれません。結果、無事に合格をいただけました。近くにあった椅子にへたり込んでました。指導教員は「かなりいい形で審査が出来た」と言ってくださいました。というのも本審査に向けて予備スライドをやや過剰なほど作っていて、その中で「これは細かすぎてさすがにいらないでしょう...」と思っていたスライドがまさかの質疑応答で大活躍していました。いくつかニッチな質問が来た時にも大半はその予備スライドたちを出しつつ返答出来ていました。あの時の私、大変よくやってくれた

本審査は終えられたものの、まだ学位論文の最終版と国際会議への発表が残っているため全然気は緩みません。急いで学位論文の修正を行い、国際会議のためのスライドを作成していました。
国際会議での発表に関しては、当日指導教員が予定の都合上来られず自分一人で臨むことになったのですが、なんだかんだまたしてもノリと勢いで乗り切った気がします。ひどいブロークンイングリッシュを喋りながらなんとかした感じです。少なくとも何も言えずに固まるといった事態にならなかったことだけは及第点かと思ってます。思い込むことにします。させてください。

そんなこんなで在学の最後までやること目白押しな、全く映えないのに非常に濃すぎる2年間を過ごし、無事に授与式にて学位をいただくことが出来ました。

 

D3

というわけでありません。


総括

指導教員からは、「博士課程にストレートで進学しても博士が取れる・取れないには一定の割合がある。そのような中で社会人博士をやりながら学位を取れたのはよくやったと思う」とのコメントをいただきました。あの時に私が学位を取れると確信し快諾してくださったことには感謝です。

上記の駄文を書きながら自分が上手く事を運べた要因を考察していましたが、「スケジュール管理をきちんと行なっていた」ことだと思います。特にジャーナルはボトルネックになる案件なので、そこから逆算して「この期間までにこれが出来ていることが望ましい」と節目を打っておき、ミーティングの度にそのスケジュール感で問題が出てないか、などを綿密に話し合っていました。またEditor's rejectや長期間に及ぶ査読期間というものは往々にしてあることだったため、「もしEditor's rejectになってしまった場合の次の投稿先を見繕っておく」「この期間になってもrejectが続く場合には別のネタでの検討を開始する」「査読期間に入ったら並行して別の研究ネタを仕込んでおく」など、特にジャーナルに関してはあらゆる場合を想定した計画を貼り出していました。

そして、一つ確実に言える事は「無茶なことをしてはいけない」です。最後の最後あたりでようやく学習しましたが、無茶をすると体を壊します。下手をするとメンタルも壊します。正直ずっと仕事も並行しているため現在進行形でなかなかにボロボロです。
在学中に何名か社会人博士の方を知ることになったのですが、その方々は最初から3年以上計画で事を進めていました。仕事との両立を考え、心身への負荷を考えたら妥当なご判断だと思っております。

今回のPh.D. Studentとしての活動により社会人博士は実際とても大変であることをこの身を以て体感いたしましたが、成し遂げられた事嬉しく思います。

体力が切れた。
兎にも角にも、まずは体力を回復させたい。メンタルも回復させたい。

 

Ice Lakeプロセッサは整数除算がアツい 数値計算編

下記の前回の記事でIce Lakeプロセッサは整数除算命令が強化されていることが実験を通じてわかった.

 

lcstmarck.hatenablog.com

 

ただこの記事では単にidiv命令をただ実行しまくっただけなので,特に意味がない処理をしている.そのため,もう少しだけそれらしい処理をさせて整数除算が強化されているかどうかをもう少しだけ見ていこうと思う.

今回は多倍長整数除算の処理をさせていく.といっても,除数と被除数が共に任意精度の時の除算処理は実装が非常に大変であるため,除数に関しては1ワードのみとし「(多倍長整数) / (1ワード整数)」の計算の処理とした.

 

実装

以下が簡易的多倍長整数除算の実装である.

(追記:aやbなどはuint32_tで十分というご指摘をいただきました.ありがとうございます.)

 

void divide(uint32_t *a, uint32_t b, uint64_t len, uint32_t *q, uint32_t r){

    int i;
    uint64_t tmp;
    for(i=len-1; i>=0; i--){

        tmp = (a[i+1] << 32) | a[i];
        q[i] = tmp / b;
        a[i] = tmp % b;
    }

    r = a[0];
}

 

除算は複雑であるがゆえに,「2ワード / 1ワード」というシンプルな除算ですら実装が難しい.したがって簡単のため,「128ビット / 64ビット」ではなく「64ビット / 32ビット」の計算に出来るようにするため,uint64_t変数tmpにuint32_t変数を2つ詰めて計算をすることにした.そのため除算の前にシフト演算等を行なっている.

本実験の主眼はプロセッサの除算命令の演算能力を見ることなので,被除数の配列が壊れてしまうなどの問題点こそあるが,正しく商と剰余が計算できていたのでこれで良しとした.

また以下が実装した除算関数のobjdumpの出力である.下線部のように符号なし除算命令であるdiv命令が実行されることが確認できた.

 

00000000000009f0 <divide>:
    for(i=len-1; i>=0; i--){
 9f0:   83 ea 01                sub    $0x1,%edx
 9f3:   78 2e                   js     a23 <divide+0x33>
 9f5:   4c 63 ca                movslq %edx,%r9
 9f8:   0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
 9ff:   00
        tmp = (a[i+1] << 32) | a[i];
 a00:   4a 8b 44 cf 08          mov    0x8(%rdi,%r9,8),%rax
 a05:   31 d2                   xor    %edx,%edx
 a07:   48 c1 e0 20             shl    $0x20,%rax
 a0b:   4a 0b 04 cf             or     (%rdi,%r9,8),%rax
 a0f:   48 f7 f6                div    %rsi
        q[i] = tmp / b;
 a12:   4a 89 04 c9             mov    %rax,(%rcx,%r9,8)
        a[i] = tmp % b;
 a16:   4a 89 14 cf             mov    %rdx,(%rdi,%r9,8)
 a1a:   49 83 e9 01             sub    $0x1,%r9
    for(i=alen-1; i>=0; i--){
 a1e:   45 85 c9                test   %r9d,%r9d
 a21:   79 dd                   jns    a00 <divide+0x10>
    }

    r = a[0];
 a23:   48 8b 07                mov    (%rdi),%rax
 a26:   49 89 00                mov    %rax,(%r8)
}
 a29:   c3                      retq
 a2a:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)

 

実験

今回実験に使用したプロセッサは以下の3つである.

  • Intel(R) Core(TM) i7-8559U CPU @ 2.70GHz (Coffee Lake)
  • Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz (Skylake-X)
  • Intel(R) Core(TM) i3-8121U CPU @ 2.20GHz (Cannon Lake)

 

また被除数のワード数を4096ワードとし,これを3000回実行した.この除算関数を3000回実行した実行時間を取って比較することとした.

 

実験結果

"Time: ~~ [ms]"が除算関数の総実行時間である.

  • Coffee Lake @ 2.70GHz

$ time ./a.out

Time: 114.418000 [ms]


real 0m0.122s

user 0m0.115s

sys 0m0.003s 

 

  • Skylake@ 3.60GHz

$ time ./a.out

Time: 99.025000 [ms]


real 0m0.102s

user 0m0.100s

sys 0m0.000s

 

  • Cannon Lake(実質Ice Lake)@ 2.20GHz

$ time ./a.out

Time: 89.798000 [ms]


real 0m0.094s

user 0m0.093s

sys 0m0.000s

 

動作周波数の観点でいうと「Cannon Lake < Coffee Lake < Skylake」であるが,実行時間の性能の観点では「Coffee Lake < Skylake < Cannon Lake」となった.

したがって除算命令の高速化により,条件付き多倍長整数除算の高速化が見込めることがわかった.

Ice Lakeプロセッサは除算がアツい.

Intel Ice Lakeのプロセッサは整数除算命令がアツい

特に理由はないのですが,intelのIce Lakeのプロセッサに対して謎の高揚感等を感じている.

Ice Lakeというコードネームのプロセッサの代表的な特色として,AI推論命令セットとなるIntel Deep Learning Boostであったり,グラフィック機能も持った10nm製造プロセスなどなど,満載感があふれている.

 

しかしこのアーキテクチャにはあまり表沙汰になっていない進化もしており,なんとinteger dividerのレイテンシも低減させているという.

除算命令,もといdiv命令系はもともとレイテンシが大きく,四則演算の中でもadd, sub, mulと比較しても処理が重い命令として有名である.そんな除算命令のレイテンシが抑えられたというのであれば,これは進化といえるであろうと思う.

ということで,今回はこのdividerに着目し,実際に動かしてみてこの目で確かめてみようではないかというのが記事の目的である.

今回の評価では,除算命令が高速化されていそうである,というのが分かる程度の計測を行う.厳密なレイテンシの計測などのレベルになるととても難しい上にしんどいので...

 

雑に実装

というわけで,符号付きの除算命令であるidiv命令について簡単に計測しようと思う.

そのために,以下のようなidiv命令をひたすら実行しまくるような素晴らしく単純なインラインアセンブリを記述した.

 

        __asm__ volatile(
            "mov $156707, %rax;"
            "mov $9999883, %rcx;"
            "mov $-1, %r10"
        );

        for(i=0; i<N; i++){
            __asm__ volatile(
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                "mov %%r10, %%rdx;"
                "idiv %%rcx;"
                ::: "rax", "rdx", "rcx", "r10"
            );
        }

 

被除数である rdx:rax のrdxには-1,raxには適当な素数を入れておき,除数であるrcxにも適当な素数を入れておいた.

ループ内でアンローリングしているような書き方をしているのは,一回idivをやるたびにcmpとjmpをするのもなあという適当な勘によるもの.

また,idivを実行するたびにrdxに-1をいちいち入れているのは,idiv命令を実行したあとのrdxレジスタには計算結果の剰余が入り,そのまま被除数の上半分として引き継いで次のidiv命令を実行すると,場合によってはfloating point exceptionが発生して落ちるからである.要するに,「念の為」である.

 

実験

今回の実験では,Nは1000万とした.つまり,idiv命令は1億回実行されることになるはずである.

またコンパイルオプションには-O3を指定し,for文のカウンタもレジスタのみで済ませていただくようにした.

 

その前に

今回のタイトルでは,Ice Lakeプロセッサと言っているが,そんなものが手元にあるのかと言われると執筆現在においては所持していない.

ではこの実験が出来ないのか,と言われると実はそうではない.

Intelが出しているプロセッサの1つに,Cannon Lakeプロセッサという10nm製造プロセスのプロセッサが,実はしれっと存在している.このプロセッサはIce Lakeの前身的なものであり,個人的にはIce Lakeの試作品のものと思っている.

現にCannon Lakeに分類するプロセッサは1つしか出荷されていない.

しかし,試作品のようなものであれば,Ice Lakeと似たアーキテクチャをしているのではないかということで,今回の実験に至った.

 

使用プロセッサ

使用したプロセッサは以下の2つである.

  • Intel(R) Core(TM) i7-7820X CPU @ 3.60GHz (Skylake-X)
  • Intel(R) Core(TM) i3-8121U CPU @ 2.20GHz (Cannon Lake)

 

要するにdividerの進化前と進化後を比べてみようというもの.

見ての通りそれぞれ動作周波数が異なるため,単純に実行時間で比較するのはさすがにと思ったため,今回はTime Stamp Counter(TSC)を使用し,idivしまくる部分をrdtscp命令を使って実質クロック数の観点で比較した.

 

実験結果

  • Skylake

$ ./a.out
diff = 4915734904 

  • 実質Ice Lake(Cannon Lake)

$ ./a.out
diff = 1067339400 

ざっくり5分の1程度のクロック数でidiv命令が処理された.

さらにこの実験してて明確に実行時間に違いを感じたので,timeにかけて再度実行してみた結果が以下である.

  • Skylake

$ time ./a.out

diff = 4923881440
real 0m1.369s

user 0m1.368s

sys 0m0.000s

  • 実質Ice Lake(Cannon Lake)

$ time ./eval

diff = 1067358772
real 0m0.487s

user 0m0.483s

sys 0m0.004s

 

実行時間の観点では,Ice Lake(Cannon Lake)がSkylakeに対しておよそ3分の1程度の実行時間で整数除算を処理した.

つまり,

「Ice Lakeプロセッサに進化したことによって整数除算のレイテンシが軽減され,ある程度低周波でも高周波数の進化前プロセッサよりも高速に除算を処理することができる」

ということがわかった.

 

このゆるふわ実験から,整数除算命令が高速化されていることが確認された.相当integer dividerを改良したんだなあ.

英文校正から学ぶ論文に使える英語,使う英語2

先日,以下のような同タイトルでの英語に関する記事を書かせていただきました.

lcstmarck.hatenablog.com

 

当時2,3人見てくれれば御の字と思って書いたのですが,想像以上に見られていただけでなく,何人かからありがたいお言葉をいただいたりしたので調子乗ってその2書きます.

 

 

相変わらず重箱の隅をつついて行きます.

細かい話なので「そんな細かいところ,気にする必要があるのか?」という疑問が浮かんでくるかもしれませんが,個人的には「論文を書く」という観点では気にする必要があると考えています.

例えば日常英会話やTwitter,チャットなどに関してはある程度のブロークンイングリッシュでも,失礼なことを言わなければ,相手に意図が伝わればなんとかなると思います.

しかし論文を書くことに関しては,公的な文書の感じでプロシーディングやネット上にそのまま残ります.

そして最も重要なのは,論文はacceptを受けなければ何も始まりません.残りません.

そのため査読者に対して稚拙な文章を送ってしまわないためにも,よりそれらしい英語にしてacceptしてもらえるような文章にするべきだと思います.

したがって,たまには重箱の隅をつついてでもよりよい文章作りに励むことは大事だと考えています.なお,自分が良い文章を書けるとは言ってない...というか書けないので一単語をいちいち調べたりしている...

 

今回も単語の意味の引用元に関してはLongman英英辞典(https://www.ldoceonline.com/)に大変お世話になった.

 

at the same time → simultaneously
at once → simultaneously

「同時に」「一度に」という意味で記述していたが,simultaneouslyと校正されていた.

simultaneous

things that are simultaneous happen at exactly the same time

辞書によってはsimultaneouslyに対して"at the same time"という意味が記述されているものあるため,意味自体に差異は見られないと思われる.ただ論文という観点では少々語彙レベルを上げた表現に,という意味で校正されたのではないかと考えている.

simultaneouslyについては,日常英会話に関しては基本的には使われず,むしろat the same timeを使う方が好まれる.

at once

a) immediately or without delay

b) together, at the same time

at onceに関してはもちろん今回の文脈ではb)の方であるが,語彙レベルの観点だけでなく,場合によってはa)の意味に誤解される恐れがあるため,simultaneouslyを使った方が無難かもしれない.

また余談だが,日常英会話の場合,a)のようにimmediatelyのニュアンスを伝えたかったら,right awayもしくはstraight sway(主にイギリス英語.straight offもアリ)を用いるようである.

straight away

(also straight off) British English spoken  immediately or without delay

 

 

avoid → circumvent 

これは「不要な処理を避ける」というような文脈で記述していた.

circumvent

 to avoid a problem or rule that restricts you, especially in a clever or dishonest way

こういう一概に良い意味と言えるか微妙な意味であったり,そのあとに記述されていた例文が,

The company opened an account abroad, in order to circumvent the tax laws. 

 であったりするが,「(うまいことやって)不要な処理を減らす,避ける」というような文脈には沿っていて,語彙レベルとしても上げてくれる校正であったと思う.

よって,この単語は単純になんでもavoidの代用として使える単語という訳ではないため使用には注意が必要ではあるものの,表現の幅が広がる一語ではなかろうか.

 

 

wrong → erroneous

「間違った」という意味で記述して校正いただいた単語.

erroneous

erroneous ideas or information are wrong and based on facts that are not correct

 日本語でいうとどちらも「間違っている」というニュアンスであるため,これらは可換であるかと言われると,そういうことではない.参考文献に記述されていた以下の例文の比較がとてもわかりやすかった.

I review the erroneous article.

I review the wrong article. 

前者は「間違いの含まれている記事のレビューをした」という意味.

後者は「そもそも全く関係ない違う記事のレビューをした」という意味になる.

同じ「間違った」という文,単語でもニュアンスには確かに違いがあるようなので,この例文を参考に考えるとよさそうである.

 

 

 

before → prior to

基本単語.「〜の前に」の意味で使用していたところ校正いただいた.

prior to

formal before 

辞典で調べても素晴らしくシンプルにbeforeと書かれている.強いて言えばformalと書かれているため論文のような堅めの文章で用いると良いのではなかろうかと思う.

では堅さ以外に違いは全くないのかと言われると,厳密にはそのようなことはないようである.

参考文献によると,文法レベルにはbeforeは後ろにSVと文が来ることが可能だが,prior toは取ることができない.名詞のみが後ろに来る場合は可換である.

もうひとつ違いがある.beforeの単語の意味には以下のような少し別の意味がある.

before 2

used to say that something happens where it can be watched by people

いわゆるin front ofの意味合いである.prior toには空間的な「前」は暗黙的に含まれていないため,そのような意味で使用することはできない.

ただ,空間的な「前」の意味でbeforeを使うこと自体あまり一般的でないため,特別気にすることではない.ここまで来ると完全に重箱の隅つつき状態になっている.

 

 

gives → yield

"X gives correct results"と書いていたところyieldに校正していただいた.単純に自分の語彙力が足りなくてちょうどいい単語が浮かばなかったため,直していただいて非常に助かった例の1つ.

yield

to produce a result, answer, or piece of information

意味の中にも記述されているくらいにはresultとの相性は良いようである.(確かに「結果をもたらす」というなあと...)

しかしながら論文ではこのyieldを用いると良いようだが,日常英会話では結果や利益(result, profit)をもたらすと言いたい時にはproduceを使うようである.

 

 

basic concept → essence

単純な語彙力不足案件.「基本的なコンセプト」というつもりでそのまま書き起こしたらessenceという「それだ!!」という校正をしていただいた.

essence

the most basic and important quality of something

余談で,essenceという単語で辞書引いたら以下の表現があることを知った.

something is of the essence

used to say that something is very important

ex)

Speed is of the essence when following up newspaper advertisements.

すごく大事であるという時に用いることができる表現のようである.初めて知った.

 

 

 show → describe

日本語で言う所の「示す」という意味で使用したが,describeに校正していただいた.

show

2) to provide facts or information that make it clear that something is true, that something exists, or that something has happened 

describe

to say what something or someone is like by giving details about them

この意味を調べて知ったが,showの言う「示す」の一つにはproveに値する単語であるようである.

今回校正していただいた文脈は,「この論文から〜という結果であることが示されている」 という旨の記述をしていた.

「示す」="show"と当時は短絡思考で記述していたが,確かにproveしている訳ではなく,こうであった,という事実を述べる意味合いで書きたかったのでdescribeに校正していただいてよかったと思う.

showは上記の2の意味の他にも「見せる」「(見せて)示す」などの,「見る(see)」に関する意味が中心で表記されていた.そしてdescribeを英和辞典で調べてみると「言葉で述べる」や「記述する」など書かれており,"to say"と書かれているだけあって「見る」とはまた違ったニュアンスの意味であるようである.

そのため,特別何かを証明している訳ではないため「この論文は〜であると示している」という解釈をするよりかは,「この論文には〜であることが記述されている」と解釈して記述した方が,より正確性が増すと考えた.

 

余談として,ではproveとshowに違いはあるのかと思って調べると,Mathematicsの世界ではshowとproveには特に違いを意識していないようであるが,Scienceの世界となるとproveは使われないようである.以下の意味を見るとニュアンス的にそうかもしれないと感じた.

prove

to show that something is true by providing facts, information etc

また記述によっては「proveするためにshowする」という旨のことも書かれていた.showの意味を改めて見ると確かに「証明するために事実や情報を出す」というように書かれている.

 

 

 

 

英文校正で受けた指摘をただ鵜呑みにするだけでなく,このように少しでも噛み砕いて見てみようとするとこれはこれで新しい知見が得られたりしてとても楽しい.その3かけたら良いなあ.

Ubuntu18.04でパスワード設定を間違えてログインできない時

 

ことの発端

 

 

要は,情弱すぎて非常に情けない話である.

しかし"single user mode"という単語をただ知っているだけで,それを実際に見たことも使ったこともなかったため,これは実際に試すいい機会ということで修復を試みる実験を行った.

 

タイトルの通り,ディストリビューションはUbuntu18.04と書いているが,その他でも普通にできるかと.

 

実験の準備

まずはテストユーザー(test)を作成する.そしてこの時のパスワードは,とてもとてもめちゃくちゃにタイピングしたものをコピペして作成した,非常にランダム性が高くて長いパスワードとし,そのままコピペメモを消去した.この行動に深い意味はない.

 

f:id:lcstmarck:20190820210616j:plain

 

そして案の定なことが発生します.全然入れる気がしません.

 

ここから復興のために動き始めます.

rescue.target と emergency.target について,以下の参考文献が非常にわかりやすかった.

www.linuxtechi.com

 

rescue.targetとemergency.targetとの違いは,環境の規模の違いのようである.

rescue.targetの場合は,できるだけローカルファイルシステムをマウントしてネットワーク含むいくつかの重要なサービスを起動しようとしてくれる.(try toと書かれている)

emergency.targetread onlyrootファイルシステムのみをマウントし,ネットワーク等のサービスは起動しない.まさにemergencyな感じ.

そのためemergency.targetでログインする際には,以下のコマンドでread-writeにすることもあるそう.

# mount -o remount.rw /

 

実際に救い出してみる

というわけで,この参考文献に則って,single user mode(rescue.target)でログインしてみる.

GRUBの選択画面で"Ubuntu"を選択中に"e"を押すと,ブートの設定ができるエディタ編集画面が出てくる.ここで/boot/grub/grub.cfgの該当部分の設定を一時的に変えることができる.

下部にあるlinuxの行の末尾にある"$vt_handoff"を消去し,以下を追記する.

systemd.unit=rescue.target 

 記入が終わったらCtrl-xしてブートさせる.

すると,Enterを押したあとrootでログインした状態になった.

そのままtestユーザーのパスワードを変更する.

# pwconv

# passwd test

今度はしっかりとゆっくりと確実に着実に1文字1文字丁寧にタイピングしてパスワードを再設定.そしてrebootへ.

 

f:id:lcstmarck:20190820212839j:plain

 

無事に再設定したパスワードを使用してtestユーザーログイン成功です.

インストールしたばかりだし再インストールすれば良いかと思っていたけれど,きちんとsingle user mode使った方がよっぽど手間が少なかった.反省してます.

 

 

どうでもいい寄り道

ネットワーク

rescue.targetでログインしてすぐにip aを打ってみるとIPアドレスが割り振られていなかったため,どうやらnetwork-managerが起動してなかったようである.当然pingも通らない.

というわけで,ものは試しでこれを起動させてみる.

# systemctl start network-manager 

IPアドレスが割り振られ,pingをしてみると無事に通ったのでrescue.targetでログインしてもネットワークを使用すること自体は可能なようである.

となれば,ネットワークが繋がるならばsshも可能ではなかろうかということで,

# systemctl start sshd 

 したら,sshログインも成功した.single user modeなので,当然rootでしかログインできない.

ユーザーでsshログインしようとすると,

"System is booting up. See pam_nologin(8)"

Connection closed by 192.168.1.120 port 22

 と突っぱねられる.

 

emergency.target

rescue.targetでログインしたならばemergency.targetもやってみようではないか.

やり方は先ほどのGRUBの設定でrescue.targeと同様以下を追記するだけである.

systemd.unit=emergency.target 

起動すると,rescue.targetの場合と大差ない感覚であったが,network-managerは当然立ち上がってなかったので立ち上げようとしてみたところ,Ubuntu起動画面に切り替わって一切の応答がなくなった.

参考文献には,

it does not enable any network or other services.

 

と書かれているので,自明ではあるけれど...面白くなってついやってみたかったの...

 

 

 

今回の知見としてはパスワード二回同じtypoしてもなんとかできるし,single user modeは簡単にできる上に便利であるとわかった.

英文校正から学ぶ論文に使える英語,使う英語

完全にテクニカルではなく,ややアカデミックに近しい話.

とはいえ論文に限らず,通常の書き言葉にも使えそうな気がする話.

英語論文を書いて,英文校正に出したらひどく赤になって返ってくる.

何度か経験しているが,それでも赤の量は多い.

自分の英語力不足が原因なのは明らかだが,校正された箇所をおいそれと修正して「はいおしまい」としてしまうのはよろしくなくて,せっかくそれなりのお金をかけているのだから,やはり今後の自分のために生かすべきだと考えた.

なので,今回は自分が受けた校正の中から,完全なる独断と偏見で気になったものをピックアップしていこうと思う.

いわゆる重箱の隅をつつく回である.

 

なお, このあとで記述する単語の意味の引用元はLongman英英辞典( https://www.ldoceonline.com/ )である.大変参考にさせていただいた.

 

 

 

A which has X → A containing X

何かと単語を修飾したいときに,ついwhichを使ってしまう癖がある.

しかしこの例のように,現在分詞を用いて名詞を修飾することでwhichの乱用を抑えようというもの.

contain

if a substance contains something, that thing is part of it

 余談だが,英英辞典によると日常英語の場合ではcontainはしばしばhaveやthere beに置き換えられるようである.

 

 

some previous research → extant alternatives

alternative (Noun)

something you can choose to do or use instead of something else

「関連研究」と言いたい時に使える表現.previous researchやrelated worksなどを用いていたが,これも言い回しの一つとしてalternativesが使えるようである.

しかし,extantに関しては意味が以下の通りであるため,使う場面には気をつけたほうが良さそうである.

extant

still existing in spite of being very old 

 

 

as well as A, B, and C → along with A, B, and C

「同様に」という文脈で書いたものだが,along withも使えると学んだ.

"as well as"という調べ方もいささか微妙なところであるが,"as well"自体が"too"のような意味合いなので,今回よしとした.

また辞書によってはalong withも"in addition to"の記述があるので,大きな違いはないと思う.別の言い回しの引き出しの一つとして使えるかと.

along with somebody/something

together with someone or something else

as well as somebody/something

 in addition to someone or something else

 

 

A allows us to do → A allows (doの名詞形)
A enables us to do → A enables (doの名詞形)

具体的には,"These instructions enable us to execute ..." → "These instructions enable execution of ..."となるように校正をしていただいた.

こうして見ると,この手の動詞を使うたびに"us to"が毎度出てくるのは少々冗長である印象は確かに受けたため,この校正から知見が得られた.

 

 

have the advantages → offer the advantages
have shorter execution time → offer shorter execution time

「優位性を持つ」や「より短い実行時間(のデータ)を持つ」というつもりでhaveを使っていたが,この非常に汎用性の高いhaveの乱用を防ぐための言い回しとして校正していただいた.

offerも少し便利な単語のようで,

offer (Verb)

to provide something that people need or want

のという意味がofferにはある.

そのため,今回のような比較的ポジティブな目的語を取る,かつhaveを使いそうになったらofferも想起できればと思う.

 

 

than A and B → over A and B

これに関しては完全に文法レベルの問題.ただのやらかしである.なぜならば,

than

used when comparing two things, people, situations etc

 と,"two"と明示的に記述されているからである.

AやBよりも〜である,と書きたかったら,overを検討するという知見.比較だからといってむやみにthanを使うとこのようなミスをするという知見.

 

 

than → compared to

むやみにthanを使うとミスする知見の一つ.

このthanがなぜ校正されたのかを考え調べた結果,「AとBを比べた時,具体的にどの程度差があるのか」という文脈になる時にはthanではなくcompared toを使ったほうが良いという結論に至った.

例えば「AはBよりも"1つ"少ない」のように具体的に差が分かる材料が混ざっている時にはcompared toに校正されているようであった.

実際にthanを使用した辞書例文を漁ったが,先述の「AはBよりも1つ少ない」のような文脈でthanを使っている文が見当たらなかった.自分の目が節穴説.

もしかしたらこのような場合でもthanを使用してはいけないルールはないのかもしれないし使用例があるかもしれないが,compared toを使用したほうが無難そうであると学んだ.

 

 

in order to → to

ことごとく校正された節.

"in order to"は「目的」であることを明確に表現でき,かつ書き言葉であるため,何度か文中に使用したが全て"to"に校正された.

辞書とは別で,参考文献を漁ってみたが,"in order to"と"to"との間には意味的な違いはないようである.そして否定文の時には,in order toの方が好まれる(in order not to)ようである.

ただ論文という観点では,in order toは少々冗長な表現なのかもしれない.

 

 

it would be → it is reasonable to assume

直にこのように校正していただいた訳ではないが,意味的にこのようになる.

文脈は「〜を考慮すると,〜であると考えるのが妥当である」といった推論である.

日本語のレポートや論文ではよく見られる「〜であると考えられる」「〜と思われる」というような表現は英語論文ではあまり使われない.つまり日本語でいうところの「〜と思われる」のような推論の文脈でthinkなどは使われない(見た記憶がない,が正しい).

"think"を辞書で参照すると,2に"imagine something"とあるため推測の意味が全くないわけではないが,自分が観測した限りでは英語論文という観点ではあまり使われる単語ではないようである.

think

1. to have a particular opinion or to believe that something is true

2. to use your mind to decide about something, form an opinion, imagine something etc

3. to have words or ideas in your mind without telling them to anyone

4. to remember something

5. to consider that someone or something is a particular thing or has a particular quality

そのため個人的に「〜と考えられる」となるような文にしないようにしているが,どうしても推論の文脈になる場合には,上手い言い回しが浮かばないためそれらしいwouldを使って書いてしまう.

しかし今回の校正で,言い回しの一つとして"reasonable"を用いた表現に直していただけたため,なるほどそういう書き方があるのかと個人的に感動したためここに書いた.

reasonable

fair and sensible

 

 

 

 

こうして振り返ると,各項目やそれに関連する項目についての下調べ,surveyのために英英辞典や英文サイト等などを漁っている時間が圧倒的に長かった.

重箱の隅の重箱の隅の重箱の隅の.....状態.

それほどには自分は英語について全くわかっていないし,英語が全然使えていないことが浮き彫りになっていることがよくわかった.

同時にすごく書いてて面白かったので,自己満的に近いうちにまたその2とかを書こうかなとも思う.

 

PowerPCのアライメントについて

前記事でPowerPCにおける条件分岐について簡単な実験を行ったが,もう一点つい気になってしまったことがある.アライメントのことである.PowerPCであろうとx86であろうと,アライメントは揃えるのは当然な話である.

PowerPCRISCであり32-bitの場合4byteで固定されている.そのため「4byte」がキモなのかと思った.

実験としてはこれまた非常にシンプルで,4byteアライメントされているアクセスをひたすらするような関数と,アライメントされていないアクセスをひたすらするような関数の2つを用意して実行時間を計測した.

 

この実験を行うためのアセンブリプログラムは以下の通りである.行列の和を求めるシンプルな関数である.今回は1024x1024の行列の和を想定している.

add_matrix_aligned:
    li      0, 1024
    mulli   15, 0, 4
    mullw   16, 15, 0
    li      8, 0

add_outer_aligned:
    li      9, 0
    mtctr   0

add_inner_aligned:
    add     10, 3, 8
    add     11, 4, 8
    lwzx    13, 10, 9
    lwzx    14, 11, 9
    add     13, 13, 14
    add     12, 5, 8
    stwx    13, 12, 9
    addi    9, 9, 4
    bdnz+   add_inner_aligned

    add     8, 8, 15
    cmpw    7, 8, 16
    bne     7, add_outer_aligned
    blr

 

アライメントされていない場合の関数に関しては"li  9, 0"の部分を"li  9, 2"として常に4+2のアドレスにアクセスするようにした.

このプログラムを100回ループした時の実行時間は以下の通りになった.alignedがアライメントされている方で,badがされていない方である.

$ ./add_matrix

add_matrix_aligned : 4.759800 [s]

add_matrix_bad : 5.624340 [s]

一目でわかるレベルにアライメントされていない方が実行時間が遅くなっていることが確認できた.

 

 

よりみち

行列和のアセンブリプログラムを書きながら,もうちょっとコードの長さを短く出来ないかなあと思ってついそのまま作ってみた.1024x1024の行列の和を想定しているから出来るコードではあるが,実行時間に変化があるかなと気になった.以下の通りである.

add_matrix_comp:
    li      0, 1024
    mullw   0, 0, 0
    mtctr   0
    li      8, 0

comp_loop:
    lwzx    10, 3, 8
    lwzx    11, 4, 8
    add     10, 10, 11
    stwx    10, 5, 8
    addi    8, 8, 4
    bdnz+   comp_loop

    blr

 

命令数が19から11に減った.そしてそのまま実行してみた.add_matrix_compが上のコードである.

$ ./add_matrix

add_matrix_comp : 4.617402 [s]

add_matrix_aligned : 4.759102 [s]

add_matrix_bad : 5.638711 [s]

 

結局メモリ律速なプログラムではあるが,素直な実装よりも少しだけ速くなった.