アカウント名:
パスワード:
数年前、ちょっとした思いつきで、
printf("fizz\n");printf("buzz\n");
なんてのを一つの*.c に山ほど書いてコンパイルしたことがありますが、約1億行(ファイルサイズ2GB)あたりで限界が来ました(Core i7 、メモリ6GB)。スワップが70GBにもなり、数時間で機器が操作不能になったように記憶します。
この機器ならできそうだけど、できてもあまり意味なさそう。(処理系の隠れたバグをほじくれるかも?)
いにしえのKDEが誇る、有名すぎるビルドスイッチ、『--enable-final』全ての.cppファイルをまとめて、たったひとつの.all_cpp.cppというファイルにしてコンパイルするだけという凶悪なコンパイル時オプションそんな--enable-finalを有効にして、テンプレートてんこもりの巨大なC++ファイルをビルドしたって、3~4GBもあれば楽勝なのにもかかわずprintfでfizzbuzzを1億行ほど繰り返してあるだけのものが70GBのスワップを使い切ったという意味不明さ
こんなしょうもない作り話を考えたバカは勿論そんなことさえ見抜けない、スラドのモデレータのレベルの低さには、もはや絶望を感じざるをえないうそはうそであると見抜ける人でないと(スラドを使うのは)難しい
笑い話にどこまでリアリティを求めるのか?ユーモア(Humour)の語源がヒューマン:人間(Humour)だとする説を用いるなら「お前、人間が小さいな」と。
そんなことさえ見抜けない、スラドのモデレータのレベルの低さには、もはや絶望を感じざるをえない
今更すぎるだろ。
つか大体あんたみたいなのもスラドに期待を持てなくなった原因のひとつだからな。
RAM 8GB SWAP 8GB のPCで試そうと以下のようにしてソースを作ってたら、ターミナルごと落ちました。seqの所でbashが落ちたのかな。
for i in `seq 1 1000000000` ; do echo 'printf("fuzz\n");' >> test.c ; done
とりあえず、落ち着いてゼロの数を数えてみようか。
#3300941です。
巨大ファイルでも楽勝とか言うので、試したかっただけですよ。
1000万行 172MBのソースを作りました。安全のために、シングルユーザーモードで起動してからコンパイルしました。コンパイルオプションはなしです。topコマンドで見ていると、cc1がRAMを7.1GBくらい消費したあたりでスラッシングが激しくなりはじめました。時間がかかりそうなので、1.9GBくらいスワップしたあたりでやめました。
1億行 2GBのソースならありえるのでは。少なくとも、3~4GBで楽勝って事はないですね。
debian 9.2です。
その--enable-finalとやらが最終的に生成したソースは何行になったの?話はそれからだ。
ウソと確定できるかっつーより、コンパイラにバグがあったんじゃねーの?という方を疑ってみたいお年頃。(何を使ったとか書いてないし
$ cat foo.rb
#!/usr/bin/env rubylast = ARGV[0].to_i + 1
print <<MAIN#include<stdio.h>int main () {MAIN
last.times do |x| if x == 0 then print "" elsif x % 15 === 0 then print <<-FIZZBUZZ printf("fuzzbuzz\\n"); FIZZBUZZ elsif x % 5 === 0 then print <<-
一ファイルに大量の関数があるのと、すさまじく巨大な関数一個だけあるのとを、一緒にするのっておかしくないですかね
> こんなしょうもない作り話を考えたバカは勿論> そんなことさえ見抜けない、スラドのモデレータのレベルの低さには、もはや絶望を感じざるをえない> うそはうそであると見抜ける人でないと(スラドを使うのは)難しい
自分自身に絶望して下さい。レベルが低いのはあなたです。
・最適化は可能だが文字列リテラルが山ほど・1関数がバカみたいに長大・普通のプログラムならソース全連結しても2GBもいかない・出力されるプログラムサイズもバカみたいに長大(と予測できる)・最適化のアルゴリズムが即座にメモリ消費を縮小できる構造でない限り最適化も困難妥当な結果。
軽くて早いで有名なTCCではどうか、と思ったがTCCも1関数にぶっ込まれると辛いらしい……データ構造があんまりでかい関数・大量リテラルに向いてないんだろうなコレは。処理速度が加速度的に低下してて、9時間でプロセスのデータ読み込み量が36MBしかない。そのあたりでメモリ消費が512MBだったからソースからメモリへの倍率はその時点で14.2倍。元米のコンパイラのメモリ効率がTCCより悪いないしは後の行程で増えるとすれば35倍位行ってもおかしくはない。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
OSのコンパイルをしてみるとか (スコア:1)
128GBあれば、快適にOSをコンパイルできそう。
Re:OSのコンパイルをしてみるとか (スコア:3, おもしろおかしい)
数年前、ちょっとした思いつきで、
printf("fizz\n");
printf("buzz\n");
なんてのを一つの*.c に山ほど書いてコンパイルしたことがありますが、約1億行(ファイルサイズ2GB)あたりで限界が来ました(Core i7 、メモリ6GB)。
スワップが70GBにもなり、数時間で機器が操作不能になったように記憶します。
この機器ならできそうだけど、できてもあまり意味なさそう。
(処理系の隠れたバグをほじくれるかも?)
なんでこんな嘘コメがスコア:3なの? (スコア:0, おもしろおかしい)
いにしえのKDEが誇る、有名すぎるビルドスイッチ、『--enable-final』
全ての.cppファイルをまとめて、たったひとつの.all_cpp.cppというファイルにしてコンパイルするだけという凶悪なコンパイル時オプション
そんな--enable-finalを有効にして、テンプレートてんこもりの巨大なC++ファイルをビルドしたって、3~4GBもあれば楽勝なのにもかかわず
printfでfizzbuzzを1億行ほど繰り返してあるだけのものが70GBのスワップを使い切ったという意味不明さ
こんなしょうもない作り話を考えたバカは勿論
そんなことさえ見抜けない、スラドのモデレータのレベルの低さには、もはや絶望を感じざるをえない
うそはうそであると見抜ける人でないと(スラドを使うのは)難しい
Re: (スコア:0)
笑い話にどこまでリアリティを求めるのか?
ユーモア(Humour)の語源がヒューマン:人間(Humour)だとする説を用いるなら「お前、人間が小さいな」と。
Re: (スコア:0)
そんなことさえ見抜けない、スラドのモデレータのレベルの低さには、もはや絶望を感じざるをえない
今更すぎるだろ。
つか大体あんたみたいなのもスラドに期待を持てなくなった原因のひとつだからな。
Re: (スコア:0)
RAM 8GB SWAP 8GB のPCで試そうと以下のようにしてソースを作ってたら、
ターミナルごと落ちました。
seqの所でbashが落ちたのかな。
for i in `seq 1 1000000000` ; do echo 'printf("fuzz\n");' >> test.c ; done
Re: (スコア:0)
とりあえず、落ち着いてゼロの数を数えてみようか。
Re: (スコア:0)
#3300941です。
巨大ファイルでも楽勝とか言うので、試したかっただけですよ。
1000万行 172MBのソースを作りました。
安全のために、シングルユーザーモードで起動してからコンパイルしました。
コンパイルオプションはなしです。
topコマンドで見ていると、cc1がRAMを7.1GBくらい消費したあたりでスラッシングが激しくなりはじめました。
時間がかかりそうなので、1.9GBくらいスワップしたあたりでやめました。
1億行 2GBのソースならありえるのでは。
少なくとも、3~4GBで楽勝って事はないですね。
debian 9.2です。
Re: (スコア:0)
その--enable-finalとやらが最終的に生成したソースは何行になったの?話はそれからだ。
Re: (スコア:0)
ウソと確定できるかっつーより、コンパイラにバグがあったんじゃねーの?という方を疑ってみたいお年頃。(何を使ったとか書いてないし
Re:再確認してみたよ。 (スコア:0)
$ cat foo.rb
#!/usr/bin/env ruby
last = ARGV[0].to_i + 1
print <<MAIN
#include<stdio.h>
int main () {
MAIN
last.times do |x|
if x == 0 then
print ""
elsif x % 15 === 0 then
print <<-FIZZBUZZ
printf("fuzzbuzz\\n");
FIZZBUZZ
elsif x % 5 === 0 then
print <<-
Re: (スコア:0)
一ファイルに大量の関数があるのと、すさまじく巨大な関数一個だけあるのとを、一緒にするのっておかしくないですかね
Re: (スコア:0)
> こんなしょうもない作り話を考えたバカは勿論
> そんなことさえ見抜けない、スラドのモデレータのレベルの低さには、もはや絶望を感じざるをえない
> うそはうそであると見抜ける人でないと(スラドを使うのは)難しい
自分自身に絶望して下さい。
レベルが低いのはあなたです。
Re: (スコア:0)
・最適化は可能だが文字列リテラルが山ほど
・1関数がバカみたいに長大
・普通のプログラムならソース全連結しても2GBもいかない
・出力されるプログラムサイズもバカみたいに長大(と予測できる)
・最適化のアルゴリズムが即座にメモリ消費を縮小できる構造でない限り最適化も困難
妥当な結果。
軽くて早いで有名なTCCではどうか、と思ったがTCCも1関数にぶっ込まれると辛いらしい……
データ構造があんまりでかい関数・大量リテラルに向いてないんだろうなコレは。
処理速度が加速度的に低下してて、9時間でプロセスのデータ読み込み量が36MBしかない。
そのあたりでメモリ消費が512MBだったからソースからメモリへの倍率はその時点で14.2倍。
元米のコンパイラのメモリ効率がTCCより悪いないしは後の行程で増えるとすれば35倍位行ってもおかしくはない。