Wahnsinn! 3 GB reicht nicht um FF zu compilieren?

Nein, es liegt - wie im Artikel steht, der nebenbei erwähnt nicht 
wirklich toll geschrieben ist und damit das Ganze etwas unschön 
darstellt - einzig am PGO.

Details dazu siehe Artikel; ohne PGO compiliert und linkt das Ganze 
offenbar nach wie vor, bloß der zweite Linkerlauf frisst offenbar 
Einiges.

Was man den Mozilla-Entwicklern allerdings vorwerfen muss, ist, dass 
früher bereits einmal die 2-GB-Schwelle erreicht und diese dann 
lediglich mittels Hack umschifft wurde - ohne weitere Konsequenzen und 
offenbar ohne weiter darüber nachzu- oder gar in die Zukunft zu denken.
Bei jedem ernstzunehmenden Entwickler sollten die Alarmglocken 
schrillen, wenn ein Ressourcenlimit erreicht wird; unabhängig davon, ob 
es mittels Hack umgangen werden kann. Danach einfach weiterzumachen wie 
zuvor ist schon ein starkes Stück.

Tut mir leid, aber PGO sagt mir erst mal gar nichts. Noch dazu klingt 
das für mich wie ein Hohn "Profile-Guided"-Optimierung". Optimierung ist 
in diesem Zusammenhang wohl eher ein Witz bzw. was soll an derart viel 
Speicherbedarf eigenlich "optimiert" sein?

> Da braucht der Linker dann eben viel Speicher, na und?
> Unter 64Bit Windows für 32 bit zu kompilieren sollte ja möglich sein.

Klingt mehr nach einem Workaround als nach einer Lösung für das 
eigentliche Problem, etwa so wie

dein Rechner ist halt zu langsam für diese Software, rüste einfach auf

Nochmal, wozu braucht man derart viel Speicher beim übersetzen für etwas 
was nachher nicht mal 20 MByte groß ist???

> @ersa erst lesen - dann motzen
> Das Optimieren braucht viel Speicher, nicht das Optimierte.

Und funktioniert nicht mehr wie man ja gerade liest. Eigentor würde ich 
sagen.

Mal abgesehen davon, schlanker Browser war mal der Anspruch an den FF. 
Davon entfernt er sich auch immer mehr ..

Das Problem scheint wohl bereits bekannt

https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization

"Warning: Linking a PGO build is known to exhaust the 32 bit address 
space on Win32. To work around this either use a 64 bit compiler or use 
the /3GB boottime switch to give the linker more address space. See Bug 
543034 for details."

Gerade Programme, die schlank werden sollen, profitieren von den 
Compilern/Linkern, die ALLES im Haupspeicher halten, um dann über alles 
optimieren zu können.
Dazu muß aber eben ALLES in den Adressraum, nicht den Hauptspeicher, 
passen.
Und dieser Adressraum ist eben unter NTx/32bit nur 2 bzw. 3Gb. Leute, 
meine erste Festplatte, in harten 2 Monate Platinen-Testen erarbeitet, 
hatte 32MegaByte.
Aber nochmal: FF wird kleiner, wenn man zum Linken über 3Gb braucht.

noch mehr Wahnsinn:
ATTiny24 braucht 32bit Maschine (NT/Linux) um C-Code zu verdauen (via 
GCC).
Ich vermute mal, dass auch die Vertigungsstrassen für den ATTiny24 
MEHRERE Meter lang sind.

Ich dachte ich bin bei Mikrocontroller.net und nicht .BILD

BTW, schreibe grad auf FF 11 (nightly) 64Bit auf Windows7 64bit 
(Maschine von der Arbeit):
Firefox, 8 offene Tabs, viele bunte Bilder: Working Set 282MB
nix mit GigaByte!

A. K. (prx) schrieb:

ff schrieb:

>> Ich dachte ich bin bei Mikrocontroller.net und nicht .BILD

"Firefox, 8 offene Tabs, viele bunte Bilder: Working Set 282MB
nix mit GigaByte!"

Das war auch nicht besser als "Bild".

