Man wollte doch mal einen schlanken Browser schaffen und dann das: Firefox platzt aus den Nähten http://www.heise.de/newsticker/meldung/Firefox-platzt-aus-den-Naehten-1393652.html "Nun scheitern jedoch die Builds für 32-Bit-Windows daran, dass der Linker dort mehr als 3 GByte Speicher benötigen würde, was das Betriebssystem nicht zulässt." Was packen die eigentlich alles da rein? Oder liegt es doch eher daran?? http://www.heise.de/ix/news/foren/S-Was-hier-viele-ganz-gerne-uebersehen/forum-217522/msg-21170066/read/ " 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."
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?
Das ist ja der witz an PGO, daß der Kram denn man oft benutzt besonders schnell geht, ohne daß man für jede Maschine einzeln optimieren müsste. Da braucht der Linker dann eben viel Speicher, na und? Unter 64Bit Windows für 32 bit zu kompilieren sollte ja möglich sein. Mit dem Speicherbedarf / der Performance von Mozilla selbst hat das nur wenig zu tun.
@ersa erst lesen - dann motzen http://en.wikipedia.org/wiki/Profile-guided_optimization Das Optimieren braucht viel Speicher, nicht das Optimierte.
> 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 ..
Also für mich bleibt da unklar, ob hier Firefox oder der Microsoft-Compiler schuld ist. Patrick schrieb: > 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. Was hätten sie denn tun sollen?
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."
Hi naja, um Chromium selbst zu kompilieren wird auch ein Rechner mit mindest 4GB, besser 8GB RAM inkl. x64 OS empfohlen. Ist also wohl mehr oder weniger üblich in der "Branche". http://www.chromium.org/developers/how-tos/build-instructions-windows Matthias
Ersa schrieb: > "Nun scheitern jedoch die Builds für 32-Bit-Windows daran, dass der > Linker dort mehr als 3 GByte Speicher benötigen würde, was das > Betriebssystem nicht zulässt." Ohne den Artikel gelesen zu haben, habe ich es noch nicht einmal gemerkt, denn ich habe Anfang lezter Woche die neuste Version von Firefox auf meinem AMD Athlon XP 3000+ mit 4 GByte DDR1 und PAE im Kernel (2.6.34) als Debian Paket gebaut... Ich bin ja einiges von OpenOffice gewohnt, sprich das ich da mal 6-8 Stunden Kompilieren muß, aber Firefox hat meine Maschine für gute 2 1/2 Stunden blokiert. Grüße Michelle
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.
Michelle Konzack schrieb: > Ohne den Artikel gelesen zu haben, habe ich es noch nicht einmal > gemerkt, denn ich habe Anfang lezter Woche die neuste Version > von Firefox auf meinem AMD Athlon XP 3000+ mit 4 GByte DDR1 und > PAE im Kernel (2.6.34) als Debian Paket gebaut... Wobei ein Linux build möglicherweise weit anspruchsloser abläuft als ein Windows build. Kein Schwein benchmarkt Browser in Linux, aber in Windows zählt jedes einzelne Prozent Javascript-Performance.
ff schrieb: > Aber nochmal: FF wird kleiner, wenn man zum Linken über 3Gb braucht. Naja, ob kleiner... Eher schneller als kleiner würde ich sagen, weil manche Optimierung, die sich aus Profiling ergibt, den erzeugten Code eher vergrössert als verkleinert.
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
ff schrieb: > Ich dachte ich bin bei Mikrocontroller.net und nicht .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.
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!
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.
3GB sind ja eh noch harmlos. ;-) http://tech.slashdot.org/story/11/10/24/0016241/android-ics-will-require-16gb-ram-to-compile Gruß, Reinhard
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
Ersa schrieb: > A. K. (prx) schrieb: > 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, ;-)
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.
Ersa schrieb: > 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. Schlecht programmiertes Javascript in den Webseiten, irgendwelche Flash-Zappel-Plugins etc., und massives Caching. Da dürfte einiges zusammenkommen. 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). 12 geöffnete Tabs, kein Videogeraffel, nur normale Arbeit. Gut, macht nichts, die Kiste hat genug Speicher, aber die gelegentlich zu hörenden Behauptungen, daß FF kein Speicherfresser wäre, klingen doch arg unglaubwürdig.
Ersa schrieb: > 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. Denk mal dran, dass der Browser von einem reinen Darstellungs- und Formularwerkzeug längst den Weg zu einer komplexen Anwendungsbasis genommen hat. HTML5 ist ein wesentlicher Schritt dorthin, zu browserbasierenden Anwendungen, die auf Anwenderseite nicht mehr in C/Java compiliert werden. Der Browser als höhere Form dessen, was davor GDI oder X11 war. Insbesondere im Mobilbereich wird das zunehmend eine Rolle spielen. Dazu kommt beispielsweise Integration von 3D-Aspekten. Uvam. Die Welt entwickelt sich weiter, mit dem Browser als weiterem Betriebssystem-Layer zwischen Anwendung und Hardware. Ja, das wird komplexer, grösser. Und neigt dazu, die zur Verfügung stehenden Resourcen jeweils auszunutzen. Ist das schlecht? Ist bei Autos nicht anders: Sind Einparkhilfen und Navis im Auto Ressourcenverschwendung? Heute kann man Dinge, die man vor 30 Jahren nicht konnte, und man nutzt sie eben auch. Klar, da sind auch Unfug und Gimmicks dabei.
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?
Troll schrieb: > 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? Das tut dem "normalen" Anwender nicht weh - Gigabytes bekommt man nachgeworfen - und was nicht im Workingset ist, muß auch nicht im Speicher sein. Auf der anderen Seite hat der Entwickler immer eine Umgebung, die er zumindest weitgehend explorieren kann. Das ist ein Riesenvorteil gegenüber den Zeiten, als man aus Speicherplatzgründen im Fehlerfall erst einen Haufen Zeug zuladen, oder gar dazugenerieren mußte und dann am Ende den Fehler nicht mehr reproduzieren konnte. Und wenn ich sehe, wie lahmarschig FF wird, wenn ein aktiver Firebug läuft, dann wünsche ich mir das Teil definitiv als nativen Code, statt als JavaScript-Zusatz.
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.
Ersa schrieb: > 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. Wenn du deinen eigenen Browser schreibst, kannst du tun und lassen, was du willst ;-) Anderenfalls wird halt gegessen, was auf den Tisch kommt...
Ersa schrieb: > Müsste (denke ich) Es entsteht nämlich allzuleicht der Eindruck "das könne ja nicht so schwer sein" bloß weil etwas inzwischen Standard (wie ein Browser der eine unüberschaubare Menge an Funktionen und Features bietet) geworden ist. Und gerade bei Optimierung gilt: Speicher ist nie genug da, CPU sowieso nicht. Schreib doch einfach mal einen eigenen HTML-Parser, dann eine Renderengine und ein Pluginsystem und optimier das dann darauf ein einem PII200Mhz und 64Mb kompiliert zu werden... aber nur vom schön reden und "müßte könnte würde" hat sich noch nie was geändert.
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^^
Chris schrieb: > 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 Aber auch nicht ohne die Unterstützung größerer Rechner am Boden die die Hauptrechenarbeit übernommen haben. 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. Matthias
Μα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."
gaast schrieb > Hat denn ein AVR genug Speicher, um Programme für sich selbst zu > kompilieren? Sicher. Meine ersten Versionen vom ChipBasic für den Mega644 hatten anstelle der 8 Programme 4 Source Blöcke und 4 Code-Blöcke, was ich aber bis zum ersten Release wieder verworfen habe da der Geschwindigkeitsvorteil den doppelten Speicherbedarf nicht aufgewogen hat. Ein (sicherlich beschränkter) C-Compiler sollte auch machbar sein, hat aber nicht unbedingt sehr viel Sinn, da der AVR Code nur aus dem Flash ausführen kann. Gruß Jörg
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.
Μαtthias W. schrieb: > Aber auch nicht ohne die Unterstützung größerer Rechner am Boden die die > Hauptrechenarbeit übernommen haben Allerdings nicht für Zündungen "hinter dem Mond" da dort keine Kommunikation zur Erde Mölgich war. Dort hat der Computer die Zündung durchgeführt. Meines wissens auch bei der Landung auf dem Mond da die Zeitverzögerung von ~1,3 Sekunden zu viel war. Ich sag nur Fehler 1201 und 1202 ;)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.