2024/05/02(木)Ubuntu 24.04 インストール (2)

vmware toolsは、vmwareのゲストで
  • デスクトップのリサイズ、
  • ホストOSとのクリップボード共有(文字列のコピペが出来るようになる)、
  • フォルダ共有
などを実現するもので、ゲストOSへのインストールはほぼ必須です。vmware標準で提供されるものは無視してopen-vm-toolsを入れるのがお薦めです。20.04と同様、24.04でも自動的にインストールされ、デスクトップのリサイズもクリップボード共有も最初から動作していました。もしそうなっていなければ、
sudo apt install open-vm-tools-desktop
としましょう。

共有フォルダは、vmwareの「VM→Settings→Option→Shared Folders」をAlways Enabledにし、Addで適当なフォルダを共有フォルダに指定、再起動。
sudo vmhgfs-fuse -o allow_other -o auto_unmount .host:/ /mnt/hgfs
で/mnt/hgfs以下にマウント出来ました。永続的にmountするには、/etc/fstabで
.host:/ /mnt/hgfs fuse.vmhgfs-fuse allow_other,auto_unmount,defaults 0 0
と書くとよいでしょう。

2024/05/02(木)Ubuntu 24.04 インストール (1)

2年に一度のubuntuのLTS (Long Time Support) である24.04LTS、インストール日記を書くのが恒例になってるので、今年も書きます。基本的にアップグレードはあんまり信用して無くて、2年に一度、一からインストールしてどう変わったのか確認してます。

Ubuntuの24.04というのは2024年4月のバージョンという意味です。Ubuntuは22.04, 22.10, 23.04...のように半年に一度新しいものが出ますが、基本的に9ヶ月のサポート期間のところ、偶数年の4月に出るバージョン(LTS)は5年のサポート期間があります。Ubuntu 24.04は、2024年4月25日にリリースされました。

インストール用のisoファイルは、http://releases.ubuntu.com/24.04/からubuntu-24.04-desktop-amd64.isoをダウンロードしました。

インストールは、Linux版のVMwareで行ったので、メニューの項目が英語になってます。File→New Virtual Machine→Create a New Virtual Machine→Typical (recommended)
→I will install the operationg system later→Linux→Ubuntu 64bitの手順で仮想マシンを作成。ディスクはデフォルトの20Gじゃ少ないので512Gに増やしました (ここを多くしても実際に仮想マシン内で使用しない限りホストマシンのディスクを圧迫することはありません)。メモリはとりあえずデフォルトの4Gで (こちらは大きくするだけホストマシンのメモリを食います)。VM→Settings→CD/DVDでダウンロードしたisoをマウントし起動。
  • 「Install Ubuntu」とし、言語は「日本語」を選ぶ。
  • キーボードレイアウトは「日本語」「日本語」
  • アクセシビリティは、何もせず「Next」
  • インターネットの接続方法は「有線接続を使用」
  • 「Ubuntuをインストール」「対話式インストール」
  • インストールセットは、「既定の選択」(最小限のWebブラウザーと基本的なユーティリティのみです。)と、「拡張選択」(オフィスツール、ユーティリティにWebブラウザーを含み、オフラインに優しい選択です。)が選べるようになっていましたが、「拡張選択」
  • 「グラフィックスとWi-Fi機器用のサードパーティ製ソフトウェアをインストールする」、「追加のメディアフォーマット用のサポートをダウンロードしてインストールする」をチェック。
  • 「ディスクを削除してUbuntuをインストールする」を選ぶ。
  • ユーザ作成時、「ログイン時にパスワードを要求する」はチェックしたままにする。
  • タイムゾーンは「Asia/Tokyo」
インストールは問題なく終了しました。

とりあえず端末を出すには、右下の丸いアイコンをクリックして「端末」を選びます。右クリックして「お気に入りへ追加」するといいでしょう。

日本語をかな漢字変換で入力するには、インストール直後の一回だけ、右上の「ja」をクリックして、「日本語(Mozc)」を選ぶ必要があります。