> Siehste! Hast du wieder was dazu gelernt. Der Unterschied ist eher
> gradueller Natur, kein prinzipieller. Der Heise-Ticker und Telepolis
> sind ja auch nicht selten etwas effektheischend, insbesondere Freitags.

Und was ist jetzt daran "effektheischend"? Ich stamme halt noch aus 
einer Zeit, als man per himem.sys für jede paar kByte dankbar war, die 
danach mehr als Hauptspeicher zur Verfügung hatte. Euch Jungvolk kann 
anscheinend nichts dergleichen mehr Fragezeichen auf die Stirn treiben, 
was Gigabyte-weise Hauptspeicher schluckt und sogar den Compiler auf dem 
Zielsystem überfordert. Dabei könnte man sich doch mal zu recht fragen, 
muss das alles wirklich so sein? Hier sind Poster tatsächlich drauf 
stolz, wenn eine Compilierung "nur" 2 1/2 Stunden dauert und das bei 
Rechnern die 1000-fach schneller sind als zur damaligen Zeit. Man 
gewinnt den Eindruck die Software hätte allseits aus "Visual Basic" 
umgestellt, so träge wird das zunehmens. Die Compilierung des 
Linux-Kernel hat zu meinen Anfängen mal ähnlich lange gedauert. Da waren 
die Rechner aber noch mit ein paar Megabyte (NICHT GIGABYTE) 
Hauptspeicher bestückt und Megahertz war der Takt. Ich wette ein Teil 
dieser zunehmenden Bloatware verdankt man der eierlegenden 
Wollmilchsau-Anforderung names "plattformunabhängigkeit" und eine zweite 
Wette wäre, wenn der Browser komplett nur unter Windows mit C# 
entwickelt würde, wäre er auch nicht langsamer und auch nicht fetter als 
er das ohnehin bereits ist (aber das Bashing wäre ähnlich wie das zu 
diesem Thread hier). Dazu beachte man den hier von einigen wohl bewusst 
überlesenen Kommentar

" FF ist eine Plattform übergreifende Software und kann daher nur
bedingt auf einzelne Plattformen optimiert sein. Das bedingt auch,
dass z. B. die Render-Engine nicht auf jede einzelne Plattform
angepasst ist, sondern für jede Plattform zusätzlich noch eine
Zwischenschicht existiert, die die Anweisungen der Render-Engine für
die jeweilige Plattform übersetzt.
uvm."

Vielleicht sollte man mal ein Compilat anbieten, das für Jedermann 
einfach per Klickauswahl konfigurierbar ist, um selber all den 
überflüssigen Kram aus dem Browser zu entfernen, den der Einzelne oft 
gar nicht braucht. Beim Linux-Kernel ging das damals schließlich auch. 
Damit (UND NUR DAMIT) war er schlank, rank und schnell zu bekommen und 
nicht mit PGO "Optimierungen", die selber erst mal optimiert werden 
sollten, wie der Artikel andeutet, aber auf der anderen Seite nur den 
Status Quo der Bloatware festigen.

Just my 2 Cents

Rufus Τ. Firefly (rufus) (Moderator) schrieb:

ff schrieb:
>> Firefox, 8 offene Tabs, viele bunte Bilder: Working Set 282MB
>> nix mit GigaByte!

> Du hast offensichtlich nicht verstanden, worum es geht. Nicht um den
> Speicherbedarf des laufenden Programmes, sondern um den Speicherbedarf
> des Compilers/Linkers beim Erzeugen des Programmes, also etwas, das der
> typische Anwender nie selbst zu Gesicht bekommen wird.

Wobei man sich auch mal Gedanken machen könnte, wie durch ein paar 
Zeilen ASCII-Text pro Seite und ein paar kleine Bildchen eigentlich 282 
MByte zustande kommen.

Aber es ist halt wie mit der ausufernden Geldmenge im Euro-Raum. Da wo 
Ressourcen vom Himmel fallen steckt die Verschwendung implizit im System 
und keine Sau geht mehr sorgsam damit um.

