Die Frage die euch bleibt...

[a user]

> Bleibt die Frage, warum Android erst auf so einem kräftigen Gerät so läuft wie iOS auf > weit weniger leistungsfähiger Hardware.
Weil so gut wie kein Hersteller ihr Android, dass sie auf ihre Geräte klatschen konfiguriert. Die scheduler-einstellungen z.b. sind immer noch die standard-desktop-werte.

Man sollte ein OS an die Hardware anpassen und entsprechend konfigurieren. Warum HTC, Samsung, LG etc. das nicht machen, DAS ist die Frage die bleibt.

Egal, mir hats bissle Geld gebracht und ne Menge user meiner app. Mein single core DHD läuft mit android so flüssig wie das iphone 4.

[Replay]

Das iPhone 4 komme ebenfalls nur mit einer Singlecore-CPU daher. Und die hat nur 800 MHz.

Die Stimmen außerhalb meines Kopfes irritieren mich am meisten...

[entonjackson]

Die Frage kann ich euch beantworten.
Weil Android hardwareunabhängig und absolut dynamisch ist.

Während bei iOS die Software auf die Hardware angepasst wird.

[Cyrano_B]

a user schrieb:
--------------------------------------------------------------------------------
> Egal, mir hats bissle Geld gebracht und ne Menge user meiner app. Mein
> single core DHD läuft mit android so flüssig wie das iphone 4.

Welche App wenn ich fragen darf?

[SevenUp]

a user, wie heisst denn Deine App?

[Misdemeanor]

a user schrieb:
--------------------------------------------------------------------------------
> > Bleibt die Frage, warum Android erst auf so einem kräftigen Gerät so
> läuft wie iOS auf > weit weniger leistungsfähiger Hardware.
> Weil so gut wie kein Hersteller ihr Android, dass sie auf ihre Geräte
> klatschen konfiguriert. Die scheduler-einstellungen z.b. sind immer noch
> die standard-desktop-werte.

Weil Apple hardwarenah programmieren kann und Android Applikationen in einer VM ausgeführt werden. Sorry, aber war das ein Geheimnis?! Natürlich braucht man dafür leistungsfähigere Hardware!

[EDIT]: Korrektur erfolgt!



1 mal bearbeitet, zuletzt am 15.11.12 15:41 durch Misdemeanor.

[droid87]

Misdemeanor schrieb:
--------------------------------------------------------------------------------
> a user schrieb:
> ---------------------------------------------------------------------------
> -----
> > > Bleibt die Frage, warum Android erst auf so einem kräftigen Gerät so
> > läuft wie iOS auf > weit weniger leistungsfähiger Hardware.
> > Weil so gut wie kein Hersteller ihr Android, dass sie auf ihre Geräte
> > klatschen konfiguriert. Die scheduler-einstellungen z.b. sind immer noch
> > die standard-desktop-werte.
>
> Weil Apple hardwarenah programmieren kann und Android in einer VM
> ausgeführt wird. Sorry, aber war das ein Geheimnis?! Natürlich braucht man
> dafür leistungsfähigere Hardware!


Android wird in der VM ausgeführt? Ich glaube, Sie meinen, dass die Apps in einer VM ausgeführt werden.

[Netspy]

a user schrieb:
--------------------------------------------------------------------------------
>
> Weil so gut wie kein Hersteller ihr Android, dass sie auf ihre Geräte
> klatschen konfiguriert.

Das kann nicht sein! Die Hersteller werden die Monate und teilweise Jahre, die sie für ein Update brauchen, doch wohl für intensive Optimierungen und Tests nutzen.

[Misdemeanor]