2024/02/07(水)g++-13と_Float64xとkv-0.4.56

kvライブラリを0.4.56にアップデートしました。

今回は問題発生への対処です。ある人から、g++ version 13でkvがまったくコンパイルできない、clang++では問題ないと連絡が来ました。実際、ubuntu 23.10を入れて試してみると、test-rounding.ccとかtest-interval.ccみたいな基本的なプログラムすらコンパイルエラーになってしまいました。

調べてみると、_Float64x (IntelのFPUが持っている80bit拡張浮動小数点数) の関係する部分がエラーになっています。kvどころか、
#include <iostream>

int main()
{
        _Float64x a;

        std::cin >> a;
}
みたいな単純なプログラムがコンパイルエラーになってしまいます。また、
#include <iostream>
#include <limits>

int main()
{
        std::cout << std::numeric_limits<_Float64x>::epsilon() << std::endl;
        std::cout << std::numeric_limits<_Float64x>::max() << std::endl;
        std::cout << std::numeric_limits<_Float64x>::min() << std::endl;
        std::cout << std::numeric_limits<_Float64x>::infinity() << std::endl;

        std::cout << std::numeric_limits<__float80>::epsilon() << std::endl;
        std::cout << std::numeric_limits<__float80>::max() << std::endl;
        std::cout << std::numeric_limits<__float80>::min() << std::endl;
        std::cout << std::numeric_limits<__float80>::infinity() << std::endl;

        std::cout << std::numeric_limits<long double>::epsilon() << std::endl;
        std::cout << std::numeric_limits<long double>::max() << std::endl;
        std::cout << std::numeric_limits<long double>::min() << std::endl;
        std::cout << std::numeric_limits<long double>::infinity() << std::endl;
}
は、
0
0
0
0
1.0842e-19
1.18973e+4932
3.3621e-4932
inf
1.0842e-19
1.18973e+4932
3.3621e-4932
inf
のように、numeric_limits<_Float64x>はすべて0を返してきます。

調べてみると、「_Float64xをサポートしているのはgccのみで、もともとg++では_Float64xをまったくサポートしていなかった。しかしversion 12までは単なるlong doubleのtypedefだったので、たまたまg++でも動いてしまっていた。最新のg++ version 13では_Float64xを部分的にサポートするようになったがlibstdc++はサポートしていない状態になり、結果的にまったく使えなくなってしまった」ということのようです。やりとりはこの辺

gccのドキュメントの6.12 Additional Floating Typesでは、「As an extension, GNU C and GNU C++ support additional floating types, (中略) _float80 is available on the i386, x86_64, and IA-64 targets, and supports the 80-bit (XFmode) floating type. It is an alias for the type name _Float64x on these targets. 」とはっきり書いているので、g++でも_Float64xはサポートされているように見えるのですが。

IntelのCPUではlong double、__float80も_Float64xと同じ80bit拡張浮動小数点数です。こっちの2つはg++-13でも生き残っています。どちらかで全部書き換えることも考えたのですが、long doubleは異なるアーキテクチャだと異なる浮動小数点数フォーマットに対応していることが多く、トラブルを招く可能性が高い、__float80はgccのみのオリジナル拡張でclangで使えない、とそれぞれ問題があります。

もっともメジャーで、4月にはみんながubuntu 24.04を使い始めることを考えると、g++-13で動かないなんてのは使い物にならないも同然なので、緊急にkv-0.4.56をリリースしました。とりあえず最低限の変更で、g++-13では_Float64x関連の機能が全部働かないようにしました。g++-12以下ではすべて問題なく、g++-13では_Float64xを使う機能を除いてすべてコンパイルできるようになりました。他の変更は、ついでにoptimize.hppにちょっとした追加機能が入ったくらいです。

g++-14以降でちゃんと戻ることを祈るのみですが、こんなIntel CPUにしかない盲腸のような機能を使おうとするほうが悪い、という話でもあるのかな。

2022/09/16(金)kv-0.4.55

