Android 4.0: Starke Workstation zum Kompilieren

Die neue Version von Googles Smartphone-Betriebssystem Android 4.0 "Ice Cream Sandwich" ist deutlich umfangreicher als der Vorgänger. Dies macht sich besonders bemerkbar, wenn man den kompletten Quellcode einmal selbst kompilieren will, so ein ... mehr... Android, Android 4.0, Ice Cream Sandwich Bildquelle: Google Android, Android 4.0, Ice Cream Sandwich Android, Android 4.0, Ice Cream Sandwich Google

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Was wird dabei eigentlich gemacht?
 
@emantsol: Der Quellcode der Entwicklung wird in Maschinensprache uebersetzt. Du kannst ja mit C++ Code deinem PC nicht sagen was er machen soll. Er muss zuerst uebersetzt werden. Bei Java Anwendungen ist sowas nicht noetig da er in der laufzeit von der Java Virtual Maschine uebersetzt wird
 
@-adrian-: Dafür ist Java auch um welten langsamer und Speicherintensiver als C++ oder Assembler Code...
 
@skyjagger: Das ist ein weit verbreiteter Irrglaube. Wenn man in Java effizient programmiert, ist die Performance nur geringfügig schlechter als z.B. in C++.
 
@Compadrito: stimme da vollkommen zu. in manchen dingen ist java sogar schneller. es kommt immer darauf an, was man haben will. ich hätte in c zum Beispiel nicht so viel lust eine gui zu erstellen wie in java bzw ist der aufwand ungleich größer bei c.
 
@Compadrito: türlich, es ist erwiesen dass ein programm wie z.b. minecraft in c etwa 8x resourcen sparender wäre, der ram verbrauch der java VM ist einfach gigantisch gegenüber einem nativen programm in c oder assembler etc.
 
@Agassiz: Gib mal nen Link zu nem Codebeispiel wo Java schneller ist als c++
 
@iP4-User: Also zuerst ist nicht Java schneller als C oder C++ oder umgekehrt, weil das alles nur Programmiersprachen sind und die können nicht einfach schnell oder langsam sein. Es liegt am Compiler (und natürlich am Code) und es gibt viele verschiedene Compiler! Selbst C++ ist bei verschiedenen Compilern unterschiedlich schnell. C ist am nähsten an Assembler dran und daher extrem schnell. Bei Java schaut sich der Compiler den Code an und analysiert, wo wie viel Zeit benötigt wird, das was langsam ist wird optimiert, die schnellen Sachen passieren zur Laufzeit. C++ Compiler schätzen dies nur ganz grob ab (ja es gibt auch Profiler etc., die nutzen aber nur wenige Leute). Also kann es passieren, dass eine Funktion die nur ein paar Mal ausgeführt wird ohne Ende optimiert wird, eine die aber 1.000 Mal ausgeführt wird, wird nur wenig optimiert. Außerdem bringt Java eine Standartbibliothek mit, die C++ richtig alt aussehen lässt (und C noch älter), diese Funktionen sind in der Regel schon stark optimiert. Bei C/C++ muss man das alles erst selber schreiben und ob der eigene Code dann wirklich besser ist, lasse ich mal jeden für sich selbst entscheiden.
Natürlich kann man sich jetzt fragen warum Java zur Laufzeit dann nicht immer schneller ist und hier spielt der Komfort wieder eine Rolle.. Bei C/C++ muss man den Speicher selber verwalten und bei Java übernimmt dies der Garbage Collector. Der Garbage Collector arbeitet aber nur selten, um CPU-Zeit zu sparen (da die anderswo eher gebraucht wird) und lagert fleißig in den Speicher aus. Der wird aber voll (und lagert dann weiter aus) und hier wird es langsam! Diese Trollsprüche von wegen Java sei generell langsam, treffen im Allgemeinen also nicht zu! Man muss sich auch mal überlegen, dass Java viel schneller als PHP, JavaScript etc. ist und die nutzt die halbe Welt ohne zu trollen.
 
@2-HOT-4-TV: Der Text ist ja noch halbwegs OK, gerade den GC und JIT müsste man viel mehr beschreiben...GC kann man z.B. anstossen. Weiter ist Java keine hoch optimierte Sprache, auch nicht die Bibliothek, hier ist C++ einiges weiter. Gerade da Java viele Methoden besitzt welche mehrere Aufgaben übernehmen sinkt deren Effizienz. Aber der grösste Witz ist ja wohl am Ende die Aussage dass Java schneller als PHP, Javascript etc. sei...nur schon php und Javascript in einen Kontext zu bringen ist bescheuert...
 