Das Problem ist doch auch, dass der Browser immer weiter mit Funktionen 
überladen wird. Bis vor ein paar Versionen gabs nur die Fehlerkonsole 
und jetzt bei aktuell 8.0 haben wir: Web Console, Inspect und Scratchpad 
dazu. Welcher normale Benutzer braucht Entwicklerprogramme im Browser?

Ersa schrieb:
>> Da braucht der Linker dann eben viel Speicher, na und?
>> Unter 64Bit Windows für 32 bit zu kompilieren sollte ja möglich sein.
>
> Klingt mehr nach einem Workaround als nach einer Lösung für das
> eigentliche Problem, etwa so wie

???

> dein Rechner ist halt zu langsam für diese Software, rüste einfach auf

Aahhh, ein Spezialexperte, der noch SAP R3 in 64 KB laufen lassen 
könnte... ;-)

> Nochmal, wozu braucht man derart viel Speicher beim übersetzen für etwas
> was nachher nicht mal 20 MByte groß ist???

Siehe Theorie Compilerbau. Du willst die anfallenden Daten im RAM und 
nicht auf Swap haben. Wirklich.

Willkommen in der wirklichen Welt, wo der Ressourcenbedarf nicht von 
Wunschdenken sondern von technischen Erfordernissen - und zugegeben 
schlampigen Entwicklern - bestimmt wird.

Haben die Spiele-Entwickler übrigens schon vor Jahren angesagt dass für 
ihre APIs und IDEs 64 Bit Pflicht werden.

A. K. (prx) schrieb:
> Denk mal dran, dass der Browser von einem reinen Darstellungs- und
> Formularwerkzeug längst den Weg zu einer komplexen Anwendungsbasis
> genommen hat. ...
> Ja, das wird komplexer, grösser. Und neigt dazu, die zur Verfügung
> stehenden Resourcen jeweils auszunutzen. Ist das schlecht?

Nur möchte ich nicht, wenn gerade mal EIN Programm (= Browser) mir 
bereits so einen Batzen an Ressourcen verschlendert, nur um ein paar 
lausige Webseiten darzustellen. Es könnte ja auch mir überlassen werden, 
ob ich beispielsweise eine 3D Anzeige von Inhalten wünsche oder nicht. 
Wäre das schlecht? Ich fürchte nur auch ohne 3D wird das Korpus Delikti 
(egal ob IE, FF, Gurgel oder sonstwas) zum Schwarzen Loch für alles was 
Arbeitsspeicher, aber auch Prozessorlast heißt. Da gab es doch mal ein 
Betriebssystem namens BeOS, das erstaunlich schlank war und sehr fix. Es 
ginge bestimmt auch anders, wenn man es nur wollte. Da aber RAM 
preismäßig zum RAMsch (bei hoher Qualität) "verkommen" ist, geht keiner 
mehr sparsam damit um. Wobei das untertrieben ist, wenn nicht mal mehr 
ein 32-bit OS genügt Speicher aufweist (jedenfalls besteht die Gefahr 
laut Artikel), um damit 32-bit Software zu übersetzen. Verstehe mich 
bitte nicht falsch, ich will daraus jetzt kein Fiasko stilisieren, ich 
war einfach nur überrascht bei dieser Heise News. Ich bin Fan von C#, 
was bekanntermaßen auch ein  paar Ressorcen frisst ;). Aber so wie es 
hier scheint spielt es wohl keine Rolle welche Programmiersprache 
eingesetzt wird. Die Browser sind mittlerweile alle samt Bloatware 
(geworden) wie Rufus' eindrucksvoll in seinem Posting zum Ausdruck 
bringt und wir müssen damit leben bis ein .. kluger Ritter (aus Fernost) 
sich erbarmt und all seine Man Power (und die seiner Freunde) 
investiert, einen tollen schlanken Browser baut und der Konkurrenz der 
Fürchten bei bringt (wird aber wohl nicht geschehen, da ja kein Bedarf 
;)).