久しぶりに、kvを0.4.55にアップデートしました。

今年の1月に、M1 macの区間演算は遅い?という記事を書きました。このときに、ARM CPUでのinline assemblerによる丸めの向きの変更のコードを追加していたのですが、大して面白い変更では無かったので放置していました。気づいたら8ヶ月も経ってしまい、細かい修正も溜まってきたのでここでいったん公開することにしました。

というわけで、今回の変更はARM CPUで-DKV_FASTROUNDを付けるとinline assemblerによる丸めの向きの変更が使えるようになる、というものです。ARM 64bitだけでなく、一応ARM 32bitでも動くようにしたつもりですが、あまりテストされていません。

詳細は丸めモードの変え方とコンパイルオプションまとめの「6. ベンチマーク」に書きましたが、一般的にARM CPUでは丸めのモードを変更すると実行時間で大きなペナルティがあるようで、Intel CPUに比べてかなり遅いです。ARM CPUではハードウェアによる丸め変更を一切行わずにソフトウェアで方向付き丸めをエミュレートするのが一番速いという、残念な状況になっています。これを、精度保証に向かないCPUが普及しつつあって残念と見るか、エミュレーションのアルゴリズムを開発しておいて良かった、と見るか。

以下、とある区間演算を多用したプログラムを、端点がdouble精度の区間演算と、端点がdd精度の区間演算の場合について、オプションを変えながら実行したときの実行時間を上のページから抜き出しておきます。爆速のはずのM1 chipの計算速度が遅く、-DNOHWROUND (ソフトウェアエミュレートによる丸め変更) が一番まともになっているのが分かります。

core i5 11400

計算精度(端点の型) コンパイルオプション
(-O3 -DNDEBUGに加えて)
計算時間
-DKV_USE_TPFMAなし -DKV_USE_TPFMAあり
double なし 6.65 sec
-DKV_FASTROUND 3.74 sec
-DKV_NOHWROUND 7.88 sec 6.05 sec
-DKV_USE_AVX512 -mavx512f 2.74 sec
dd なし 37.20 sec 33.58 sec
-DKV_FASTROUND 25.08 sec 21.52 sec
-DKV_NOHWROUND 92.24 sec 71.81 sec
-DKV_USE_AVX512 -mavx512f 16.47 sec

M1 MacBook Air

計算精度(端点の型) コンパイルオプション
(-O3 -DNDEBUGに加えて)
計算時間
-DKV_USE_TPFMAなし -DKV_USE_TPFMAあり
double なし 24.45 sec
-DKV_FASTROUND 22.36 sec
-DKV_NOHWROUND 9.08 sec 6.03 sec
dd なし 108.8 sec 100.6 sec
-DKV_FASTROUND 102.4 sec 94.64 sec
-DKV_NOHWROUND 84.60 sec 53.76 sec

2022/06/13(月)Ubuntu LinuxでVMware Workstation pro/playerを使うときの注意

割と長いこと(15年くらい?)、windowsにVMwareを入れて(というかVMwareしか入れない)、そこにFreeBSDやLinuxを入れて、その中で生活する、という生活を続けてきました。LinuxなどのPC-UNIXはハードウェアの違いを吸収する力が弱く、windowsをハードウェアの違いを吸収するためだけに使う、という考え方でした。しかし、ここ2年くらい、Linux (Ubuntu) の完成度は十分高くなり、デスクトップなら当然、ノートPCでも、普通にインストールすれば大体普通に動くようになってきました。そこで、ホストとゲストを逆転させて、PCには基本的にUbuntuを入れてそこにLinux版のVMwareを入れ、どうしてもwindowsを使いたいときだけ仮想で飼っているwindowsを使うようになりました。

UbuntuでVMwareを使うときの特別な設定を備忘録も兼ねて書いておきます。誰かの役に立つかもしれないので。

ゲストが異常に重くなる現象への対策

