Abo
  1. Foren
  2. Kommentare
  3. Handy
  4. Alle Kommentare zum Artikel
  5. › HTC Titan: Großes Smartphone mit 1,5-GHz…

Zweikernschwachsinn

  1. Thema

Neues Thema Ansicht wechseln


  1. Zweikernschwachsinn

    Autor: WinMo4tw 01.09.11 - 21:00

    Sowas braucht momentan noch kein Mensch. Windows Phone läuft selbst auf der ersten Generation Snapdragon butterweich. Die hier verbaute zweite Generation mit 2-3fach leistungsfähigerer Grafik und nochmal 50% mehr Takt reicht für diese Gerätegeneration allemal.

    MfG

  2. Re: Zweikernschwachsinnschwachsinn

    Autor: pwn2own 01.09.11 - 21:10

    Normalnutzer vllt. nicht. Aber mittlerweile gibt es auch Anwendungen, die nicht im App-Store/Market/Softwarekonsum zu finden sind und sehr wohl ein bisschen Rechenpower benötigen.

  3. Re: Zweikernschwachsinn

    Autor: Anonymer Nutzer 01.09.11 - 21:41

    is doch wurscht, hauptsache der schwanz ist länger als der von apple.

  4. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 01.09.11 - 22:18

    Da WP7 aber zB gegenüber Android ein extrem performantes OS ist, reicht die Performance sehr wohl auch für komplexere Anwendungen aus.

  5. Re: Zweikernschwachsinnschwachsinn

    Autor: smurfy 01.09.11 - 22:46

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > Da WP7 aber zB gegenüber Android ein extrem performantes OS ist, reicht die
    > Performance sehr wohl auch für komplexere Anwendungen aus.

    Ich glaube du hast da nicht ganz zuende gedacht. Die Windows GUI ist sehr performant, jedenfalls performanter als die von Android (so lange Android nicht die GPU verwendet).

    Allerdings hat das nichts mit der Performance von Anwendungen und Spielen zu tun. Denn diese laufen unter Android nicht langsamer als unter WP7. Die performancekritischen Teile können auch unter Android unter C/C++ geschrieben werden, und laufen spätestens dann sehr flott. Gegen einen DualCore Android kommt da ein SingleCore WP7 auch nicht an.

  6. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 01.09.11 - 22:56

    >Allerdings hat das nichts mit der Performance von Anwendungen und Spielen zu tun. Denn diese laufen unter Android nicht langsamer als unter WP7. Die performancekritischen Teile können auch unter Android unter C/C++ geschrieben werden, und laufen spätestens dann sehr flott. Gegen einen DualCore Android kommt da ein SingleCore WP7 auch nicht an.

    Naja, das geht aber wirklich nur bei Spezialanwendungen, die genau auf einem bestimmten Gerät laufen, mit Multiplattform ist dann Sense. Mag für eine firmeninterne Anwenung, oder ein Kundenprojekt funktionieren, bei dem die Hardware gleich mit ausgeliefert wird - für kommerzielle Projekte ist das aber nix. Und bei jedem späteren Modellwechsel ist dann fröhliches Portieren angesagt...

  7. Re: Zweikernschwachsinnschwachsinn

    Autor: JeanClaudeBaktiste 01.09.11 - 23:37

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Allerdings hat das nichts mit der Performance von Anwendungen und Spielen
    > zu tun. Denn diese laufen unter Android nicht langsamer als unter WP7. Die
    > performancekritischen Teile können auch unter Android unter C/C++
    > geschrieben werden, und laufen spätestens dann sehr flott. Gegen einen
    > DualCore Android kommt da ein SingleCore WP7 auch nicht an.
    >
    > Naja, das geht aber wirklich nur bei Spezialanwendungen, die genau auf
    > einem bestimmten Gerät laufen, mit Multiplattform ist dann Sense. Mag für
    > eine firmeninterne Anwenung, oder ein Kundenprojekt funktionieren, bei dem
    > die Hardware gleich mit ausgeliefert wird - für kommerzielle Projekte ist
    > das aber nix. Und bei jedem späteren Modellwechsel ist dann fröhliches
    > Portieren angesagt...

    auf kurz oder lang wird es wp7 oder 8 dann auch mit multicore geben,

    ich finde es auch recht vernünftig noch bei 800 x 480 zu bleiben auch wenn auf dem großen schirm vielleicht wieder pixel zu sehen sind.

    wenn man aber überlegt dass damals damit 15 zoll monitore gelaufen sind (800 c 600) ist noch ein bischen luft.

    retina halte ich für marketing. ich habe mal das iphone 4 mit meinem omnia verglichen. beim omnia sieht man wenn man genau hinschaut ein raster was wohl prinzipbedingt an amoled liegt. der auflösungsvorteil des iphone 4 kommt nicht zum vorschein, dafür büsst der screen wegen der geringeren größe und den trüben farben massiv ein.

    ---
    leer, weil keine Werbung bei Golem :(

  8. Re: Zweikernschwachsinn

    Autor: sparvar 02.09.11 - 00:00

    [ ] du hast ahnung
    [ x ] troll

  9. Re: Zweikernschwachsinnschwachsinn

    Autor: tomek 02.09.11 - 00:21

    JeanClaudeBaktiste schrieb:
    --------------------------------------------------------------------------------
    > ich finde es auch recht vernünftig noch bei 800 x 480 zu bleiben auch wenn
    > auf dem großen schirm vielleicht wieder pixel zu sehen sind.
    >
    > wenn man aber überlegt dass damals damit 15 zoll monitore gelaufen sind
    > (800 c 600) ist noch ein bischen luft.
    >
    > retina halte ich für marketing. ich habe mal das iphone 4 mit meinem omnia
    > verglichen. beim omnia sieht man wenn man genau hinschaut ein raster was
    > wohl prinzipbedingt an amoled liegt. der auflösungsvorteil des iphone 4
    > kommt nicht zum vorschein, dafür büsst der screen wegen der geringeren
    > größe und den trüben farben massiv ein.
    Denke ich auch. Es ist ein unterschied zwischen dem was möglich und dem was nötig ist. Und das Display meines HD7 ist alles andere als pixelig. Und das gehört mit zu den größeren Display (von der Diagonale her).

  10. Re: Zweikernschwachsinn

    Autor: EqPO 02.09.11 - 07:58

    Nein WP7-Besitzer. Schön reden ist wichtig.

  11. Re: Zweikernschwachsinnschwachsinn

    Autor: nate 02.09.11 - 08:59

    > > Die
    > > performancekritischen Teile können auch unter Android unter C/C++
    > > geschrieben werden, und laufen spätestens dann sehr flott.
    >
    > Naja, das geht aber wirklich nur bei Spezialanwendungen, die genau auf
    > einem bestimmten Gerät laufen, mit Multiplattform ist dann Sense.

    So ein Käse. Alle(*) Android-Smartphones haben einen ARMv6- oder ARMv7-Prozessor und wenn sie eine GPU haben (und die haben fast alle), dann eine, die über OpenGL|ES 2.0 angesprochen werden kann. Wieso sollte eine Anwendung dann nur "genau auf einem bestimmten Gerät" laufen?


    (*) Ausnahmen sind hierzulande so gut wie gar nicht verbreitete Ultra-Billig-China-Geräte, die gelegentlich noch ältere ARMe oder sogar vereinzelt MIPSe benutzen. Aber das sind wirklich nur die Billigstdinger, auch Huawei und ZTE spielen da in einer anderen Liga.

  12. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 09:28

    >retina halte ich für marketing. ich habe mal das iphone 4 mit meinem omnia verglichen. beim omnia sieht man wenn man genau hinschaut ein raster was wohl prinzipbedingt an amoled liegt. der auflösungsvorteil des iphone 4 kommt nicht zum vorschein, dafür büsst der screen wegen der geringeren größe und den trüben farben massiv ein.

    Ich finde, besonders bei Desktop-Websites mit viel Schrift sieht man durchaus den Unterschied beim iPhone4. Besonders, weil das AMOLED (im Gegensatz zum neuen Super AMOLED) eine deutlich geringere tatsächlich Auflösung als die Nennauflösung hat. (weniger Sub-Pixel pro Pixel)

  13. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 11:18

    >So ein Käse. Alle(*) Android-Smartphones haben einen ARMv6- oder ARMv7-Prozessor und wenn sie eine GPU haben (und die haben fast alle), dann eine, die über OpenGL|ES 2.0 angesprochen werden kann. Wieso sollte eine Anwendung dann nur "genau auf einem bestimmten Gerät" laufen?

    Weil es z.B. selbst zwischen den einzelnen ARM-Prozessoren Unterschiede gibt:
    http://www.riscosopen.org/wiki/documentation/show/ARMv7%20compatibility%20primer

    Weil die GUIs von den verschiedenen Herstellern z.T. angepaßt wurden - OK, vermutlich schlägst Du jetzt vor, Deine eigene GUI zu schreiben - viel Spaß mit unterschiedlichen Display Auflösungen und Formaten...

    Weil es mehr als CPU+GPU auf den SoCs gibt? Wie ist das mit Multithreaded Code? Wird der ohne Neucompilierung jeweils optimal auf Single-Core Geräten als auch auf Multicore-Geräten ausgeführt?

  14. Re: Zweikernschwachsinnschwachsinn

    Autor: nate 02.09.11 - 11:39

    > > Wieso sollte eine
    > > Anwendung dann nur "genau auf einem bestimmten Gerät" laufen?
    >
    > Weil es z.B. selbst zwischen den einzelnen ARM-Prozessoren Unterschiede
    > gibt:

    Das bezieht sich nicht auf einzelne ARM-Prozessoren, sondern auf Architekturversionen -- und die beiden für Smartphones relevanten (ARMv6 und ARMv7) habe ich ja bereits genannt. Davon abgesehen sind das, was der Artikel nennt, mehr oder weniger Peanuts: Anderes Verhalten bei falsch ausgerichteten Speicherzugriffen ("geht gar nicht"/"geht langsam"/"geht schnell"), anderes Verhalten bei sinnlosen Codesequenzen und solches Zeug. Alles Dinge, mit denen sich allenfalls der Compilerhersteller herumplagen muss und für einen Anwendungsentwickler in 99% aller Fälle komplett irrelevant sind.

    > Weil die GUIs von den verschiedenen Herstellern z.T. angepaßt wurden

    Und? Was interessiert deine Anwendung, wie der Launcher und die Statusleiste konkret aussieht?

    > vermutlich schlägst Du jetzt vor, Deine eigene GUI zu schreiben

    Was meinst du mit "eigene GUI schreiben"? Die allermeisten Android-, WebOS, WP7- und iOS-Anwendungen benutzen die Standard-Widgetsets des Betriebssystems. Ausnahmen sind Applikationen, die besondere Anforderungen haben und daher ein komplett eigenes User Interface brauchen, z.B. Spiele.

    > viel Spaß
    > mit unterschiedlichen Display Auflösungen und Formaten...

    Und? Mit unterschiedlichen Displayauflösungen muss man sich auf jedem Smartphone-Betriebssystem auseinandersetzen. Das einzige, wo das nicht so ist, ist WP7 -- bisher. Früher oder später wird aber auch Microsoft zur Erkenntnis gelangen, dass 480x800 keine Auflösung für die Ewigkeit ist :)

    > Weil es mehr als CPU+GPU auf den SoCs gibt?

    Und? Für so ziemlich jede Komponente gibt es APIs vom jeweiligen Betriebssystem.

    > Wie ist das mit Multithreaded
    > Code? Wird der ohne Neucompilierung jeweils optimal auf Single-Core Geräten
    > als auch auf Multicore-Geräten ausgeführt?

    Da gilt das gleiche wie für normale PC/Mac-Anwendungen: Wenn im System mehr Threads benutzt werden als die CPUs Threads hat (und das ist *immer* der Fall), kommt präemptives zeitscheiben-basiertes Multitasking zum Einsatz.

    In Anwendungen, die konkret auf Multithreading ausgerichtet sind, kommt übrigens meist eine Thread-Pool-Verwaltung zum Einsatz, die sich an die Anzahl der im System vorhandenen Cores/Threads anpasst -- zur Laufzeit, wohlgemerkt.

  15. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 12:40

    >...anderes Verhalten bei sinnlosen Codesequenzen und solches Zeug. Alles Dinge, mit denen sich allenfalls der Compilerhersteller herumplagen muss und für einen Anwendungsentwickler in 99% aller Fälle komplett irrelevant sind.

    Ähem, exakt davon rede ich doch? Ich sagte nicht, daß Du Deine C++ Anwendung wegen der unterschiedlichen CPUs jedesmal Redesignen mußt, aber um ein Neucompilieren kommst Du nicht drumherum...

    >Und? Was interessiert deine Anwendung, wie der Launcher und die Statusleiste konkret aussieht?

    Wie ist das mit den GUI-Libs? Werden die nicht angefaßt und angepaßt?

    >Was meinst du mit "eigene GUI schreiben"? Die allermeisten Android-, WebOS, WP7- und iOS-Anwendungen benutzen die Standard-Widgetsets des Betriebssystems.

    Richtig, und wenn beim Betriebssystem oberhalb des Kernels jeder Hersteller sein eigenen Anpassungen, Erweiterungen und Änderungen machen kann, dann mußt Du auch Deine App anpassen, die diese nutzt.

    >Und? Mit unterschiedlichen Displayauflösungen muss man sich auf jedem Smartphone-Betriebssystem auseinandersetzen.

    Eigentlich nur bei Android... Apple hat das ja geschickt durch die Auflösungs-Verfierfachung umgangen.

    >Und? Für so ziemlich jede Komponente gibt es APIs vom jeweiligen Betriebssystem.

    Und gegen die muß man nicht compilieren? Und das sind bei jedem Hersteller immer die gleichen in der gleichen Version?

    >Da gilt das gleiche wie für normale PC/Mac-Anwendungen: Wenn im System mehr Threads benutzt werden als die CPUs Threads hat (und das ist *immer* der Fall), kommt präemptives zeitscheiben-basiertes Multitasking zum Einsatz.

    >In Anwendungen, die konkret auf Multithreading ausgerichtet sind, kommt übrigens meist eine Thread-Pool-Verwaltung zum Einsatz, die sich an die Anzahl der im System vorhandenen Cores/Threads anpasst -- zur Laufzeit, wohlgemerkt.

    Ist das so? Ich kenne die Implementierung unter Android nicht so en Detail, vor allem weiß ich nicht, was dort native ist und welcher Anteil Java basiert ist. Dürfte auch nicht so einfach sein, aus Assembler Code heraus eine Java API zu bedienen...

  16. Re: Zweikernschwachsinnschwachsinn

    Autor: nate 02.09.11 - 12:57

    > Ich sagte nicht, daß Du Deine C++
    > Anwendung wegen der unterschiedlichen CPUs jedesmal Redesignen mußt, aber
    > um ein Neucompilieren kommst Du nicht drumherum...

    Doch -- denn niemand zwingt den Entwickler, sowohl eine ARMv6- als auch eine ARMv7-Version vorzuhalten. Man kann auch einfach für ARMv6 compilieren und fertig (oder im Zweifelsfall gar ARMv5, das läuft dann *überall*, inklusive Billigst-Chinaware).

    > Wie ist das mit den GUI-Libs? Werden die nicht angefaßt und angepaßt?

    Soweit ich weiß nicht. Das wäre ja auch absolut dämlich, damit würde der Hersteller ja inkompatibel zu existierenden Anwendungen werden.

    > Richtig, und wenn beim Betriebssystem oberhalb des Kernels jeder Hersteller
    > sein eigenen Anpassungen, Erweiterungen und Änderungen machen kann, dann
    > mußt Du auch Deine App anpassen, die diese nutzt.

    Nein, außer man braucht wirklich herstellerspezifische Funktionen. Aber praktisch alles an Peripherie und Funktionen, die man in so einem Smartphone oder Tablet hat (Touchscreen, Telefon, SMS, Kontakte, Internet, Bluetooth, GPS, Beschleunigungs-/Lagesensoren, Kompass, Speicherkarten, Kameras, Audio- und Videoplayback, ...) kann man durch Standard-APIs in den jeweiligen Betriebssystemen erreichen. Herstellerspezifische APIs sind dadurch überflüssig (und auch generell nicht besonders erwünscht).

    > > Und? Mit unterschiedlichen Displayauflösungen muss man sich auf jedem
    > > Smartphone-Betriebssystem auseinandersetzen.
    >
    > Eigentlich nur bei Android... Apple hat das ja geschickt durch die
    > Auflösungs-Verfierfachung umgangen.

    Zwischen 320x480 (iPhone) und 768x1024 (iPad) vermag ich keine Vervierfachung zu erkennen.

    > >Und? Für so ziemlich jede Komponente gibt es APIs vom jeweiligen
    > > Betriebssystem.
    >
    > Und gegen die muß man nicht compilieren? Und das sind bei jedem Hersteller
    > immer die gleichen in der gleichen Version?

    Siehe oben: Es sind bei jedem Hersteller die gleichen, weil es Betriebssystem-APIs sind. Was die Versionen angeht, gilt das gleiche wie bei eigentlich jeder API: Rückwärtskompatibilität.

    > Dürfte auch nicht so einfach sein, aus Assembler Code heraus
    > eine Java API zu bedienen...

    Man muss sich dazu eine kleine Schicht aus prozeduralem Java-Code bauen, die man dann über Callbacks aus dem nativen Code aus aufruft. Nicht besonders schön, zugegeben -- das ist einer der wenigen Aspekte, wo iOS mit seinem konsequenten Native-Code-Konzept den Mittbewerbern klar überlegen ist.

  17. Re: Zweikernschwachsinnschwachsinn

    Autor: Trollversteher 02.09.11 - 13:04

    >Zwischen 320x480 (iPhone) und 768x1024 (iPad) vermag ich keine Vervierfachung zu erkennen.

    Du schriebst aber "Smartphone-Betriebssystem". Denn wenn wir das auf Tablets erweitern, wirst Du durch die Unterschiede zwischen Honeycomb und Ginger bread unter Android bei native Apps deutlich größere Probleme bekommen als nur die Auflösung...

    >Man muss sich dazu eine kleine Schicht aus prozeduralem Java-Code bauen, die man dann über Callbacks aus dem nativen Code aus aufruft. Nicht besonders schön, zugegeben -- das ist einer der wenigen Aspekte, wo iOS mit seinem konsequenten Native-Code-Konzept den Mittbewerbern klar überlegen ist.

    OK, das dachte ich mir - wird ja auch einen Grund dafür geben, daß es so weinige native Apps im Android MArket gibt.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. AKDB, München
  2. Württembergische Gemeinde-Versicherung a.G., Stuttgart
  3. eXXcellent solutions GmbH, Ulm, München, Stuttgart, Darmstadt, Berlin
  4. Publicis Pixelpark Köln, Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. mit Gutschein: NBBGRATISH10