@2-HOT-4-TV: re11 bezog sich auf re6: " in manchen dingen ist java sogar schneller." Wenn Java schneller ist als C dann liegts einfach am schlechten C-Code. Nichttriviale Berechnungen sind bei ausreichenden Fähigkeiten des Programmierers in C eigentlich immer (zumindest messbar) schneller als in Java.
 
@2-HOT-4-TV: Wer keine Lust hat GUI's in C++ zu schreiben, was auch wirklich niemand machen sollte, schaut sich einfach mal QT an. Wem die STL nicht ausreicht, was leicht nachzuvollziehen ist, besorgt sich die Boost Bibliothek. Die ist ausgezeichnet, deckt alles ab von Asynchronen Netzwerk Verbindungen bis hin zu Threading, und Kinderleicht wenn man template Fehler entziffern kann ;P Ansonsten wäre da noch SFML Bibliothek zu nennen, die deckt wohl beide der genannten Bereiche ab, wenn auch nicht so umfangreich wie Boost. OpenCV wenn man gerne mit Kameras experimentiert. Ach es gibt etliche Bibliotheken für C++, man muss nur wollen. Und das C schneller ist als C++ halte ich für ein Gerücht. Ich programmiere viel für ARM mikrocontroller und schaue mir immer den produzierten Assembler an. Durch Objektorientierung spart man sich oft viel bei den Funktionsaufrufen für umfangreiche Objekte, da nur der this pointer und nicht 4-5 Parameter übergeben werden müssen. Und wer jetzt sagt das man Die Parameter ja in eine struct schreiben könnte und nur den Pointer übergibt, der hat den Schuss nicht gehört.Wenn man C++ Bedacht einsetzt wird das keineswegs langsamer wie reines C. Wenn ich unbedingt pfuschen will und irgendwas auf was anderes Casten will und am besten quer in die Objekte schreibe, dann setzt ich halt alles public, nichts ist const und so weiter. Es gibt aber keinen Grund auf diese Fehlerfindungs Instanz zu verzichten.
 
@flailers: Ja das wichtigste ist bei jeder Programmiersprache der eigene Code. Wenn man guten C Code schreibt wird der immer schneller sein als C++ oder anderen Sprachen, weil es eigentlich nur ein abstrahiertes Assembler ist. Nur wie schon erwähnt, sind zwischen den meisten Sprachen keine Welten und daher liegts im Endeffekt hauptsächlich am eigenen Code.. Wenn man sich z.B. mal überlegt, dass Strings eigentlich unveränderbar sind und deshalb intern bei jedem "+"-Operator ein neuer String angelegt werden muss. Kann man sich schon vorstellen, was für enorme Geschwindigkeitsvorteile z.B. ein StringBuffer in einer größeren Schleifen bringen kann.
 
@skyjagger: Bei Java ist der ausgeführte Code in dem meisten Fällen nur unwesentlich langsamer(wenn überhaupt) als z.B. bei C++. Dafür kommt am Anfang aber noch das Starten der Java-VM hinzu (was bei Android Apps z.B. entfällt).
 
@-adrian-: Java Anwendungen müssen sehr wohl kompeliert werden
 
@okeanos: Aber erst zur Laufzeit. Das nicht noetig hat sich dabei auf die "zuerst uebersetzt werden" bezogen
 
@-adrian-: bei Java Code ist das sehr wohl nötig: Java wird vom Java-Compiler in Java-Bytecode übersetzt. Dieser wird dann später, wenn das Programm ausgeführt werden soll noch einmal (in Maschinencode) übersetzt; wenn die Quellen nicht kompiliert werdene müssen, so nennt sich das Interpretieren, wie es zum Beispiel von Ruby, Python oder Javascript gemacht wird...
 
@emantsol: Schau bei Wikipedia unter "Compiler" nach.
 
"Die Quellcodes allein sind bereits ein 6GB großes Paket" - 6GB Quellcodes??? Also selbst wenn die einen 2 Byte Unicode nutzen, wären das 3,25 Mrd. Zeichen! Die Bibel hat ca. 4,4 Mio. Zeichen. Also sind die Quellcodes von Android ca. 740 mal so umfangreich wie die Bibel! Nee, das glaub ich nicht. Dann würde es mich nicht wundern wenn Google ein Wartungsproblem mit Android bekommt.
 
@Givarus: Das kann tatsächlich nicht sein. Da wurde irgendwas mit eingerechnet, was nicht dazu gehört...
 
@DataLohr: Trotzdem werden dass niemals 6GB mit Ressourcen...
 
