Cygwin + MinGW + GCC 相談室 Part 8
まあ名前解決のところと passwd/group の設定はしといた方がいいね >>712
forkが遅いのはわかってるけど、
このコードでforkなんて大量にはしないだろ？
time bash -c 'for i in {1..1000000}; do :; done' 元々、bash が、ループ向きではないから、dash などを使う
for は遅いから、while などを使う。
実行時間中のほとんどが、フォークの時間
ループは、awk, perl, ruby などでは、0.1 秒も掛からない。
単一プロセス中の処理だから あ、dashの結果書くの忘れてた。dashは速いから数を10倍にしてる
傾向は一緒。ただのループなのに2倍ぐらいの差が出てしまう
WSL1
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m4.480s
user 0m2.875s
sys 0m2.047s
Cygwin
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m7.598s
user 0m6.531s
sys 0m1.296s
MinGW64
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m7.905s
user 0m6.905s
sys 0m1.155s awkは更に速いから、更に10倍にしてる。これなら理解できるな。
CygwinとMinGW64がWSL1より少し遅いのは起動時のパフォーマンスの差だろう
ってことはシェルスクリプトだと、なにか遅くなる処理をやってるってことか
整数型じゃないとか？
WSL1
$ time awk 'BEGIN{i=0;for(i=0;i<100000000;i++);}'
real 0m4.121s
user 0m4.109s
sys 0m0.016s
Cygwin
time awk 'BEGIN{i=0;for(i=0;i<100000000;i++);}'
real 0m4.978s
user 0m4.875s
sys 0m0.031s
MinGW64
$ time awk 'BEGIN{i=0;for(i=0;i<100000000;i++);}'
real 0m4.586s
user 0m4.562s
sys 0m0.015s for がコマンドだから、フォークされるのだろ。
だから、シェルスクリプトでは、while を使えと言われる
bash よりも、dash を使う。
それ以上は、awk, perl, ruby whileを使うと遅いからforに変えたのですが？
forを使った>>716とループ回数は同じ
WSL1
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m4.480s
user 0m2.875s
sys 0m2.047s
$ time dash -c 'i=0; while [ $i -lt 10000000 ]; do i=$((i+1)); done'
real 0m15.811s
user 0m15.766s
sys 0m0.016s
Cygwin
$ time dash -c 'for i in $(seq 10000000); do :; done'
real 0m7.598s
user 0m6.531s
sys 0m1.296s
$ time dash -c 'i=0; while [ $i -lt 10000000 ]; do i=$((i+1)); done'
real 0m26.173s
user 0m26.109s
sys 0m0.031s
MinGWはCygwinと大差ないので省略 8年前のシェルスクリプトの本には、
10万行の処理で、
for : 9分
while : 5秒
awk/perl : 0.1秒 $((i+1)) という部分が、コマンドだから遅いのだろう
ほとんどが、そのフォーク時間 せいぜいbashのサブコマンドで、forkしとらん気がする
ただマルチスレッドは使ってるかも知れんし、その際のメモリ操作はなんか性能の問題があった気はする $(())内でiを更新できることから分かるようにforkしていないし、少なくともbashとdashはシングルスレッド
linux上で
ltrace -f bash -c 'for i in {1..1000000}; do :; done'
したら、mallocを何度も呼んでいるようだから、ヒープ操作関係が遅い可能性はある
実際、linux上でもmallocの実装をglibcのからjemallocに切り替えたら上のループが2割近く速くなった wsl2は仮想マシンになるのか
windowsバイナリ実行できるのかな 以下のパッケージ、入れようとすると対象が見つからないと出るんだけど・・・
dlfcn
libpng
tools-git
jq
clang WSL, Ubuntu 18.04 には、jq もあるけど
apt-cache show jq
メンテナー : 陳昌倬 >>727
ないんだろ？Cygwinは独自のディストリ
Windowsに移植できたもの、自分が関心があるパッケージしか
登録されていない MSYS2でWin32アプリ作ってみようとチャレンジ中 msys2をサイレントインストールするにはどうしたら良いですか？ WSL2で 9PFs 経由でWin32側のファイルを読み込むの、なんでこんな遅いの？ 仮想マシン経由だからでは？
だからWSL1も引き続き開発してるわけで 同意。mingwは存在意義があるけど、cygwinは役割を終えた。 mingwは「Git For Windows」のバンドルモジュールとしてしぶとく生き残る。
cygwinはdll依存をなくしてmingwに統合されていくでしょ。 それを言ったらGit Bashはmsys2のbashだが、bashがmingwに移植されるとは思えんな gcc -staticがデフォじゃないのがよくわからん
じゃあMinGWの立ち位置って何よって bash使いたいならbusybox-w32を使えばいいじゃない MinGWの立ち位置？
Win32アプリをビルドできるGCC環境 ReactOS Build Environment (RosBE)という選択肢もアリます。 MSVC に依存したくないので、mingw をお手軽に維持できる cygwin 環境はありがたいですね… WineHQとかRosBEとかはLinuxでも使えるクロスコンパイラを用意している。まあ、やる人は少ないが。 別にlinuxからでもクロスコンパイルできるんやろ？ XPでも動くプログラムが作れるってのが味噌。MSYS2はVista+に移行した。 移行したと言うか、互換性の点でbashの方が良かったが
bashのライセンスがGPL3に変わって受け入れられなかったから
仕方なくzshにしたってだけだろ
古いbash 3系よりは、zshの方がまだましという消極的な理由 >>752
>>754
tdmgcc で cygwin から解放されました
ほんとうにありがとうございました tdmgcc は wikipedia では開発が止まった事になってるな。 今時mingwはmsys2のを使っときゃいいんだよ SourceForgeのMinGWページを隅から隅まで探せば書いてあるじゃん 隅から隅まで探さないといけないやつを検索すらできないのかっていうのはなんか違わない？？？？？
僕そもそもなぜかCygwinの話だと思ってたからそれ以前の問題なんですけど こまけーことは気にせずにmsys2使っときゃええんやで
cygwinはなあ…gccの更新いつも遅いから Git for Windows にバンドルされてるbash使えばいい。
ビルド環境はStrawberry Perlにバンドルされてるのを使えばいい。 ライブラリをストリップしたらあかんのではないかな
gccのオプションにexceptionのなんかがあった気がする Visual Studioに入ってるdumpbinに相当するコマンドある？
DLLのエクスポートテーブルを覗きたいんだけど digitalmars_com /ctg/implib.html
wiki_dlang_org /Win32_DLLs_in_D
www_kmonos_net /alang/d/dll.html fork: retry: resource temporarily unavailable とかでて直せない。
rebaseallとかやっても効果ないみたいだし
もうcygwin、msysのテストやめようかな MSYS2には、lscpuコマンドはないのかな？
CentOSなんかだとutil-linuxパッケージに入ってるけど、MSYS2のには入ってないもよう。。。 /proc/cpuinfo
/proc/meminfo
/usr/bin/free
はあるんだけど、lscpuはないんだよな。。。 Windows 10, WSL2, Ubuntu 18.04 には、
/usr/bin/lscpu
がある コロナもどんどん変異種がでてきとるしな
もう人類は無理だろ
さよなら人類 
