目次: Zephyr
Zephyr RISC-V SMP対応にチャレンジしてます。
Zephyrは既に他のアーキテクチャでSMP対応されていますから、真似するだけの何がチャレンジなの?簡単でしょ?と思われるかもしれません。その考え方は間違ってないんですが、少なくとも私にとっては「余裕」と言えるほど簡単ではなさそうです。
RISC-V向けの実装はAArch32をパクっているようで「お前、シングルコアだろ?な?」的な実装がそこら中にあり、SMPを有効にした途端、猛烈にコンパイルエラーが出ます。
一個一個見てますが、先ほど、コンテキストスイッチから直さないとダメなことに気づきました。こりゃ先は長そうだ〜……。
目次: Windows
今に始まったことではないのですが、Windows 10が突然高負荷に陥ってしまうことがあります。大抵Windows Updateが裏で動いているだけのことが多いですが、今日は様子が違ったのでメモしておきます。
いつもと違う点、その1は、Systemプロセスが高負荷に陥っていることです。Windows Updateが裏で実行されている場合、マウスを動かしたりキーボードに触ったりすると負荷が下がります。今回はマウスを触っても負荷が下がりません。
Process Explorerで見るとPsReturnProcessNonPagedPoolQuota() という関数がめちゃくちゃ頑張っていました。なんでしょうね?これ?
NVIDIAがArm全株式買収、ソフトバンクGから最大400億ドルで - ケータイWatch を読んで。
NVIDIAがArm買収です。買収額の2/3は株式交換で、ソフトバンクはNVIDIAの大株主になります。買収が成立すれば、ソフトバンクは1兆円超の利益を得ます。
ArmがNVIDIA配下となれば、NVIDIAと思い切り食い合う、Ethos(エッジAIプロセッサ)とMali(モバイル向けGPU)はゴミ箱行きですかね?ディスコンにしなくても、まともに開発しなくなりそうです。
さらにNVIDIAはNVIDIA GPUをライセンスするメリットがない(自分で作れる)ので、組み込み業界はImagination PowerVRとArm Maliという2大モバイルGPU IPを揃って失ってしまう悲しい未来になりそうです。
他陣営(RISC-Vとか)はまともなGPU IPがありませんし、Armがどんな地獄になろうとも、グラフィック必須のスマホ系SoCベンダーに逃げ場はなく、Armで作り続けるしかありません。
Armの築いたエコシステムがArmごとひっくり返されるとは思いませんでしたね。耐震構造のビルを建てていたら、いきなり一面の海になるような……バグったゲームみたいですが、現実なんですよね。
中国はImaginationごとPowerVRを買ってるので、ArmもしくはRISC-V用にPowerVRを売り出す可能性はあります(もう売ってる?)けど、PowerVRって性能的に今の時代のGPUに追いついているんでしょうか??
メモ: 技術系?の話はFacebookから転記しておくことにした。
目次: FreeRTOS
FreeRTOSにRISC-V QEMU virtpcのパッチをぶん投げてみました。やり方はGitHubでプルリクエストを送れば良いみたいです(説明へのリンク(FreeRTOS/CONTRIBUTING.md))。
FreeRTOSには既にQMEUのプロジェクトはある(SiFive HiFive1エミュレーション環境向けのEclipseプロジェクトがある)から要らないよ!?と言われることが目に浮かびますが、それならそれで良し。今後なにかの役に立つでしょう。
FreeRTOSはインデントやコード記法が非常に特徴的で、とても書きにくかったです。
void vFunc( int aaa )
{
int xBbb;
if( aaa )
{
/* do something */
xBbb = 0;
}
}
クセが強すぎる。何でこんな記法にしたのやら……??
メモ: 技術系?の話はFacebookから転記しておくことにした。色々と加筆。
自動車業界(だけじゃないですが)で重宝されているMATLABを家で使えることになったので、インストールしてみました。
ダウンロードは Mathworksのサイトからできますが、たぶん会社や学校からもらえるアカウント、アクティベーション番号が必要です。MATLABは個人でも買えますがメチャクチャ値段が高く、私は買う気は起きません……。
MATLABはDebian 9, Debian 10には対応しています(System Requirements for MATLAB R2020a - MATLAB & Simulink)が、Debian Testingには対応していません。インストーラを起動した瞬間にクラッシュします。
$ cd matlab_archive $ unzip matlab_R2020a_glnxa64.zip $ ./install terminate called after throwing an instance of 'std::runtime_error' what(): Unable to launch the MATLABWindow application Aborted
ありがたいことに、Linux向けのMATLABインストーラは通常版とlegacy版が同梱されています。
$ cd matlab_archive $ unzip matlab_R2020a_glnxa64.zip $ bin/glnxa64/install_unix_legacy
推奨された使い方ではないと思いますがlegacy版ならばインストーラが動きます。質問にはハイハイ答えておけば、そんなに問題ないはずです。
MATLABを起動するときに変なエラーが出ます。
$ matlab MATLAB is selecting SOFTWARE OPENGL rendering. matlab_install_dir/bin/glnxa64/jcef_helper: symbol lookup error: /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0: undefined symbol: g_ptr_array_copy
このエラーはMATLABの動的ライブラリの構成がおかしいことが原因です。libglib-2.0.soをMATLAB内部に抱えているのですが、libpango-1.0.soはシステム側を使うため、バージョンの非互換が発生します。libpango-1.0.soも内部に抱えれば良いのに??何だか中途半端な作りですね。
$ ldd bin/glnxa64/jcef_helper | grep glib libglib-2.0.so.0 => matlab_install_dir/bin/glnxa64/../../cefclient/sys/os/glnxa64/libglib-2.0.so.0 (0x00007f43ac828000) ★MATLAB内部に抱えているライブラリをダイナミックリンクする $ cd matlab_install_dir/cefclient/sys/os/glnxa64 $ mv libglib-2.0.so _libglib-2.0.so $ mv libglib-2.0.so.0 _libglib-2.0.so.0 $ mv libglib-2.0.so.0.5600.1 _libglib-2.0.so.0.5600.1 $ ldd bin/glnxa64/jcef_helper | grep glib libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f10b2e6d000) ★システム側のライブラリをダイナミックリンクする
MATLABの内部で抱えているlibglib-2.0.soを無視して、システム側のlibglib-2.0.soをダイナミックリンクすればエラーは出ません。これも推奨された使い方ではないと思いますが、とりあえず動いたのでめでたしめでたし。
< | 2020 | > | ||||
<< | < | 09 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | 1 | 2 | 3 | 4 | 5 |
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | - | - | - |
合計:
本日:
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2023.
Powered by PHP 8.2.7.
using GD 2.3.3(png support.)