@Viceinator: naja gut, nächste überlegung wäre ob die vll tools und datenbanken usw. mit eingerechnet haben, die für die erstellung des eigentlichen quellcodes genutz werden. da kann ja auch schonmal was zusammen kommen.
 
@DataLohr: Ist ja Open Source - da kann man es sich ja einfach runterladen und anschauen, oder :P
 
@DataLohr: Was dann aber eigentlich nichts mehr mit Source zu tun hat...
 
@-adrian-: ok, tu es und berichte
 
@Viceinator: stimmt, aber statistiker nehmen das nich so genau, denen ist alles recht um für werbung irgendwas darzustellen oder zu beweisen.
 
@DataLohr: Ich finde VIEL Quellcodes sind alles andere als Werbung für ein System. Da habe ich gerade zufällig ein sehr schönes Zitat von Bill Gates gefunden: „Den Programmierfortschritt durch die Anzahl der Programmzeilen zu messen, ist wie wenn man den Fortschritt beim Bau eines Flugzeugs an dessen Gewicht misst.“ Gute Programme zeichnen sich nicht durch möglichst viel Coding aus, sondern durch möglichst schlankes Coding um das Ziel zu erreichen...
 
@Givarus: womit er auch absolut recht hat, aber du weißt auch wies bei amd damals war. die leute haben amd gekauft weil sie meinten der 3300+ wäre genauso schnell wie ein pentium der mindestens 3300 mhz haben müsste, den gabs natürlich nich. große zahlen machen eindruck und die meisten leute wissen das nicht richtig zu interpretieren.
 
@Givarus: So ein Quatsch! Ob ein Quellcode 10000 oder 100 Zeilen hat, sagt rein gar nichts über die Qualität aus. Wenn man z.B. alle Kommentare entfernt, kann der Quellcode deutlich kleiner werden hat aber immer noch dieselbe Funktion, nur halt keine Kommentare mehr (was eher schlecht ist). Und wenn man die Hälfte der Funktionen weglässt, wird der Quelltext auch kürzer. Man kann übrigens auch alle Leerzeichen und dergleichen entfernen, dann wird er noch kleiner aber ganz sicher nicht besser ;)
 
@dodnet: Da hast du vollkommen Recht! Man muss ja auch beachten, was für die jeweilige Anwendung BESSER ist. Wenn eine Software sehr sicher und stabil laufen muss, dann wird oft viel mehr Quellcode von nöten sein der z.B. für Fehlerbehandlungen/Abfangen von Fehlern etc. zuständig ist. Bei Anwendungen die auf Geschwindigkeit ausgelegt sein müssen ist es erst recht nicht zu sagen ob mehr oder weniger Quellcode besser sind. Manche Algorithmen sind vielleicht umfangreicher vom Quellcode aber vom Prozessor vielleicht schneller zu bewältigen als eine Funktion die dieselbe Aufgabe mit weniger Quellcode behandelt. Da muss man immer abwägen
 
@Viceinator: Der sicherste Code, den es gibt, hat möglichst wenige Zeilen Code. Hier wäre wohl die Minix-Präsentatino von Andrew Tanenbaum sehr zu empfehlen (~1h auf YouTube). http://www.youtube.com/watch?v=bx3KuE7UjGA
 
@3-R4Z0R: Da muss man aber auch wieder unterscheiden. Je weniger Code umso weniger Fehler macht man natürlich. Aber wenn man bestimmte Dinge nicht abfängt bringt einem dass herzlich wenig! Und um Dinge abzufangen benötigt man Quellcode!
 
@Viceinator: Deshalb sollte man ein Konzept haben bei dem man im Prinzip nichts abzufangen bräuchte.
 
@3-R4Z0R: Was unmöglich ist!
 
@Viceinator: Deshalb sollte man ein Konzept haben bei dem man im Prinzip nichts abzufangen bräuchte.
 
@Givarus: vergess nich das da auch audi und bild dateien dabei sind und ich denk mal um die statistik zu verschönern hat man diese dateien einfach mit eingerechnet. wie groß dürfen android roms denn heute sein? bei meinem alten htc p3300 sinds wenn ich mich recht erinnere 64Mb die zu verfügung stehen, aber ich hab bis heute wm6.1
 
@DataLohr: Also das Rom meines Optimus 3D ist unkompriemiert 340 MB groß und das ist 2.2 allerdings inklusive dem kram von lg.