Haben wir etwas übersehen?

E-Mail an news@golem.de


Nachhaltigkeit: Jute im Plastik
Nachhaltigkeit
Jute im Plastik

Baustoff- und Autohersteller nutzen sie zunehmend, doch etabliert sind Verbundwerkstoffe mit Naturfasern noch lange nicht. Dabei gibt es gute Gründe, sie einzusetzen, Umweltschutz ist nur einer von vielen.
Ein Bericht von Werner Pluta

  1. Autos Elektro, Brennstoffzelle oder Diesel?
  2. Energie Wo die Wasserstoffqualität getestet wird
  3. Energiespeicher Heiße Steine sind effizienter als Brennstoffzellen

WEG-Gesetz: Bundesländer preschen bei Anspruch auf Ladestellen vor
WEG-Gesetz
Bundesländer preschen bei Anspruch auf Ladestellen vor

Können Elektroauto-Besitzer demnächst den Einbau einer Ladestelle in Tiefgaragen verlangen? Zwei Bundesländer haben entsprechende Ergebnisse einer Arbeitsgruppe schon in einem eigenen Gesetzentwurf aufgegriffen.
Eine Analyse von Friedhelm Greis

  1. Elektroautos Mehr als 7.000 neue Ladepunkte in einem Jahr
  2. Elektroautos GM und Volkswagen verabschieden sich vom klassischen Hybrid
  3. Elektroauto BMW meldet Zehntausende E-Mini-Interessenten