droid87 schrieb:
--------------------------------------------------------------------------------
> Misdemeanor schrieb:
> ---------------------------------------------------------------------------
> -----
> > a user schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > > Bleibt die Frage, warum Android erst auf so einem kräftigen Gerät so
> > > läuft wie iOS auf > weit weniger leistungsfähiger Hardware.
> > > Weil so gut wie kein Hersteller ihr Android, dass sie auf ihre Geräte
> > > klatschen konfiguriert. Die scheduler-einstellungen z.b. sind immer
> noch
> > > die standard-desktop-werte.
> >
> > Weil Apple hardwarenah programmieren kann und Android in einer VM
> > ausgeführt wird. Sorry, aber war das ein Geheimnis?! Natürlich braucht
> man
> > dafür leistungsfähigere Hardware!
>
> Android wird in der VM ausgeführt? Ich glaube, Sie meinen, dass die Apps in
> einer VM ausgeführt werden.

Völlig richtig, falsch ausgedrückt, sorry.
Apps & Widgets müssen virtualisiert ausgeführt werden, was einen erheblichen Performanceunterschied ausmacht.

[niw8]

Das VMs an der Perfomance drehen, erst recht "erheblich", ist ein Märchen.

[Cyrano_B]

Die Frage die uns bleibt...


.... welche App meint 'a user' im ersten Post?


Project Butter? *g* ;-)

[wrecked]

niw8 schrieb:
--------------------------------------------------------------------------------
> Das VMs an der Perfomance drehen, erst recht "erheblich", ist ein Märchen.
+1

[tingelchen]

Quatsch mit Soße.

Ja, Java wird in einer geschlossenen Box ausgeführt. Wofür man eine Runtime benötigt. Diese bildet eine zusätzliche Schicht und damit auch zusätzliche Resourcen. Welches auch etwas Performance kostet.

Jedoch sind die Zeiten, in denen Java schleichend langsam sind, seit Jahren vorbei. Oder sollte man mittlerweile sagen... Jahrzehnte? ^^ Mit einem guten Compiler sind Java Anwendungen, mit der aktuellen Runtime unwesentlich langsamer als C++ Anwendungen.

[ssssssssssssssssssss]

Lustigerweise setzen Leute die ständig auf Java fluchen dann XUL und JS apps ein....

[Doomchild]

Die App bleibt er uns wohl schuldig.

____________________________________________________________________
"Hey, I rock the unfree world, that's my specialty." - Jello Biafra

[chrulri]

Zumal es schlussendlich keine Java Runtime und auch kein Java Bytecode sondern eine Dalvik VM mit Dalvik Bytecode ist.

Unterschiede?
DVM = Register-basierend
JVM = Stack-basierend

[nightfury]

tingelchen schrieb:
--------------------------------------------------------------------------------
> Quatsch mit Soße.

och, geht.

> Ja, Java wird in einer geschlossenen Box ausgeführt. Wofür man eine Runtime
> benötigt. Diese bildet eine zusätzliche Schicht und damit auch zusätzliche
> Resourcen. Welches auch etwas Performance kostet.

Bitte nicht vergessen: Es geht nicht nur darum dass eine VM die App kapselt, sondern auch dass Java, auch als Dalvik Variante, teilweise durch den Interpreter muss. Java ist und bleibt eine Hochsprache, und bringt den damit einhergehenden Overhead mit sich. Das kostet halt Rechenzeit und CPU. Dalvik hat sich vor knapp 2 Jahren damit gerühmt, durch die Optimierungen "nur noch" 50% Interpreter-Overhead zu haben. Sprich, die CPU hat fuer die gleiche App 150% Rechenaufwand wie unter C. Und das war ein grandioses Ergebnis...

> Jedoch sind die Zeiten, in denen Java schleichend langsam sind, seit Jahren
> vorbei. Oder sollte man mittlerweile sagen... Jahrzehnte? ^^ Mit einem
> guten Compiler sind Java Anwendungen, mit der aktuellen Runtime
> unwesentlich langsamer als C++ Anwendungen.

Aber sicher doch. Solche Aussagen sind dermaßen weit entfernt von jeglicher rationalen Bewertbarkeit. Und das lässt sich sogar leicht überprüfen: So ein Quadcore S3 hat im reinen CPU Benchmark die Nase vorn. CPU Benchmarks sind aber auch so simpel, dass nichts im Interpreter verarbeitet wird. einfaches Abarbeiten von Listen. Wenn man dann ein realeres Szenario (wer recoded schon ein DVD Image auf seinem Handy..) nimmt und z.B. einen Browserbenchmark laufen lässt, zeigt sich dass von der CPU Power vergleichswese wenig über bleibt. Da ziehen sowohl WinPhone als auch iOS schnell vorbei, mit wesentlich magerer CPU Leistung.

