News Hersteller entwickeln dünnere Heatpipes für Smartphones

[Piktogramm]

...

@ Piktogramm
Wozu ein 20nm SoC im mobilen Begleiter, wenn selbst ein 60nm nicht richtig genutzt wurde. Man entwickelt sich um Kopf und Kragen um Fortschritt zu rechtfertigen, der nicht genutzt wird. LTE auf dem Chip bei unbrauchbaren Endverträgen ist genauso Verschwendung...

Die Reduktion der Strukturgröße geht einher mit geringerer Leistungsaufnahme bei ansonsten gleicher Architektur bzw. Leistung oder aber bei gleicher Leistungsaufnahme eine höhere Performance. Hinzu kommt längerfristig eine Kostenoptimierung, da die Chips kleiner werden. Da gibt es ganz andere Entwicklungen, die merkwürdig sind und nur kompensieren müssen, dass die Programmierer oft mit heißer Nadel stricken (müssen).

Was LTE angeht, nur weil es in Deutschland keine gescheiten Verträge gibt, heißt das nicht, dass die Integration im internationalen Maßstab nicht sinnvoll ist. Zudem ist es auch möglich Telefonen mit UMTS Verträgen in LTE Zellen einzubuchen und so zwar keine höhere Geschwindigkeit aber eine bessere Versorgungssituation (vor allem in Innenstädten) zu bewerkstelligen. Es ist aus Sicht der Netzbetreiber also durchaus sinnvoll.

 

[TrueAzrael]

Die technik ist mit der von PC's ja nicht so recht vergleichbar, aber braucht man wirklich Quad- / Hexacore Handys? Muss man ein Spiel mit super-bombastischer Grafik auf einem Handy zum laufen bringen, was den Akku in 30 Minuten leersaugt? Meiner Meinung nach geht die Smartphoneentwicklung in die falsche Richtung.

Also wenn ich mit meinem Smartphone im angestecktem Zustand Battlefield, Crysis und Co. auf 3x 30" Monitoren in 3D spielen könnte, dann würd mir das sehr entgegenkommen (Gamingrechner eingespart). Aber dabei darf die Laufzeit im mobilen Einsatz (ohne externe Stromquelle) natürlich nicht leiden. Da gibts noch einiges zu tun in Punkto Leistung und Skalierbarkeit.

 

[iiiPlayer]

Zu Apple: Ich bin der Meinung mal gelesen zu haben, das sobald eine "Wichschgeste" ausgelöst wird, das alle Prozesse gestoppt werden, nur um die Animation hübsch und flüssig darzustellen. Netter Trick und ich muss zugeben es Funktioniert, allerdings ist das schon ein wenig "geschummelt"

Ach so! Deshalb stoppt bei mir dann immer die Musikwiedergabe

Ich denke, dass es viel eher daran liegt, dass Apple iOS einfach perfekt an das iPhone anpassen kann, während Android auf fast jedem Handy läuft.

 

[Piktogramm]

@Simpl3Moe: Das ist alte Schule, dass Nutzereingaben Vorrang haben und eine flüssige Benutzerführung oberste Priorität ist. Bei Android wird nach dem Drücken einer Taste um den Bildschirm aufzuwecken auch die CPU auf 50% bis 100% getaktet und in diesem Zustand für 0,5 bis 1 sek belassen*, damit folgende Nutzereingaben möglichst flüssig erfolgen können. Gleichzeitig erhält die GUI auch die höchste Prozesspriorität (daher Hintergrundprozesse die zu diesem Zeitpunkt Daten aktualisieren wollen kommen meist nicht zum Zuge).



*Daher, wenn man nur auf die Uhr schaut wird das ganze System sofort auf maximale Leistungsfähigkeit getrimmt und verpulvert dabei "sinnlos" Energie, genauso wird oftmals nach jeder Eingabe (Wischgeste, Tastendruck) die CPU noch etwas auf dem höchstem Takt belassen um weitere Eingaben möglichst fix bearbeiten zu können.

 

[riDDi]

Und du meinst Apple macht das anders? Race to Idle eben... ganz besonders bei Nutzereingaben. Je schneller man den Nutzer dazu bringen kann das Gerät in Ruhe zu lassen, umso besser

Warum stockt Android manchmal? Zwei Gründe: Apps und Services können im Hintergrund echte Arbeit erledigen und schludrige App-Programmierung - selbst in Googles eigener Software. Der wichtigere Grund ist vmtl. letzterer, denn mit mehreren Kernen und gutem Scheduler sollte sowas eigentlich nicht passieren. Die vorletzte Version der Play Store hat permanent vor sich hin gezuckelt. Besonders auffällig war das in der letzten Version von Play Music. Die Portrait-Ansicht ruckelte sich tot, während das optisch viel ansprechendere Landscape-Format im Coverflow-Stil absolut ruckelfrei lief.
Vielleicht geben sich die App-Programmierer bei Apple einfach mehr Mühe? Vielleicht lässt das Framework auch einfach keine Programmiersünden zu. Meine Apps ruckeln jedenfalls nicht. Dazu muss ich nur eine Regel beachten: Keine Arbeit im UI-Thread. Die Extraarbeit nervt manchmal, aber es wirkt. Wenn ich allerdings sehe, dass Google sich dazu genötigt sah Apps rigoros abstürzen zu lassen, falls man einen Socket im UI-Thread öffnet, kann ich nur noch den Kopf schütteln. Sowas macht man ja nicht ohne Grund.

 

