Cygwin + MinGW + GCC 相談室 Part 8

Cygwin + MinGW + GCC 相談室 Part 8 (987ﾚｽ)
上下前次 1-新

617: 2019/12/23(月)18:46 ID:wtBUbgEZ(1) AAS
>>612
黙れ！

618(1): 2019/12/23(月)22:27 ID:nMe23UdH(1) AAS
>>615
何をしようとしているか大体分かった。
・/cygdrive/d/dev/debug はシンボリックリンクで /cygdrive/d/test/debug を指すと仮定
・/cygdrive/d/dev/some_file があると仮定
このとき
・まずcd /cygdrive/d/dev/debugする
・次にcp ../some_file .するとファイルが無いと言われる
ということだと思う。もしそうならそれがUNIX系では普通。LinuxやMacでもそうなる。

これは、cdした時点で既にカレントディレクトリが/cygdrive/d/test/debugに移っているからで、cpは/cygdrive/d/test/some_fileを読もうとしているために起こる。つまり
>本来はシンボリックリンクはカレントと共に使用される。
がUNIX的には正しくない。

実際の挙動としては、
・UNIXの場合、カーネル的にはカレントディレクトリはあくまでもディレクトリで、シンボリックリンクをパスの途中に含むことはできない
・cd ..でもといたディレクトリに戻るのはbashがシンボリックリンクを本当のデイレクトリのようにエミュレーションしているから(set -Pで切れる)
・これは基本的には内部コマンドのcdやpwdに対してのみできることで、外部コマンドのcpやlessに対してはできない(引数の..が親ディレクトリの意味になるかはコマンドに依存するから、シェルが勝手に置き換えられない)
・シェルはPWD環境変数にシンボリックリンクを含むロジカルなカレントディレクトリを出力するので、これを見るようにすれば原理的には外部コマンドもエミユレーションに対応できる(危なっかしいので普通はしない)

WindowsのシンボリックリンクはUNIXと違ってOS自体がシンボリックリンクを含むカレントディレクトリを扱っているようだが、CYGWINはUNIXに合わせていると考えられる。

619(1): 2019/12/23(月)23:39 ID:IO6RyZUn(6/7) AAS
>>618
こちらの状況は正しく伝わっており、君の言っていることも正しい。
こちらも615を書いた後、遠い昔にシンボリックリンク周りでトラブった記憶があり、
あれはなんだったかな？と思っていたところだった。

つまりbashで上手く誤魔化していてくれているわけだ。
ではtcshは？と確認したが、こちらもsymlinks変数で誤魔化し方を調整出来るようになっている。
外部ﾘﾝｸ[html]:linuxjm.osdn.jp
結果、Cygwinとしては仕様通り、UNIXは糞仕様（≒仕様バグ）だな。