Zu meiner Schande muss ich allerdings gestehen, auch ich rufe gerne die 
eingebetteten Videos von David L. Jones' Webseite im Browser auf 
(youtube sowieso) und auch gerne mal eines der Videos abgelaufener 
Sendungen im ÖR (blödes flash). Asche auf mein Haupt. ;) Ob diese Videos 
jetzt den Bock fett machen? Keine Ahnung! Müsste (denke ich) nicht 
zwangsläufig sein. Zumal auch nur Textlastige Webseiten bereits 
ordentlich MBytes ziehen.

Naja.

Rufus Τ. Firefly schrieb:
> Und 282 MByte ist für FF noch wenig, der hier, den ich
> gerade nutze, braucht etwa 700 MByte physikalischen, 500 MByte
> virtuellen und 400 MByte "privaten" Speicher (so zeigt's der OS
> X-Taskmanager 'Aktivitätsanzeige' an)

und Du meinst das sind dann in Summe 1,6GB, oder?

Rufus Τ. Firefly schrieb:
> Du hast offensichtlich nicht verstanden, worum es geht. Nicht um den
> Speicherbedarf des laufenden Programmes, sondern um den Speicherbedarf
> des Compilers/Linkers beim Erzeugen des Programmes, also etwas, das der
> typische Anwender nie selbst zu Gesicht bekommen wird.

hättest Du mal meinen ersten Post gelesen, dann wüsstest Du, daß ich den 
Unterschied kenne. Ich wollte ja gerade den Unterschied zwischen FF 
produzieren und FF benutzen klarmachen.

Ersa schrieb:
> Wobei das untertrieben ist, wenn nicht mal mehr
> ein 32-bit OS genügt Speicher aufweist (jedenfalls besteht die Gefahr
> laut Artikel), um damit 32-bit Software zu übersetzen

Hat denn ein AVR genug Speicher, um Programme für sich selbst zu 
kompilieren?

gaast schrieb:
> Hat denn ein AVR genug Speicher, um Programme für sich selbst zu
> kompilieren?

falls nicht müssen wir uns eben mal heftig empören.

Das darf ja wohl nicht wahr sein, dass bisher keiner einen GCC 
gescrieben hat, der sich mit 4K zufrieden gibt.

Bekommen halt nix hin, die Amateure von der FSF  :-)

Apollo 11

Mal ein paar Zitate:

Der Rechner hatte Abmessungen von 61 × 32 × 15 cm. Er wog 31.7 kg und 
verbrauchte 70 Watt Strom bei 28 V Spannung. Im Standby Modus waren es 
noch 15 Watt. Dazu kamen die hier abgebildeten Bedienungseinheiten die 
je 20 × 20 × 17.5 cm groß waren und 8 kg wogen. Zwei davon waren im CM 
und eines im LM.

Speicher (pro Rechner): 16 KWorte = 16.384 Worte = 262.144 Bit.
Geschwindigkeit: 0,06 MIPS (zum Vergleich Athlon 64 8.400 MIPS bei 
2,8GHz)
Quelle: http://www.bernd-leitenberger.de/computer-raumfahrt1.shtml

und damit sind die Amis auf dem Mond gelandet sowas reicht heutzutage 
nicht mal mehr um sich ins Internet einwählen zu können :D

mfg

Chris

Ich glaub das hat damals schon nicht fürs Internet gereicht^^

Μαtthias W. schrieb:
> Und die benötigte Rechenleistung für
> die Navigation im Erde-Mond System ist auch nicht so komplex als das
> man das nicht mit den damaligen Rechnern lösen konnte. Einen einzelnen
> Buchstaben aus einer Vektordarstellung ordentlich auf einem Pixelschirm
> darstellen dürfte ein mehrfaches an Rechenoperationen benötigen.

Erinnert mich an die Szene in Simpsons S5 EP15, wo Homer gerade ins 
Weltall startet.

"Wie geht es der Crew?" -
"Keine Ahnung, diese ganzen Computer dienen nur der Erfassung der 
Einschaltsquoten."

Eigentlich dachte ich, es wäre selbstverständlich, dass ich von einem 
optimierenden C-Compiler sprach, schließlich geht es hier um genau 
diesen ressourcenfressenden Prozess.