Vanilla Android von CyanogenMod in Version 2.3.7 ohne google apps (dürfen sie ja nur extern anbieten) zwischen 95 und 110 MB je nach handy.allerdings ist das Rom komprimiert!
aber irgendwie ist das kompliziert zu erklären, den apps bzw programme die im rom enthalten sind werden ja nicht in die systempatition geschrieben sondern ausgelagert.die reine größe des betriebssystems ohne apps,also nur der kern inkl treiber und oberfläche, wird schwer zu bestimmen sein bzw von handy zu handy und version zu version stark varieren.
 
@Givarus: in 3 Zeilen Quellcode befindet sich sicherlich schon mindestens eine Zeile Kommentar
 
@-adrian-: Die müssen aber ne Menge Kommentare haben! Ich habe gerade mal geschaut: Windows XP hat ca. 50 Mio. Zeilen Code. Wenn man jetzt mal von durchschnittlich 40 Zeichen pro Zeile ausgeht (das ist eher sehr hoch gegriffen) kommt man auf ca. 2 Mrd. Zeichen. Wenn das jetzt mit 2 Byte pro Zeichen (Unicode) gespeicht würde, käme man für die Quellcodes von Windows XP auf ca. 3,75 GB!. Android ist also fast doppelt so Umfangreich wie Windows XP :-))
 
@Givarus: Da Android auf Linux basiert, ist vermutlich auch nochmal ein Großteil des Linux-Quellcodes enthalten (inkl. der verwendeten Tools)
 
@dodnet: Das könnte natürlich der Grund sein... Das muss ja auch noch für die entsprechende Plattform kompiliert werden. Trotzdem finde ich das schon extrem...
 
@Givarus: der Quellcode von XP ist als rar gepackt mit normalen Einstellungen 1.1gb groß ;)
 
@Ludacris: Woher willst du das wissen?
 
@Larucio: ich wusste das das kommt... Er lag ne Zeit lang auf einem ftp... Ein internetbekannter hat sich damit eine eigene Version von winxp compiliert
 
@Ludacris: WTF, das will ich auch.
 
@Larucio: Die Quellcodes von Windows sind kein Geheimnis. Microsoft gibt sie raus - nur nicht an jeden. Allein in Deutschland haben z.B. Dutzende Unis den Quellcode. Zu meinen Unizeiten hatten wir ihn auch im Institut, aber leider kann ich nicht mehr sagen wie groß er war.
 
"Die Quellcodes allein sind bereits ein 6 Gigabyte großes Paket." 6 GB Source??? Im Leben nich...
 
@Viceinator: Wieso nicht? Kann ich mir schon vorstellen. Allein wenn Google aus einer extern entwickelten OpenSource-Bibliothek nur eine einzige Funktion verwendet, können sie doch das komplette Source-Paket mit aufnehmen. Das müsste dann komplett zum Quellcode dazugerechnet werden.
 
@DennisMoore: Selbst mit externen Libs sind 6GB utopisch. Auch dass die Übersetzung auf einem Rechner mit 24GB 5h dauern soll is irgendwie komisch. Ich kann mit meinem Rechner nen FullHD Film der 3h geht in der hälfte der Zeit konvertieren.
 
@Viceinator: Konvertieren eines Filmes ist aber bei weitem nicht so aufwendig wie tausende kleine Dateien zu kompilieren.
 
@Viceinator: Das kann gut sein. Kompillieren fordert den Rechner mehr.
 
@Viceinator: hm... ne Banane schmeckt anders als nen Apfel...
 
@Viceinator: kann ich mir auch nicht vorstellen. Der Linux Kernel Quellcode hat etwas mehr als 73 MB. Dann noch etwas GUI drumrum und fertig.
 
@Viceinator: Doch, das kann sein. Das Subversion Sourcecode Repository in meiner Firma hat auch (ohne Kompilat) fast 1 GB (ausgecheckt).
Da kommt schnell was zusammen, ist ja nicht alles Source sondern auch Bilder, und andere Ressourcen.
 
6 GB sind ne Menge Holz. Allerdings sind das mit Sicherheit zum großem Teil irgendwelche Binärdateien (Bilder, Dokus...).
 
Wo kann man sich den Quellcode eigentlich runterladen?
 
@lordfritte: bis jetzt ist nur das sdk verfügbar für ics was als emu für den pc dienen soll bzw für programmiere um ihre apps anzupassen.der komplette Quellcode soll erst erscheine sobald das erste Handy auf dem Markt ist.also rechne nicht damit das es vor dezember bzw ende november rauskommt
 
@lordfritte: Noch garnicht, erst im Nov./Dez. wird es möglich sein.
 
Masse ist nicht immer Klasse
 
@mschatz: Hä?
 