突っ込む必要はないと思うが、
> (引数の..が親ディレクトリの意味になるかはコマンドに依存するから、シェルが勝手に置き換えられない)
これはよく分からない。
bashがコマンドに引数を渡すときにあらかじめシンボリックリンク周りを解決していたら、どういう問題が発生する？
というかtcshだとsymlinks=expandに設定したらそうなるらしい。
今回で言えば、
MyMachine@MyName /cygdrive/d/dev/debug
$ cp ../some_file .
を cp /cygdrive/d/dev/somefile /cygdrive/d/dev/debug として実行すれば問題ないはず。
(.を展開する必要はないかもだが）
既存シェルスクリプトの互換性が無くなるだけなら仕様バグでした、残念でした、でしかなく、
後発のwindowsでは修正されているということになる。
シンボリックリンクを辿って、その上の「論理的ではない、物理的上位ディレクトリ」を辿る必要がある使い方なんて無いはず。

なお上記man of tcshのsymlinksの最後の
> > cd ".."; echo $cwd
> /tmp/from
> > /bin/echo ..
> /tmp/to ←これがよく分からん、/tmpではなくて？あるいはコマンドが .. ではなく /bin/echo . なら納得だが
> > /bin/echo ".."
> ..
分かれば出来れば解説よろしく。

620(2): 2019/12/23(月)23:43 ID:gENEPh5i(1) AAS
WindowsがーではなくCygwinの問題でしょ
WindowsはWindowsの仕様でやってる。それがなんであれ正しい仕様

Cygwinがエミュレート機能をすべて行ってる
問題があるならそれはCygwinの問題

WSLならその問題も解決してるだろうさ

621: 2019/12/23(月)23:58 ID:IO6RyZUn(7/7) AAS
>>620
それは違う。
Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
だから仕様としてUnixと同じ動作になる。
詳しくはWikiなり本家なり読めばいい。

問題はUnixの糞仕様が今も修正されずそのままbash等で誤魔化され続け、
windowsでは修正された？為に動作が異なっている事による。
ただこれをCygwinで修正することは出来ないし、するべき事柄でもない。

622: 2019/12/24(火)00:05 ID:8h2rOUkn(1/2) AAS
> Cygwinはエミュレーションレイヤーを提供しており、つまりUnixのシステムコールを受け付けているだけ。
ただしい

? だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない

623(2): 2019/12/24(火)00:06 ID:8h2rOUkn(2/2) AAS
なんか文字化けする方法のバツを記録してるな。これでいいか？

× だから仕様としてUnixと同じ動作になる。
○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない

624: 2019/12/24(火)00:22 ID:6GYTbaHl(1/4) AAS
>>620
なおWSLは理屈上はUnixの動作になるはず。
ただしbash等を見る限り既知の問題だから対策出来そうではあるが、
バイナリ互換なので現実的に無理だと思う。
(もちろんwindows専用bashを用意すればいいが、それだと既存のシェルスクリプトが動かなくなる。
といってもそれで問題が発生するような奴はWSLなんて使わずDockerだと思うが）

が、まあ、俺に関して言えば、
問題の詳細は判明し、特段問題ないから当面はCygwinを使う。

(すまんがNGに当たっているようなのでバラバラにして投稿する）

625: 2019/12/24(火)00:23 ID:6GYTbaHl(2/4) AAS
(すまんがNGに当たっているようなのでバラバラにして投稿する）

>>623
> ○ 仕様としてUnixと同じ動作になるように目指すべきだが、できてない
違う。そこを目指してない。
CygwinはUnixのシステムコールをcygwin1.dllが受け付けることにより、
GNU等が書き溜めた膨大なUnix向けCソースをそのまま動作させることを目標としている。
結果、ありとあらゆるUnixのツールがcygwin上では動くので、大成功している。

626: 2019/12/24(火)00:24 ID:6GYTbaHl(3/4) AAS
>>623続き

windowsのＣＭＤ。ＥＸＥのエミュレーションなんて必要ないし、目指してもいない。
本家でも読め。

そして認識も間違っている。CygwinはUnixと同じ動作になってる。つまり、「できてる」

627(3): 2019/12/24(火)00:29 ID:d/S5Qnsu(1) AAS
>>619
・tcshのmanは間違っているだけだと思う。実際試したら想定通り/tmpになった。
・シェルが勝手に置き換えるべきではないというのは、単にgrep ..とかの動作が今までと変わって直感的でなくなるあたりの問題。.や..の置き換えの仕様とエスケープやクォートの仕様を十分理解すればまあそんなに困らないとは感じる。

628: 2019/12/24(火)00:49 ID:6GYTbaHl(4/4) AAS
>>627
おおサンクス、手元にこなれた環境がないので助かる。
しかし今更このレベルの誤字ってあるかね？
まあtcshなんて今時誰も使ってないが、他のマニュアルもそうなってるし。
外部ﾘﾝｸ:linux.die.net
とはいえ実行結果がそうなのならそれが一番信憑性があるが。

Unixは今更直せないで行くのだろうけど、WSLの際にMS内部ではどうするか検討してるだろうね。
WSL推しの人はどうぞ動作報告よろしく。

629: 2019/12/24(火)15:52 ID:IBUEMR4t(1) AAS
WSLの話題はこちらへどうぞ 2chｽﾚ:linux

cygwinの話題は引き続きこのスレでどうぞ

630(1): 2020/01/05(日)00:06 ID:RxmL5T69(1) AAS
>>627
ばーーーか

631: 627 2020/02/21(金)14:13 ID:3bMJAyBr(1) AAS
>>630
ごめんなさい。

632: 2020/03/07(土)09:24 ID:6t68C04E(1) AAS
このところ、MSYS2 の pacman を実行するとエラーが出るな
サーバー不調なん？それとも pacman がバグった？
一度アンインストールして最初から入れなおしてもダメやった・・・

633: 2020/03/11(水)21:27 ID:o+x7iIJI(1) AAS
いつの間にか直ってた
やっぱり、サーバーが不調なだけだったのか・・・

634: 2020/03/12(木)11:58 ID:MzPDqAwN(1) AAS
自分の回線を疑う気は皆無か

635: 2020/03/12(木)19:21 ID:TmXPZpmc(1) AAS
自分の回線だけだったら書き込まないが・・・

636: 2020/03/25(水)09:30 ID:C+0WfFNh0(1) AAS
回線があまりに遅いと向こうからお断りしてくるのでは

637: 2020/03/28(土)13:48 ID:Mtf58BEo(1) AAS
サーバー不調なだけだぞ、公式でも話題になってた
外部ﾘﾝｸ:github.com

638: 2020/04/02(木)18:00 ID:1pp0Yvcl(1) AAS
今更
pacmanでfork errorでまくったので見切った。
wslでLinux入れてmingw64クロスコンパイルしている。
wslのコンソールでwindowsバイナリもそのまま動くし良い。
cygwinやmsysみたいにcygwin, msysバイナリとwindowsバイナリが混在することの混乱もないしさらに良い

639: 2020/04/03(金)04:00 ID:FV+QUjkb(1) AAS
GCC 9.3を早く出してくれ

640: 2020/04/03(金)09:51 ID:yEeayoKI(1) AAS
pacmanでfork errorの一番の解決策は
ちゃんと出てきたメッセージを読むこと
これに尽きる
638がそうなのかは知らんが

641: 2020/04/05(日)22:38 ID:bwZ5xk1F(1) AAS
WSLよりMSYS2の方が更新早い？

642: 2020/04/06(月)09:55 ID:m+LKHOnj(1) AAS
WSLで使うディストリビューション(ArchとかUbuntuとか)によるでしょう
共通して言えるのはLinuxではセキュリティ修正の取り込みは早い

643: 2020/04/06(月)20:27 ID:O5iO/eDc(1) AAS
WSL は色々なディストリビューションが選べるんですね

644: 2020/04/19(日)17:57 ID:UEW9MHEw(1/2) AAS
インストールしようと思ったら、このサイト3年近く更新が止まってる・・・
外部ﾘﾝｸ:xhmikosr.1f0.de

今入れるならどうしたらいい？

645(2): 2020/04/19(日)22:00 ID:+AizyWB9(1) AAS
WSLがある以上、MSYSのメンテはもう廃れるだろうな。
意味ねーし。
cygwinはXのためだけに存在する

646: 2020/04/19(日)23:35 ID:UEW9MHEw(2/2) AAS
>>645
えっ、そんなのあるの？

647: 2020/04/20(月)01:29 ID:VYi0JRSU(1) AAS
そ、そんな〜(´・ω・｀)

648: 2020/04/20(月)04:16 ID:DIgHaEzI(1) AAS
更新が止まってしまった

649: 2020/04/20(月)04:41 ID:H+0bMHyU(1) AAS
>>645
cygwinは便利だ。

650: 2020/04/20(月)07:25 ID:vhP2C7pa0(1) AAS
マジかよシグウィン窓から投げ捨てた
WSL派になります

651: 2020/04/20(月)08:37 ID:iSOfvkhv(1/2) AAS
DLLだけで動くのが便利なときもあるが、日々の生活はWSLだね

652: 2020/04/20(月)09:12 ID:aqwTNz7b(1) AAS
Windows 10, WSL, Ubuntu 18.04 で、
VSCode の拡張機能、Remote WSL も使う

Linux側には、日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv を使って、
ruby 2.6.6, node 12.16.2 を入れた

yarn は、Windows側に入れて、WSL から、拡張子なしのyarn コマンドを呼べる。
これは、#!/bin/sh で始まるシェルスクリプト

anyenv は多言語向きで、rbenv, nodenv, pyenv, phpenv などを同じ使い方で、統一的に扱える。
~/.bashrc に、下の2行を追加するだけで、各言語ごとに追加しないでも良い

export PATH="$HOME/.anyenv/bin:$PATH"
eval "$(anyenv init -)"

653(3): 2020/04/20(月)09:13 ID:lEczCUui(1/2) AAS
MSYS+MinGW、仮想マシン+Linuxって感じでWSLの入る余地がない
WSL+MinGWツールチェーンにすれば仮想マシンすら必要ないって考えもあるけど
やっぱり仮想マシンは手放せないからWindows側はMSYSでいいやってなる

654: 2020/04/20(月)10:24 ID:HdM6J8YZ(1) AAS
>>653
同じく

655: 2020/04/20(月)13:58 ID:2UEzrf8e(1/4) AAS
>>653
MSYS+MinGWで何作ってるの？
Windowsアプリ？

まあWindowsアプリしかないよね。
WSLはLinuxアプリを作って動かすものなので目的が違うよ。

656: 2020/04/20(月)14:00 ID:2UEzrf8e(2/4) AAS
仮想マシンは手放せないけど、仮想マシンはほぼテスト環境になった
作ったアプリを動かすための環境

普段の開発でテストのためだけの環境を使う気にならない
起動重いしメモリ食うし

657: 2020/04/20(月)14:10 ID:X6dUog3k(1) AAS
起動したままで良い
メモリ喰うのは諦めろ

658(1): 2020/04/20(月)14:16 ID:agWbeiM9(1) AAS
msys+mingw入れて何がしたい？
ffmpegをビルドしたいから

659: 2020/04/20(月)14:17 ID:2UEzrf8e(3/4) AAS
ああ、なるほど。テスト環境じゃないから
一つしか仮想マシンがないんだな

それぞれ微妙に異なるからテスト環境（仮想マシン）は
プロジェクトごとに必要なんだよ

660: 2020/04/20(月)14:18 ID:2UEzrf8e(4/4) AAS
>>658
LinuxツールのWindowsネイティブ版への移植以外になんかあるの？
ffmpegもそうだし

まあ全員がWSLをインストールしてるとは限らないから
Windowsネイティブ版を作る意味はあるだろうね。

661: 2020/04/20(月)17:04 ID:lEczCUui(2/2) AAS
だから何としか言えねぇ

662: 2020/04/20(月)21:50 ID:vn9gJe4h0(1/2) AAS
cygwin
mingw
wsl

作ったアプリの動作時オーバーヘッド（動作速度）が大きい順に並べて

663: 2020/04/20(月)21:54 ID:iSOfvkhv(2/2) AAS
c
w
m

664: 2020/04/20(月)21:57 ID:vn9gJe4h0(2/2) AAS
マジかよWSLに失望しました。窓から投げ捨ててMinGWに乗り換えます

665(1): 2020/04/20(月)23:38 ID:pVOiahav(1) AAS
いやいや君なんでも即断すぎやろw

666: 2020/04/21(火)05:17 ID:Lx1iEb8v(1) AAS
>>665
結論ありきの質問だからねｗ

使ってみればわかる。
WSLが一番軽いし一番正確に動く。

667: 2020/04/22(水)00:52 ID:nnh+EV8P(1) AAS
mingw-w64-〇〇〇-yasm-1.3.0-4 (は32bit用はi686、64bit用はx86_64)
yasm-1.3.0-2

どう違うの？
入れるのはどっち？

668: 2020/04/22(水)09:41 ID:UQ7whF8j(1) AAS
前者はMinGW-w64のDLLが必要。いわゆるネイティブアプリ
後者はMSYSのDLLと場合によってはターミナルエミュレータが必要
どちらを使うかは環境と用途次第

669: 2020/04/22(水)09:46 ID:O/jaLKmb(1) AAS
おま環

670: 2020/04/23(木)21:18 ID:4ZqPhGA2(1) AAS
msys2を入れてpacman -Syuをやった後、home/PC名のフォルダに、.gnupgというフォルダがあるんだけど、これって消しちゃダメ？

671(1): 2020/04/26(日)14:07 ID:XGLrD3LC0(1) AAS
え！？WSLってそのままでは音流せないんですか！？

672: 2020/04/26(日)15:10 ID:O/ywVmO1(1) AAS
gnupgってGPGだろ
GNU製のPGP暗号化と復号プログラム

673: 2020/04/26(日)16:13 ID:D7tlSM02(1) AAS
>>671
PulseAudio使えばいいだけじゃね？

674: 2020/04/27(月)04:32 ID:xcrAouIA0(1) AAS
ではWSLは、デフォルトでは音すら流せない杜撰な造りをしていると認めるんですか？

675: 2020/04/27(月)06:42 ID:4F1K1x/3(1/2) AAS
単にサウンドデバイスを実装してないだけだよ
設計は良く出来てるので実装しようと思えば出来るだろうが
利用者が求めてない機能なので優先度が低い
WSLの利用者は開発者だからね。開発者が欲しい機能が最優先

676: 2020/04/27(月)06:46 ID:4F1K1x/3(2/2) AAS
あ、もしWSLが開発者向けの機能を優先してるのを知った上で
WSLは駄目だって印象を与えようとした書き込みだったらごめん、邪魔したね
そうでないなら音ならWindowsで鳴らせばいいと気づければOKだよ
音を鳴らす程度のためにWSLは不要だからね

677(1): 2020/04/27(月)17:16 ID:cdGyQVmm(1) AAS
>>653
wslはwslのコマンドラインからlinuxバイナリもwindowsバイナリも動く優れものなんだよ

678: 2020/04/27(月)18:06 ID:AD9YXzU7(1/3) AAS
>>677
そうそう。だからbashのシェルスクリプトで
Windowsのコマンドを実行してOSの設定を変更するとかできちゃう

679(2): 2020/04/27(月)19:44 AAS
Windowsのコマンドプロンプト側からWSLのディレクトリに入っていけるの？

680: 2020/04/27(月)19:55 ID:AD9YXzU7(2/3) AAS
>>679
それはコマンドプロンプト自体の問題で、こいつは古いアプリなのでUNCパスに対応していない
UNCパス（\\ではじまるネットワークフォルダのパス）を扱えるツールを使う必要がある
WSLのディレクトリに対応してるかというよりも
ネットワークフォルダに対応しているかという話に近い

PowerShellはUNCパスに対応しているからWSLのディレクトリにも入れる
コマンドプロンプトから実行するコマンドもUNCパスに対応していれば参照できる
またネットワークフォルダはドライブに割り当てることが出来るので
ドライブに割り当てればコマンドコマンドからWSLのディレクトリに入ることも出来る

681: 2020/04/27(月)19:56 ID:AD9YXzU7(3/3) AAS
ちなみにcdの代わりにpushdを使えば
コマンドコマンドからUNCパスに移動できる
一時的にドライブを割り当てているだけだが

682: 2020/04/27(月)22:41 AAS
詳しい情報サンクス！
これなら皆がWSLへｌ移行するのもわかる気がする

683: 2020/04/27(月)23:26 ID:hGgbh3Gh(1) AAS
windowsのSSHサーバ立ち上げてwslをシェルにできるのは便利
PowerShell極めてるひとなら不要かもしれんけどね

684(1): 2020/04/28(火)10:33 ID:gG+m5xpc(1) AAS
MSYS2とWSLって共存出来るんですか？

685(1): 2020/04/28(火)10:52 ID:zAZN/f3s(1) AAS
マジレスするとmsys使ってて問題無ければwsl要らない

686: 2020/04/28(火)17:09 ID:7TaGv6sC(1/4) AAS
>>684
共存できる。msys2はただのアプリでしかないから

>>685
msysの問題はUbuntuと同じようなメンテナンス力を期待できないところかな
WSLは本物のUbuntuのディストリのパッケージが使われてるので
Ubuntuとほぼ同等にメンテナンスされてると思っていい

だけどmsysは（Ubuntuと比べたら小さな）開発者が対応してるパッケージしか使えない
しかもLinuxと完全互換じゃないからmsysでソースコードからコンパイルしようとしても
動くとは限らない。WSLを使えばそういった煩わしさから開放される。

msysはWSLを入れてない人のためのWindows用アプリを作るためのものだよ
開発者がLinuxの代わりとして使うものじゃない

687(1): 2020/04/28(火)17:14 ID:qC7CqvMj(1) AAS
ホームパスを一緒にすると色々弊害出そう

688: 2020/04/28(火)17:30 ID:7TaGv6sC(2/4) AAS
>>687
シンボリックリンクでホームディレクトリ以下から
アクセスしやすくするのがおすすめ
色々と混ざらないし複数のディストリでも共有できる

689(1): 2020/04/28(火)18:17 ID:eCWBo+Hl(1) AAS
色々と混ぜたいからホームディレクトリを一緒にするんだろ
そうじゃなければ最初から分けとけばいいだけの話だ

690: 2020/04/28(火)18:20 ID:7TaGv6sC(3/4) AAS
>>689
「色々」と混ぜたいならその「色々」だめを混ぜればいいじゃん
全部混ぜる必要はない

691: 2020/04/28(火)18:21 ID:7TaGv6sC(4/4) AAS
「色々」と混ぜたいならその「色々」だけを混ぜればいいじゃん

692: 2020/04/29(水)09:35 ID:TuLha3Ht(1) AAS
混ぜるな危険

693: 2020/04/29(水)09:46 AAS
Microsoft Store に　WSL Ubuntu 20.04 LTS　出てるけど、まだ入れない方がいいんですか

694: 2020/04/29(水)10:27 ID:Cpi+Il5+(1/2) AAS
早くても、8月以降に、20.04.1 とか修正版が出た後。
1年後でも良い

Ruby のirb では、MSYS2/MinGW で、日本語入力でバグるから、
WSL の方が、互換性が高い

日本人が作った、バージョンマネージャーのanyenv で、rbenv, nodenv で、
色々なバージョンも入れられる

VSCode も、Remote WSL 拡張機能で、Linux 側へアクセスできる

695: 2020/04/29(水)10:38 ID:Cpi+Il5+(2/2) AAS
>>679
コマンドプロンプト・PowerShell で、wsl と入力すれば、WSLが起動する

最も良いのは、Linux 側のフォルダのショートカットをデスクトップにでも作って、
そのフォルダの右クリックメニューから、VSCode を起動する

これで、WSLを起動して、Linux側のプロジェクトを開ける

696: 2020/04/29(水)11:51 ID:Jemg3aCN(1) AAS
wsl, opensuse leapにmingw64入れてクロスビルドしてる。
configure作って--hostでmingw指定すれば楽勝すぎて屁が出そう

697: 2020/04/29(水)11:51 AAS
自分が使っているWSLが１なのか２なのか知る方法は？

698: 2020/04/30(木)13:35 ID:HbyVq09Q(1) AAS
openSUSE Leap 15.1用のmingw配布消えとるやん
くそがー

699: 2020/04/30(木)17:32 AAS
そもそもWSL2はエンスー向けか
普通の人は１が入ってるのか

700: 2020/05/02(土)23:21 ID:nkPqW+JC(1) AAS
MinGWっていうかGitBash環境なんだけど
WSL1より2倍ぐらいシェルスクリプトが遅いんだよね
どこが原因かわからんけどこんなもん？
なにか大きな差がでるポイントでもあるんかね？

701: 2020/05/03(日)03:37 ID:HUz+EFHq(1/8) AAS
WSL1 (bash 4.4.20) だと
$ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done'
real 0m6.317s
user 0m6.313s
sys 0m0.000s

MinGW64 (bash 4.4.23) だと
$ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done'
real 0m15.053s
user 0m15.000s
sys 0m0.030s

Cygwin (bash 4.4.12) だと
$ time bash -c 'i=0; while [ $i -lt 1000000 ]; do : $((i+=1)); done'
real 0m13.897s
user 0m13.858s
sys 0m0.046s

うーん、こんな単純なコードで2倍の差がでてるから
もうこれはどうしようもないのか？

702: 2020/05/03(日)04:04 ID:HUz+EFHq(2/8) AAS
比較とか計算が遅いのかと思ってやってみたけど
この比率は変わらない

WSL1
$ time bash -c 'for i in $(seq 1000000); do :; done'
real 0m2.159s
user 0m1.828s
sys 0m0.359s

Cygwin
$ time bash -c 'for i in $(seq 1000000); do :; done'
real 0m4.222s
user 0m3.889s
sys 0m0.341s

MinGW64
$ time bash -c 'for i in $(seq 1000000); do :; done'
real 0m4.821s
user 0m4.342s
sys 0m0.436s

WSL1 → Cygwin（２倍ぐらい遅い）→MinGW（さらに10%遅い）
こんな傾向がある。ファイルシステムは関係ないはず
やってるのはCPUの処理だけなはずなんだけどなぁ

703(1): 2020/05/03(日)05:18 ID:1PSoskYy(1/2) AAS
調べるとradeonのドライバを切れとか書いてあるけど…

704: 2020/05/03(日)05:22 ID:HUz+EFHq(3/8) AAS
>>703
使ってないよｗ

705: 2020/05/03(日)05:24 ID:HUz+EFHq(4/8) AAS
radeonの話は画面に出力が絡むなら
関係ありそうな気もするけど、それ以外でも発生するんだろうかね
あとHOMEは MinGWは /c/Users/myname
Cygwinは/home/mynameだ

706: 2020/05/03(日)05:26 ID:HUz+EFHq(5/8) AAS
よく見ると大きな差があるのはuser空間だから
コンパイルオプションが違ってるとかなのかな？

707(1): 2020/05/03(日)05:38 ID:1PSoskYy(2/2) AAS
seq使うんじゃなくて{1..1000000}の方がいいかもね

708(1): 2020/05/03(日)06:00 ID:HUz+EFHq(6/8) AAS
>>707
つってもわずか一回だからなぁ。やってみてもいいけど

WSL1
$ time bash -c 'for i in {1..1000000}; do :; done'
real 0m1.710s
user 0m1.547s
sys 0m0.156s

Cygwin
$ time bash -c 'for i in {1..1000000}; do :; done'
real 0m4.854s
user 0m4.811s
sys 0m0.108s

MinGW64
$ time bash -c 'for i in {1..1000000}; do :; done'
real 0m4.934s
user 0m4.843s
sys 0m0.109s

あとあれから少しわかったのはMinGWは何回か繰り返せば
Cygwinに迫るのでファイル読み込み？とかも少し関連してるんだと思う
が2倍以上かかることに変わりはない

cygwin.dll？とかが遅いのかもな。MinGWでも使ってるんじゃなかったっけ？

709(1): 2020/05/03(日)07:25 ID:69WKUEPM(1) AAS
>>708
を、WSL1, Ubuntu 18.04 で、3回やった。
8GB メモリ、CPU-i3・エコモード

real 0m4.680s
user 0m4.234s
sys 0m0.453s

710: 2020/05/03(日)07:38 ID:HUz+EFHq(7/8) AAS
>>709
いや比較しないと意味ないだろｗ

711: 2020/05/03(日)07:39 ID:HUz+EFHq(8/8) AAS
ちなみに俺のはCPUはi7な
Cygwin、MinGWを実行したら
それの2倍かかるはず

712(1): 2020/05/03(日)21:39 ID:ADBK+oPb(1) AAS
cygwinはforkがヘボいから遅い
MinGWといいつつmsysのbashやろ
これもforkがcygwinゆずりだから遅い。
wslもfork遅いと思うけど。
virtual boxにwindowsファイルを共有させたものの方が実は速い。
純粋にwindowsとLinuxの環境を同居させたきゃ仮想PC
Linuxでwindows binaryをクロスビルド、テストまでしたけりゃwsl

713: 2020/05/03(日)21:47 ID:v0W4oGhj(1) AAS
まあ名前解決のところと passwd/group の設定はしといた方がいいね

714: 2020/05/03(日)23:40 ID:sXSeyux8(1) AAS
>>712
forkが遅いのはわかってるけど、
このコードでforkなんて大量にはしないだろ？

time bash -c 'for i in {1..1000000}; do :; done'

715(4): 2020/05/04(月)02:27 ID:R/PLl+Gn(1/4) AAS
元々、bash が、ループ向きではないから、dash などを使う

for は遅いから、while などを使う。
実行時間中のほとんどが、フォークの時間

ループは、awk, perl, ruby などでは、0.1 秒も掛からない。
単一プロセス中の処理だから

716(1): 2020/05/04(月)03:06 ID:szliIti6(1/5) AAS
あ、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

717: 2020/05/04(月)03:06 ID:szliIti6(2/5) AAS
>>715
どこでフォークしてるというの？

718: 2020/05/04(月)03:16 ID:szliIti6(3/5) AAS
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

719: 715 2020/05/04(月)04:54 ID:R/PLl+Gn(2/4) AAS
for がコマンドだから、フォークされるのだろ。
だから、シェルスクリプトでは、while を使えと言われる

bash よりも、dash を使う。
それ以上は、awk, perl, ruby

720: 2020/05/04(月)05:14 ID:szliIti6(4/5) AAS
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と大差ないので省略

721: 715 2020/05/04(月)07:28 ID:R/PLl+Gn(3/4) AAS
8年前のシェルスクリプトの本には、
10万行の処理で、

for : 9分
while : 5秒
awk/perl : 0.1秒

722(1): 715 2020/05/04(月)07:33 ID:R/PLl+Gn(4/4) AAS
$((i+1)) という部分が、コマンドだから遅いのだろう

ほとんどが、そのフォーク時間

723: 2020/05/04(月)07:37 ID:iIYyf/rd(1) AAS
せいぜいbashのサブコマンドで、forkしとらん気がする
ただマルチスレッドは使ってるかも知れんし、その際のメモリ操作はなんか性能の問題があった気はする

724: 2020/05/04(月)07:49 ID:szliIti6(5/5) AAS
>>722
コマンドじゃないよ

725: 2020/05/04(月)18:39 ID:EvcVp/Zr(1) AAS
$(())内でiを更新できることから分かるようにforkしていないし、少なくともbashとdashはシングルスレッド

linux上で
ltrace -f bash -c 'for i in {1..1000000}; do :; done'
したら、mallocを何度も呼んでいるようだから、ヒープ操作関係が遅い可能性はある
実際、linux上でもmallocの実装をglibcのからjemallocに切り替えたら上のループが2割近く速くなった

726: 2020/05/06(水)17:53 ID:cyb3WwF6(1) AAS
wsl2は仮想マシンになるのか
windowsバイナリ実行できるのかな

727(1): 2020/05/06(水)19:33 ID:DK8FW5YB(1) AAS
以下のパッケージ、入れようとすると対象が見つからないと出るんだけど・・・

dlfcn
libpng
tools-git
jq
clang

728: 2020/05/06(水)20:42 ID:Fjn1hDTG(1) AAS
WSL, Ubuntu 18.04 には、jq もあるけど

apt-cache show jq

メンテナー : 陳昌倬

729: 2020/05/06(水)22:45 ID:UqyV1t7H(1) AAS
>>727
ないんだろ？Cygwinは独自のディストリ
Windowsに移植できたもの、自分が関心があるパッケージしか
登録されていない

730: 2020/05/11(月)23:46 ID:77t5bXxM(1) AAS
GCC 10.1まだですか

731: 2020/05/12(火)00:26 ID:6XbzcR0E(1) AAS
ついにGCCのバージョンも10まできたか・・

732: 2020/05/12(火)01:18 ID:yS+J4vmz(1) AAS
GCCじゅにや

733: 2020/05/12(火)07:09 ID:zxRznJOz(1) AAS
カバにダンスをさせるのは
あまり楽しくないそうだ

734: 2020/05/14(木)00:17 ID:rBW8Yffw(1) AAS
MSYS2でWin32アプリ作ってみようとチャレンジ中

735: 2020/05/14(木)10:05 ID:tvxDWcUo(1/2) AAS
きばれ
tdm-gcc (64)

736: 2020/05/14(木)10:09 ID:tvxDWcUo(2/2) AAS
外部ﾘﾝｸ:jmeubank.github.io

737: 2020/05/14(木)10:17 ID:HbCKurWZ(1) AAS
Ruby はやめとけ