特に複数ゲストを起動したときなどに、ゲストがほとんど操作不能なレベルで重くなってしまい、そのときホストではkcompactd0というプロセスのCPU使用率が100%になっている、という現象が見られることがあります。数分待つと解消しますが、またすぐに再発します。これは多くの人が悩まされ決定的な対策はなかなか見つからなかったのですが、
にあるように最近対策が見つかりました。rootで(sudo suとかした後に)、
echo 0 > /proc/sys/vm/compaction_proactiveness
とすると立ちどころに収まります。永続的にこれを設定するには、/etc/sysctl.confに
vm.compaction_proactiveness=0
と書き加えて再起動すればいいようです。

Ubuntu 22.04でVMware Workstationを使う

現時点でVMware Workstationの最新版は16.2.3-19376536ですが、これはまだUbuntu 22.04の新しいカーネルに対応していないようで、初回起動時のカーネルモジュールのコンパイルでエラーになってしまい、起動することができません。そのうち対応するでしょうけど、とりあえず、
にあるように、
git clone https://github.com/mkubecek/vmware-host-modules
cd vmware-host-modules
git checkout workstation-16.2.3
make clean
make
sudo make install
sudo modprobe -a vmw_vmci vmmon vmnet
sudo service vmware restart
で起動するようになりました。

NATを使ったとき、断続的にネットワークがON/OFFを繰り返す

ゲストOSのネットワークをNATにしたとき、ゲストOSの種類には関係なく、断続的に(10秒周期くらい?)ゲストのネットワークがON/OFFを繰り返す、という困った現象に遭遇しました。Ubuntu 22.04にVMware Workstationを入れたときに発生したのですが、別のマシンにUbuntu 22.04とVMware Workstationを入れて発生しないケースもあったので、発生する条件はよく分かりません。 (2022/6/15追記: その別のマシンでもこの現象を確認しました。当方の環境では、Ubuntu 22.04にしたことで2/2で発生。) 検索してみると、
このようにかなり以前からこの現象は発生していたようです。いろいろ検索したところ、解決策を見つけました。
によれば、vmware-natdがDHCPのleaseを頻繁に行っており、それ自身はIPが変わらなければ問題ないが、それが仮想マシンのネットワークの頻繁な切断を引き起こしてしまうのが原因らしい。実際、ホストの/var/log/syslogにはゲストのネットワーク切断と同期して
May 21 17:43:44 exa kernel: [14661.785888] userif-3: sent link up event.
May 21 17:43:47 exa kernel: [14664.977941] userif-3: sent link down event.
May 21 17:43:47 exa kernel: [14664.977949] userif-3: sent link up event.
May 21 17:43:52 exa kernel: [14669.758177] userif-3: sent link down event.
May 21 17:43:52 exa kernel: [14669.758186] userif-3: sent link up event.
May 21 17:44:00 exa kernel: [14677.442456] userif-3: sent link down event.
May 21 17:44:00 exa kernel: [14677.442465] userif-3: sent link up event.
May 21 17:44:03 exa kernel: [14680.650489] userif-3: sent link down event.
のようなログが残っていました。そこで、前の節で入れたカーネルモジュールのvmware-host-modules/vmnet-only/userif.cに、強引ですが
*** userif.c.original   2022-05-15 22:05:24.140904301 +0900
--- userif.c    2022-05-21 17:43:37.199281561 +0900
***************
*** 1002,1007 ****
--- 1002,1010 ----
        return -EINVAL;
     }
  
+    /* never send link down events */
+    if (!linkUp) return 0;
+ 
     if (userIf->eventSender == NULL) {
        /* create event sender */
        retval = VNetHub_CreateSender(hubJack, &userIf->eventSender);
のようにlink downイベントを発生しないようにパッチを当ててモジュールを再インストールしたら、問題は解決しました。

おわりに

おそらく、VMwareがバージョンアップしたら不要になる情報かもしれませんが、自分がこれらの情報に行き着くまでに結構苦労したので、こうしてまとめておけば誰かの役に立つかもしれないと思い、こうして情報を残しておきます。
OK キャンセル 確認 その他