Schienenverkehr: Die Bahn hat wieder eine Vision
Schienenverkehr
Die Bahn hat wieder eine Vision

Alle halbe Stunde von einer Stadt in die andere, keine langen Umsteigezeiten zur Regionalbahn mehr: Das verspricht der Deutschlandtakt der Deutschen Bahn. Zu schön, um wahr zu werden?
Eine Analyse von Caspar Schwietering

  1. DB Navigator Deutsche Bahn lädt iOS-Nutzer in Betaphase ein
  2. One Fiber EWE will Bahn mit bundesweitem Glasfasernetz ausstatten
  3. VVS S-Bahn-Netz der Region Stuttgart bietet vollständig WLAN

  1. Spielestreaming: Cyberpunk 2077 erscheint für Stadia
    Spielestreaming
    Cyberpunk 2077 erscheint für Stadia

    Gamescom 2019 Google hat das Rollenspiel Cyberpunk 2077 für Stadia eingekauft - leider ohne zu verraten, ob die Raytracing-Version gestreamt wird. Auch der Landwirtschaft-Simulator 2019 und Borderlands 3 sollen über die neue Plattform erscheinen.

  2. Magentagaming: Auch die Telekom startet einen Cloud-Gaming-Dienst
    Magentagaming
    Auch die Telekom startet einen Cloud-Gaming-Dienst

    Google Stadia, Blade Shadow und jetzt Magentagaming: Die Deutsche Telekom macht beim derzeit viel diskutierten Cloud-Gaming-Geschäft mit. Das Angebot der Telekom umfasst zum Beginn 100 Spiele und soll in Full-HD und später in 4K funktionieren. Die Beta startet noch auf der Gamescom 2019.

  3. Streaming: Disney+ kommt zunächst nicht für Amazon-Geräte
    Streaming
    Disney+ kommt zunächst nicht für Amazon-Geräte

    Disneys Streamingdienst Disney+ wird auf einer Reihe von Geräten als App verfügbar sein - nicht jedoch auf Amazons Tablets und TV-Sticks. Außerdem hat Disney die ersten Länder bekanntgegeben, in denen der Dienst im November 2019 starten wird.


  1. 20:01

  2. 17:39

  3. 16:45

  4. 15:43

  5. 13:30

  6. 13:00

  7. 12:30

  8. 12:02