Da soll noch einmal jmd sagen Programmierer surfen nur und haben keinen aufwendigen Job :P
 
Ich erwarte es schon sehnlichst für mein S2.
 
@tim-lgb: und ich für mein optimus 3d.aber nicht von lg sondern von cm ;) da die hardwaretechnischen specs vom Galaxy Nexus fast gleich sind einzig der Prozessor ist ein anderer, wird es wohl ziemlich schnell gehn ;)
 
Jungs was macht ihr denn so einen Wind, 5h sind das nur beim ersten compile, danach muss ja nur noch das jeweilige Teilsystem, das geändert wurde kompiliert werden, das sind dann ein paar Minuten. Hätte der Typ das in einer Ramdisk kompiliert hätte es höchsten 2h für einmal komplett bauen gebraucht. 6Gb an Quellcodes kann viel sein(wenn der Ganze Code von Google käme) oder auch gar nix, wenn ich z.B. für diverse Plattformen entwickle, dann habe ich in der Regel oftmals speziell für die Plattform gepatchte Kernel und somit liegen da gleich mal 5 Linuxkernel mit im Repository und die ersten paar GB sind schon verbraten. Habt ihr euch schon mal angeguckt, wie groß alleine die QT Quellen sind:-) Also nicht plappern sondern erstmal informieren.
 
@[U]nixchecker: Als wenn eine Ramdisk das Kompilieren schneller machen würde! Das Kompilieren hängt hauptsächlich vom Prozessor ab.
 
@gurke1509: die schreib und lese vorgänge beim kompilieren sind nicht ohne... da ist ne ramdisk klar besser als ne normale festplatte... das hab ich damals zu meiner gentoo zeit auch so gemacht wenn es nicht gerade openoffice war welches leider zu groß für meine ramdisk war ;-)
 
@[U]nixchecker: Gutes Argument. Und wenn dann noch vom Git-Clone der Android Sourcen gesprochen wird hat man auch noch alle Revisionen mit dabei. Gut die sind mit zlib (deflate) gepackt aber macht trotzdem noch was an Größe weg.
 
Wird es den nun 4.0 auch offiziell für das Xperia X10 Mini geben (Sony Ericsson: Android 4.0 für alle 2011-Modelle)?
 
@Ice-Tee: Leider wird das wohl noch einige Jahre dauern. Die Hersteller von Android Smartfones sind sehr schlampig was Updates betrifft. Selbst Spitzenprodukte wie das Samsung Galaxy S2 werden nicht sehr gut gepflegt.
 
@brunner.a: Was für ein Käse...gerade das SGSII ist sehr aktuell und auch das alte SGS ist auf dem gleichen Stand...
 
"Ein Smartphone, auf dem das Betriebssystem später einmal laufen soll, wäre wohl heillos überfordert, wenn es die Sourcen selbst übersetzten sollte."

Wer zum Teufel würde auf die Idee kommen Quellcodes auf einem Smartphone zu kompilieren?
 
@gurke1509: Ich da es einen schnelleren Prozessor hat als mein PC ;)
 
Ein viel zu aufgeblähtes Projekt.
 
@BadMax: Definiere "Aufgebläht". Viel MB heißt nicht, dass das System langsam ist. Bei Ice Cream Sandwich soll es ja sogar das Gegenteil sein
 
Also ohne ein paar Details zu den Angaben würde ich mich nicht darauf verlassen dass die Stimmen. Android wird mittels Git Entwickelt. D.h. eine Kopie des Sourcecodes beinhaltet alle Revisionen. Meint Google den Head oder den Git Clone mit 6GB Source Code? Was beinhaltet der Source-Code alles und wieviel Prozent sind Ressourcen und Dokumentation? Das Binary soll knapp 4 mal so groß sein als der Source? Niemals! Da wird doch sicher für mehrere Zielplattformen zugleich übersetzt. Zudem ist die Frage: Unterstützt der Source-Code auch den Build von älteren Android Versionen aus dem Bestandscode? Die Fragen kann man natürlich noch weiterführen aber die werden sowieso nicht beantwortet. :)
 
Es heißt AOSP.. Nur so am Rande..
 
@GlockMane: Danke. Ist behoben.
 
Im Android SDK sind so Sachen wie QEMU komplett mit dabei. Das Zeug bläht halt auf ohne Ende.
 
Irgendwie wird das Forum bei WinFuture wohl in erster Linie dazu verwendet, die erscheinenden Artikel entweder richtig zu stellen oder die entscheidenden Fakten zusammenzutragen.
Kommentar abgeben Netiquette beachten!

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles