はてなブックマーク

いままでpip実行するたびに、「これどこかのsetup.pyに一行でもid_rsaとかfirefoxのprofileデータをどこかにアップロードするコード混じってたら終わりだよな」と思ってたけど、 https://pytorch.org/blog/compromised-nightly-dependency/ いよいよそういうことが起こってきたので、なんとか対応したほうがいいという気持ちになった。今年中に使用感を悪化しない範囲でどこまでできるかを探りたいと思いますね。 ブラウザを別UIDで実行する firefoxのデータに自由にアクセスできたらMFAとか意味ないんだよなあ… ブラウザのデータを別プロセスから読みたいとか、ブラウザにパイプ繋げたりとかしたい場合はないので、別ユーザにして、isolationすべきという気がする。 firefoxだけ起動できる UID を作って、その UID で

なんか GTK の UI を作ろうかと思って、Valaで書くのがよさそうな気がしたのでValaというのを触ってみたが、なんか思ってたよりよかったな。 まあRustが打倒C++できそうな今の時代に、わざわざマイナーなValaを使ってもあんま良いことないと思うけど、まあ良かったと思う点を書いておく リファレンスカウンタと文字列があってコンパイルがはやい 個人的には、プログラミング言語の機能って、C99 に自明な場合だけでもいいのでうまくやってくれるリファレンスカウンタと、文字列のconcatが簡単にできるぐらいで十分だと思ってたのだけど、大体そのぐらいの機能になっててよかった。 リファレンスカウンタやunownedは、Rustの所有権と比べたら雰囲気ぐらいの機能しかなくて、安全でないパターンが書けてしまうのはたしかにそうなんだけど、実際プログラム書いてると所有権は雰囲気ぐらいでなんとかするふん

すいません。 これはswayに問題があったわけではなくて、うちのRADEONをつけるとマザボごと死ぬので諦めた次第であります。(電源ボタンもきかなくなる) 正直Ryzenってすぐ不安定環境にならないですか…私は電圧オフセット+0.250V 追加して運用してる。これやらないとLinuxだとsoft lockupして死ぬ。これはRADEONでなくてもなる。 https://w0.hatenablog.com/entry/20170621/1497988036 この頃は出ないと書いてあるな。なんかこのあとBIOSアプデトしたら死ぬようになって、それ以降マザボもRyzenもメモリも更新したけど安定したときない。 見てる不安定現象 Linux で soft lockup する → これは電圧盛れば解決する 再起動に失敗する → これは解決したことない 突然マザボごと死ぬ → これは手元のRADEON

pidfd_open pkill 打つたびに、「これpid再利用されたら地球が爆発するよな…」とか思っていたのだけど、今はpidfd_openがあるので助かった。 #define _GNU_SOURCE #include <sys/types.h> #include <sys/syscall.h> #include <unistd.h> #include <poll.h> #include <stdlib.h> #include <stdio.h> #include <sys/wait.h> #include <sys/stat.h> #include <fcntl.h> static int pidfd_send_signal(int pidfd, int sig, siginfo_t *info, unsigned int flags) { return syscall(__NR_pi

もう戻らないでいけるやろ。 Xorg はマルチディスプレイのときにディスプレイごとにスケール変えるのができなくて微妙なことをやってたがもう考えなくていい。 emacs を pgtk にしたので、Xwaylandも無くてもいける。Arch なら emacs-native-comp-git-enhanced 入れれば一発で gccemacs + pgtk にできる。 環境変数は、.pam_environmentで変えるのがやりたいことだと思うのでそうしている。(どこから何でログインしても環境変数統一したい。pamを通らないことはないやろ) xrandr のかわりは、sway の config に書く ctrl:swapcaps も sway の config に書く Firefox は何故かデフォルトXになるので、 MOZ_ENABLE_WAYLAND=1 する NVIDIA GPUは…諦めよ

さて、C言語を使い慣れた人には常識ですが、C言語初心者にとって少し難しいのが、変数の宣言です。 例えば、初心者にとって、関数ポインタの配列へのポインタを返す関数の宣言を書くのはあまり簡単ではありません。 C言語の初心者には、以下のようなコードを書くのは少し難しく、また、C言語にあまり慣れていない人は、typedefなどを使ってしまいがちです。 typedef int (*func_t)(int); typedef func_t func_arr_t[10]; extern func_arr_t *x[40]; int (*(*x[40])[10])(int); int (*(*func(int i))[10])(int) { return x[i]; } そのようなことでは、いつまでたってもC言語の初心者を脱出することはできません。この章では、変数の宣言について詳しく勉強することにしましょ

これまでのあらすじ : https://twitter.com/tanakmura/status/1280152564898557952 FPGAでHello World以上のものが書きたいという気持ちは前からあったので、この機会に少し実用的はHDLを書くことにした。 なにをやっているかの解説を書いておこう。 ソースは、 https://github.com/tanakamura/jisaku_pc_8088 ここにある(上のツイートでは、タイミング問題があってLED点灯しないことがあると書いてるが、これは多分改善してあるはず。) こういう昔のCPUは、CPU側の命令実行とバスが直結していて、ポインタ0x80 を読むと、CPUの足に、そのまま0x80が出てくる。それを正しくハンドリングして、有効な命令バイト列を返せば、8088を動かすことが可能だ。 この実装では、この足から出てくる信号をデ

https://preferred.jp/ja/news/pr20200623/ 特に書いてなかったけど、10月に転職したものの、ディ〜プラ〜ニングもよくわからんのでこれをやっていた。HW詳細は公開されてないのであまり面白い話題は書けないけど、嬉しいので記録しておく。 (twitterにしか書いてなかったけど)転職前は https://www.pezy.co.jp/news/news20171213/ これをやっていて似たようなことばっかやってますね… https://twitter.com/tanakmura/status/923517981610729473 PEZYの実装は今はどうなっているか知らないけど、大きく変わってなければ、今も僕が最後10%チューニングしたプログラムが残ってるはずで、ランク1位のプログラムとランク3位のプログラム両方僕の手が入ってる可能性がある。 https:

アーキテクチャと実装混ざってるけど 命令dispが32bit届く immも32bit入ることが多い メモリが順序守る(何回も書くが、メモリ順序が緩いことによって得られたCPU時間より失なった人間時間のほうが絶対多いから) ファームウェアがBIOSとUEFIの二種類しかない (ボードごとにカーネルにディレクトリ作るのやめろARM) 周辺デバイスがPCIに統一されててキャッシュの問題が起こりづらい(もうdma_alloc_coherentの挙動調べるの飽きた) キャッシュがソフト的に見れば一階層 (L2の挙動が定義されてないARMとかいう無名CPU) 除算とFPUが付いてる ABIがWin除けば32bitと64bitとx32の3種類しかない。 PCIe がキャッシュスヌープ付けてフルスピード近く出る lock cmpxchg が遅くない *fence が遅くない こういう問題で別のアーキがx8

(まだ断片的な情報しか出てないので、多くの推測を含んでいます) https://community.arm.com/groups/processors/blog/2016/08/22/technology-update-the-scalable-vector-extension-sve-for-the-armv8-a-architecture (上から参照されてる https://community.arm.com/servlet/JiveServlet/download/38-25150/ARMv8-A%20SVE%20technology%20Hot%20Chips%20v12.pdf が一番情報あるのでこっちを開きながら以下読むと良いです) ようやく資料が断片的に出てきたので書いておこうと思う。 一番の特徴は、命令セットはベクタ長を固定してないという点だろう。これのメリット、デメリッ

ファイルから読んだデータを、CPUで加工せずにソケットに送りたいとする。 read(in_fd, buffer, 4096); write(out_fd, buffer, 4096); とか、やりたくなるが、これは実際には非常に無駄で、read 時に、ファイルシステムキャッシュからユーザ空間へコピー、ユーザ空間からskbへコピーしている。 まあ1Gb Etherなら全然大したオーバーヘッドにはならないけど(それがなるんだよなぁ…(なんで？))、NVMe Flash から、100Gb イーサに送るとかすると、memcpy が一回増えるだけで無視できないオーバーヘッドになるので、無駄がある。 そこで sendfile というシステムコールがある。 上のread,writeは sendfile(out_fd, in_fd, NULL, 4096); とか書くと、カーネル内のページをなんかうまくや

キャッシュフラッシュに苦しんでいる人も世の中にはたくさんいる。 そういう人を救うために、Skylake からはclflushopt という命令が新設された。 これまでは、clflush という命令があって、これを使うとキャッシュフラッシュができた。clflushoptは、これよりはやい。どのぐらい違うかというと、手元(i7-6770 + DDR4 2ch) だと、 clflush 4.1[GB/s] clflushopt 43.6[GB/s] memset 30.2[GB/s] このぐらい違う。 #include <stdio.h> #include <x86intrin.h> #include <sys/time.h> #include <string.h> #include <time.h> double sec(void) { struct timespec ts; clock_ge

色々あって、Zynqを使うことになって、色々つらい思いをしている。 VivadoもQuartusもはっきり言ってひどいとしか言いようがない。HDLで書いたモジュールをTcl(!?!?今は21世紀だぞ??)でラップして作ったブロックをくっつけていくという設計は狂っているし、合成配置は遅すぎるというツール実装の問題もある…まあこのへんの話はまたそのうち。 最初は全くわからなかったけど、色々つらい思いをしたおかげで、大分理解してきたのではないかと思う。理解すればそんなに難しくない。もちろん、微妙にアナログの問題が出るとか、FPGA特有の難しさはある、が、まあそれは仕方無いだろうと思う。 以下、僕と同じように、ボトムアップに問題を理解していくのが好きな人向けに書いている。ちゃんとしたチュートリアルは http://www.zynqbook.com/download-tuts.html にあるので各

あけましておめでとうございます(投稿周期を考えるともう正月まで投稿しなさそうなのでフライング) 今年のテーマは「何故HadoopとかMapReduce系は簡単だという風潮があるのにGPGPUは難しいという風潮になるのか？」だった。 別にテーマだったと言っても何かやったわけではないけど… それで「GPGPUも簡単だと思う」みたいなことを書いてたら https://twitter.com/tanakmura/status/672681735990075393 なんか色々あって、今見たら「帰ったらちゃんと書きます」とかおととい書いてたのでちゃんと書こうと思った。 「GPGPUは難しい」と主張することのデメリット 〜Hadoop vs CUDA〜 MapReduce系とか登場当時は、「これで並列が簡単に使える」みたいなことが宣伝されてたよね。(最近あんま見かけない気がするけど) 一方、それに比べて

printfは複雑な挙動をするので信頼できないことが多い。おいつめられると以下のようなものをprintfがわりに使う。 デバッグwhile(1) コードが止まるかどうかを判定することでフローを確認する。マシン語数命令で完結するのでかなり信頼できる。OS無し環境でも使えるのが嬉しい。Windows環境下ではプログラムを終了させるのが面倒。副作用が無いので時間かかっているだけなのか判定できない。 デバッグ *(int*)0 = 0; (デバッグSEGV) プログラムが終了するかどうかを判定してフローを確認する。さらにcoreを吐かせたり、JITデバッグしたりしやすい。ライブラリを必要としないので、abortよりも信頼できるしバックトレースもきれいに出る。が、Windows GUIはたまに例外を握り潰してることがある気がする(やめてくれ) デバッグexit(1) プログラムが終了するかどうかでフ