[Piktogramm]

Mein erster Satz besagt doch eigentlich, dass dieses Verhalten "alte Schule" sei und sollte damit andeuten, dass es plattformübergreifend so gemacht wird und das weit länger als iOS und Android am Markt sind . Danach beschreibe ich nur das Verhalten von Android, da mir dessen Verhalten halbwegs bekannt ist .

Apple kann es bei iOS durchaus anders machen. Es gibt da verschiedene Ansätze und ich weiß nicht welche Apple nutzt, außer das (was selbstverständlich ist) im Vordergrund befindliche Nutzerprozesse Vorrang erhalten. Wobei selbst bei Android viele Customroms das Einstellen des Governers zulassen und da die verschiedenste Ansätze verfolgen (zumindest soweit wie es die Hardware zulässt)

 

[user4base]

@Simpl3Moe
such mal nach den Stichworten: iOS Browser Seitenaufbau stoppt scrollen ....

@Piktogramm
und das hat weniger mit dem Governor (Taktfrequenz) zu tun, sondern mit dem Scheduler und nein ich meine nicht nur den I/O Scheduler. Und da gab es in den letzten Jahren teilweise auch Paradigmenwechsel bzw. Versuche:
Beispiel:

Der Brain Fuck Scheduler orientiert sich beim Verteilen von Rechenzeiten am CFS. Allerdings beeinflussen beim CFS auch die am Prozess gemessenen Ruhepausen der Vergangenheit die Entscheidung, wie lange eine Zeitscheibe für den Prozess in der Zukunft dauern wird. Gerade bei leistungsschwacher Hardware, wie beispielsweise Mobiltelefonen, kann dies für die Benutzereingaben hinderlich sein. Wenn zu viele Ruhezeiten des Eingabeprozesses in der Vergangenheit aufgetreten sind, wird auch in Zukunft weniger Zeit dafür vorgesehen, bis sich die Statistik wieder ändert - eben dann, wenn wieder eine Benutzerinteraktion stattfindet. Der BFS entfernt diese komplexe Berechnung der Zeitscheiben anhand von Sleep-Aufrufen und versucht eine komplett faire Verteilung anzustreben.

Dieser „verkehrten“ Herangehensweise verdankt der Algorithmus auch seinen Namen. Er macht genau das, was in der Informatik nicht gelehrt wird, um einen effizienten Scheduler zu programmieren

Der BFS wurde mit Version 4.1.6 in den CyanogenMod, eine Distribution des Mobil-Betriebssystems Android, integriert und hat zu berichteten Geschwindigkeitsverbesserungen geführt.[7][8] Steve Kondik kündigte Ende Oktober 2009 an, den BFS wieder aus dem Hauptentwicklungszweig zu entfernen. Der BFS wurde am 23. September 2009 auch in einen experimentellen Zweig des Android-Entwicklungsrepositoriums aufgenommen. Er wurde jedoch nicht in die Froyo-Veröffentlichung (Android 2.2.x) aufgenommen, nachdem Blindtests mit dem Droid und dem NexusOne keine Verbesserung im Benutzererlebnis zeigten.
Quelle: Wikipedia

@Simpl3Moe
und das was du Trickserei nennst ist "normal"
Es gibt teilweise einen eklatanten Unterschied zwischen tatsächlicher (Warte-)zeit und gefühlter.
So können 3sec. zu gefühlten 10sec. werden und dies versucht man unter allen Umständen zu vermeiden in dem man z.B. "schöne" Animationen, Fortschrittsbalken usw. verwendet. Es kann dadurch passieren, dass aus den tatsächlichen 3sec. 4sec. werden, aber für den Benutzer sind es gefühlte 5sec. und er ist zufrieden, auch wenn das ganze ohne den ganzen "Schnick-Schnack" nur 3sec. gedauert hätte.

• Tatsächlich 3sec. => gefühlt 10sec. (ohne Animation...)
• Tatsächlich 4sec. (mit Animation...) => gefühlt 5sec.

Die gefühlten 5sec. sind für den Benutzer angenehmer, als die tatsächlichen 3sec.

c't:
...
Auch das Lumia ist flott: Die Oberfläche animiert flüssig und ruckelt nie, allerdings brauchen Apps zum Starten länger als auf Android und iOS. Das fällt aber gar nicht so auf, weil Windows die Wartezeiten mit Animationen überspielt.
...

Psychologie (menschliche Wahrnehmung) spielt dabei also (auch) eine wichtige Rolle. http://blogs.msdn.com/b/windowsappd...-sie-die-leistung-von-apps-im-metro-stil.aspx

Auch beim Scheduler
Beispiel:

Interaktive Systeme (Dialogsysteme)

• Proportionalität: Die Antwortzeiten verschiedener Prozesse sollten den Erwartungen des Benutzers entsprechen. Werden Prozesse (wie z. B. das Schließen einer Anwendung) vom Benutzer als simpel betrachtet, sollten diese auch schnell ausgeführt werden

.

@riDDi
Such mal nach: ios appstore ruckelt