- Eclipse統合M35【Java/C++/Ruby/Python/Scala】
101 ：デフォルトの名無しさん[sage]：2014/09/06(土) 09:06:27.98 ID:Qjz0oFL7 - >>100
どうせ変になるならリファクタリング機能を使わずにgrepで全置換してしま
えば、最後の行の心配は要らないし、リファクタリング機能使わずに、
人間が内容を理解して置換する方がましにかも知れない。
>>99
#if は無視して、今現在の正しい宣言・定義場所が分かるだけでも助かる。
|
- 【最速へ】LowLevelVirtualMachine【LLVM】
861 ：デフォルトの名無しさん[sage]：2014/09/06(土) 09:27:16.45 ID:Qjz0oFL7 - FLTKを、cygwin-gcc, cygwin-mingw32, msys-mingw32, VC++, clang++
でビルドして試してみた。
このうち、ファイルサイズが最も小さく出来たのはVC++。速度優先に最適化
した場合でさえ、他よりだいぶ小さく出来た。サイズ優先最適化すると
もっと小さくなる。
clang++は、llvmを使っていると思って期待したが、結果は、
多くのexampleにおいて、mingw32のgccより数%大きい。
また、コンパイル速度（コンパイル作業に必要な時間）もVC++が圧倒的に
速い結果となった。gccの4〜5倍程度速い。clang++は、gccと同程度の
コンパイル速度だったと思う。
ただし、clang++に関しては、llvmの最適化ツールを使えばもっとサイズ
ダウンできる可能性はあるが、まだ試してない。
|
- 【最速へ】LowLevelVirtualMachine【LLVM】
864 ：デフォルトの名無しさん[sage]：2014/09/06(土) 13:27:21.67 ID:Qjz0oFL7 - >>862
objdumpで確認してみたけど大丈夫だった。
今回、バイナリのサイズ比較に用いたのは、FLTKのexamplesの中にある
menubar-add.cppをコンパイルしてexeにしたもので、FLTKは全て静的リンクした。
1. VC++ : 自分でworkspaceとprojectを作成。サイズ優先最適化 --> 196,608 バイト
# msvcrt.dll などは全くリンクしていない。
2. cygwinのmingw32-g++ : mingw32-g++ -Os --> exe --> 288,768 バイト
# msvcrt.dll を動的リンクしている。
# cygwin1.dll などはリンクしていない。
3. msys+clang : clang++ -Os --> o --> clang++ --> exe --> 296,960 バイト
# msvcrt.dll, libgcc_s_dw2-1.dll, libstdc++-6.dll を動的リンクしている。
4. msys+clang : clang++ -Os -emit-llvm --> bc --> cygwinのllvm の opt -Os
--> bc --> clang++ でリンク --> strip --> 308,750 バイト
5. msysのmingw32 : g++ -Os --> 284,672 バイト
# msvcrt.dll, libgcc_s_dw2-1.dll, libstdc++-6.dll を動的リンクしている。
上記で、system dll の kernel32.dll や gdi32.dll などはどの場合もリンクしている
ので省略した。
clangは、msysのmingw32と同系統のexeを出力していることが分かる。
というのは、libgcc_s_dw2-1.dll, libstdc++-6.dll がmsysのmingw32独特のもの
だから。一方、cygwinのmingw32 は、これらとは別系統で、この2つのdllはリンクしてない。
cygwin1.dllもリンクしてないので、Win32 nativeアプリと言える。4は強くサイズ最適化
するつもりで試してみたがむしろ最適化前より大きくなった。今のところ原因不明。
|
- 【最速へ】LowLevelVirtualMachine【LLVM】
865 ：デフォルトの名無しさん[sage]：2014/09/06(土) 13:47:57.28 ID:Qjz0oFL7 - >>863
今回、プロジェクトは自分で作成した。
pre compiled header は使わないように設定してビルドした。
その場合でさえVC++はコンパイル速度が速い。
今回使ったVC++は古いもので1Coreでしかビルドできないので
CPUパワーは、50%までにしかなってなかった。
ところが、gccの場合は、make -j2でコンパイルした時でさえ、1core
で頑張っているVC++ に負ける。体感速度で少なくとも2倍。なので、-j2
の効果と合わせると4倍以上遅いことになる。
|
- 【最速へ】LowLevelVirtualMachine【LLVM】
867 ：デフォルトの名無しさん[sage]：2014/09/06(土) 14:30:13.71 ID:Qjz0oFL7 - >>864 の 2. をさらに小さくしようとして、
-ffunction-sections -fdata-sections
と
-Wl,--gc-sections
を使ってみたが、むしろ大きくなった。
上記オプションを付ける前：288,768
上記オプションを付けた後：300,032
|
- 【最速へ】LowLevelVirtualMachine【LLVM】
868 ：デフォルトの名無しさん[sage]：2014/09/06(土) 14:32:50.77 ID:Qjz0oFL7 - >>866
サイズが大きいと、
馬鹿なんじゃないか。技術力が無いんじゃないか。
馬鹿でも時間かければ出来てしまう時代になったんじゃないか。
いろんなライブラリを集めて来て作られているだけなんじゃないか。
などと邪推されますぜ。
|