http://d.hatena.ne.jp/shi3z/20150422/1429659958 の反論見てると、「いまどきはコンパイラがSIMDにしてくれるし」みたいなのがそれなりにあるのだけど、僕は基本的に自動ベクトル化とか信用していないので、私は考えが古い人間なのかと思って結構ショックだった。 (機械語知ってればデバッグ技の幅がかなり広がるので、可能なら機械語まで知っておいたほうがいいというのには大体同意できる。その話はまた気が向いたら…) 以下、自動SIMD化を信用できない理由について書いておく。 遅くなる場合がある まだプロファイルフィードバック技術が完成していない現代では、コンパイラがループ回数わからないから、3回とか7回のループだと遅くなる場合があるんだよな。 #include <x86intrin.h> #include <stdio.h> void __attribute_

http://icfpcontest.org/ いつも疲れてるからあとで書こうと思って結局書かないので今日のうちに書いておこう。 コードは、 提出したの : https://onedrive.live.com/redir?resid=ECB59E566C2D71F1!4183&authkey=!ALgIJhZtnX4zNCU&ithint=file%2czip lambdaman: http://int.main.jp/files/icfpc2014/lambdaman.gcc ghost: http://int.main.jp/files/icfpc2014/ghost0.ghc 何故か会社の人で毎年参加するという文化があったので@foota, @nabesan_tofu, @tomerun, @logicmachine, 私の5人で参加した。(その文化は公認になって宿泊費とかが会社から

プログラマが集中してる時は邪魔すんな、みたいなのって、当然のように語られてるけど、あれ、正しくないこともよくあると思う。 まあ、真面目な話をすると、プログラマの障害の半分くらいはコミュニケーションロスから出てくるのだから、作業効率半分くらいになったとしても、話しかけんなオーラをアピールするのは良くない、とかある。 …が、まあそれはいいとして、寂しいから話しかけて欲しい、という人も、それなりにいると思う。 2ヶ月くらい前になんかの機会に8人ぐらいに聞いたところ、「集中してる時は話しかけんな」派は半分くらいだった。 多分、割合としては、 話しかけんな派 : 50% どっちでもいい派 : 25% 寂しいから話しかけて欲しい派 : 25% くらいなんではないですかね。(超適当) 僕とかは、人に仕事頼まれた直後とかは、承認欲求パワーによりそれなりにやる気あるけど、そこから2時間とか半日とか過ぎると、

まあ最近のインターネットを活用した鬱研究によると、自分のこと悪く言うのが一番良くないと言われつつあった。 しかし、この点エンジにゃーは若干不利だよな。エンジにゃーは、それなりに、ものごとを悪く考えるのが仕事として有利な場面があって、日頃から物事を悪いほうに考える訓練をしてると言える。 もちろん、仕事で悪く考えるのと、日常のものごとを悪く考えるのは一緒ではないが、人間の精神はそんなにうまく切り離せるものではないので、こうしてエンジにゃーな人々は鬱っていくのだった。 まあ仕事より健全な精神のほうが大事なので、仕事でも悪く考えないようにするのが大事だと思う。 ファイル開けなかったらどうしよう 大丈夫。開けるよ。 ユーザーが操作まちがえたらどうしよう まちがえるやつが悪いよ。僕は悪くないよ SQL文字列が送られてきたらどうしよう その人、SQL送ってデータベース見たかったんだよ。お客の要求に応えた

http://software.intel.com/en-us/blogs/2013/07/23/intel-memory-protection-extensions-intel-mpx-design-considerations 最近MPXという文字を見るな、という気がしてて、Memory Protection Extension とか書いてあったので、またVMとかで保護機能増えたのかな、と思ってたが、そんなことはなかった。 Intel MPX 拡張は、ユーザー空間でアドレス境界チェックを簡単にするための拡張。サポートは、http://software.intel.com/en-us/articles/intel-software-development-emulator によると Skylake/Goldmontからと書いてある。 使い道は色々ありそうで、みんな知っておくべきだと思った