Noch so eine Sache: Ich kenne keine Java Anwendung, die performant ist. Nimmt man mal sowas wie JDownloader und Borland Together, dann fragt man sich wirklich wofür da CPU und RAM verbraten werden.

[hyperlord]

> Noch so eine Sache: Ich kenne keine Java Anwendung, die performant ist.
> Nimmt man mal sowas wie JDownloader und Borland Together, dann fragt man
> sich wirklich wofür da CPU und RAM verbraten werden.

Dann schau Dir z.B. mal die IDEs von JetBrains an (IDEA, PyCharm, WebIDE, PHPStore oder AppCode). Alles Java - alles sau schnell.

[nightfury]

hyperlord schrieb:
--------------------------------------------------------------------------------
> > Noch so eine Sache: Ich kenne keine Java Anwendung, die performant ist.
> > Nimmt man mal sowas wie JDownloader und Borland Together, dann fragt man
> > sich wirklich wofür da CPU und RAM verbraten werden.
>
> Dann schau Dir z.B. mal die IDEs von JetBrains an (IDEA, PyCharm, WebIDE,
> PHPStore oder AppCode). Alles Java - alles sau schnell.

? Also, nur dass wir uns recht verstehen - als Beispiel werden immer IDEs genannt. IDEs sind allerdings Texteditoren mit Syntax-Highlighting. Quasi kein nennenswerter Anspruch. Der Start von IDEA dauert hier von SSD immer noch 2-3 Sekunden (das ist recht lange), die Anwendung hat direkt nach dem Anlegen eines neuen leeren Projekts 300MB Speicher verbraten (das ist mehr als Visual Studio braucht mit einer offenen Solution) und ich kann nicht sehen wo mich da Geschwindigkeit beeindrucken soll. Es sind schliesslich nur Textfiles, die irgendwann einem Compiler übergeben werden. Ich wette, als C++ Anwendung wäre das ganze wesentlich effizienter, aber in beiden Fällen ist es sehr schnell für den Anwender. Ein Argument pro Java ist das aber trotzdem nicht.

[ZetaGlm]

Wie währe es mit IL-2 Sturmovik, Minecraft oder Apache Tomcat?

Eine Reimplementierung von Quake2 von C in Java erreichte eine Framerate von 85%-105% im Vergleich zum Original (je nach verwendeten Treiber/System).
http://bytonic.de/html/benchmarks.html

Die reine Rechenperformance von Javaprogrammen ist nicht schlecht.
Hier ist eine Seite, welche Algoritmen in verschiedenen Programmiersprachen implementiert und anschließend die Performance verlgleicht:
http://shootout.alioth.debian.org/u32/which-programs-are-fastest.php

Java ist dort im Durchschnitt 1,78 mal langsamer, als die schnellste Programmiersprache (zum Vergleich: C++ ist im Schnitt 1,12 mal langsamer; C ist im Schnitt 1,3 mal langsamer; C# im Schnitt 2,46 langsamer)

Die Probleme von Java liegen meiner Meinung nach bei anderen Dingen:
- Java braucht, bedingt durch die Speicherverwaltung, deutlich mehr Hauptspeicher. Hier kann man als Programmierer auch viel falsch machen und die Programme unnötig aufblähen.
- Die Übernahme von Sun durch Oracle und die Ungewissheit über die künftige Entwicklung
- Wiederkehrende Sicherheitslücken in den Browserplugins: Hier bekommt Java viel schlechte Kritik und viele Leute haben Probleme, die Programmiersprache Java vom Browserplugin Java (und sogar JavaScript) zu unterscheiden.



1 mal bearbeitet, zuletzt am 15.11.12 19:33 durch ZetaGlm.